[JENKINS-61480] Dark Theme

A checkbox that provides a global Dark Theme configuration.

Originally reported by tasigabi97, imported from: Dark Theme

assignee: oleg_nenashev
status: In Progress
priority: Minor
component(s): core
label(s): user-experience, ux
resolution: Unresolved
votes: 3
watchers: 9
imported: 2025-11-24

Raw content of original issue

A checkbox that provides a global Dark Theme configuration.

3 attachments

tasigabi97:

Original comment link

Raw content of original comment:

Hello guys!

Could you give me advice in connection with the implementation?

Hello guys!

Could you give me advice in connection with the implementation?

oleg_nenashev:

Original comment link

Raw content of original comment:

A simple way to do so is to create a new theme for https://plugins.jenkins.io/simple-theme-plugin/ so that others can enable it. But it would work for all users of a Jenkins instance at once. Right now Jenkins does not support user-selected themes, but technically it could be added.

CC fqueiruga jhartley, might be a topic for UX SIG

A simple way to do so is to create a new theme for https://plugins.jenkins.io/simple-theme-plugin/ so that others can enable it. But it would work for all users of a Jenkins instance at once. Right now Jenkins does not support user-selected themes, but technically it could be added.

CC fqueiruga jhartley, might be a topic for UX SIG

fqueiruga:

Original comment link

Raw content of original comment:

I think this is worth discussing at the next SIG meetings, as it can be a rather interesting project. It also would "double" our CSS and design work. tasigabi97 please feel free to come to the next SIG meeting, 16/03/2020 4PM UTC. More info here: https://jenkins.io/sigs/ux/

tasigabi97:

Original comment link

Raw content of original comment:

So I'm working on it and thought it would be nice for it to be compatible with whoever wants his plugin to be compatible with it. I made a regex that can find css colors in a file and replace it with another color like this:

   

How I imagined it would get all css files that being rendered on a page, search it in the static resources, make a copy with substituted colors and re-link them in the header. But now I got kinda stuck on how could it get all css links on a currently rendered page, first thought was I should get the StaplerResponse and crawl it from the html response, but it doesn't have a body. Any suggestions guys? oleg_nenashev,  fqueiruga

By the way, the current design looks like this

So I'm working on it and thought it would be nice for it to be compatible with whoever wants his plugin to be compatible with it. I made a regex that can find css colors in a file and replace it with another color like this:

How I imagined it would get all css files that being rendered on a page, search it in the static resources, make a copy with substituted colors and re-link them in the header. But now I got kinda stuck on how could it get all css links on a currently rendered page, first thought was I should get the StaplerResponse and crawl it from the html response, but it doesn't have a body. Any suggestions guys? oleg_nenashev, fqueiruga

By the way, the current design looks like this

oleg_nenashev:

Original comment link

Raw content of original comment:

It might be easier to just poll all CSS files from GitHub: https://github.com/search?q=org%3Ajenkinsci+extension%3Acss&type=Code

fqueiruga:

Original comment link

Raw content of original comment:

TBH I don't think scanning and substituting existing files will scale well, and it may not be ressilient to changes. I agree with oleg_nenashev that a better alternative would be to use a custom theme using the simple-theme-plugin. You can take inspiration on the material or neo2 themes.

In the medium/long term I would like to have the UI themable using CSS variables, but we lack infrastructure at the moment for that.

TBH I don't think scanning and substituting existing files will scale well, and it may not be ressilient to changes. I agree with oleg_nenashev that a better alternative would be to use a custom theme using the simple-theme-plugin. You can take inspiration on the material or neo2 themes.

In the medium/long term I would like to have the UI themable using CSS variables, but we lack infrastructure at the moment for that.

oleg_nenashev:

Original comment link

Raw content of original comment:

https://github.com/jenkinsci/uithemes-plugin can partially help also, but it is not as flexible as Simple Theme plugin (CC markewaite)

tasigabi97:

Original comment link

Raw content of original comment:

I mean, regex is really fast and it only needs to be done when a new plugin is added or existing plugin was updated. The problem isn't necessarily how I get the css files, because I can just search them in the static resources folders. It is how can I tell which css is currently being rendered on a page. Because if I render all the substituted css at all the time I can cause conflicts or overrides. I dont really understand how the page rendering works in Stapler. From what I've seen it takes the bound classes then serializes them to xml, but where the actual html rendering is? I made the plugin based on how simple-theme works. The main class extends PageDecorator so it gets called on every page, my header.jelly contains all the css. It also has a location-based automatic turn-on when the sun goes down. Of course the manual way for plugin style support would be to add additional stylesheets on the plugin config page. But it would be nice if I could just get the css currently being rendered on a page and search for the /*D@RK: #ffffff */ tag or something similar, so if people want to add dark mode support on their plugin they can do that. But anyway, thank you for replying, I'll check out ui-theme.

I mean, regex is really fast and it only needs to be done when a new plugin is added or existing plugin was updated. The problem isn't necessarily how I get the css files, because I can just search them in the static resources folders. It is how can I tell which css is currently being rendered on a page. Because if I render all the substituted css at all the time I can cause conflicts or overrides. I dont really understand how the page rendering works in Stapler. From what I've seen it takes the bound classes then serializes them to xml, but where the actual html rendering is? I made the plugin based on how simple-theme works. The main class extends PageDecorator so it gets called on every page, my header.jelly contains all the css. It also has a location-based automatic turn-on when the sun goes down. Of course the manual way for plugin style support would be to add additional stylesheets on the plugin config page. But it would be nice if I could just get the css currently being rendered on a page and search for the /*D@RK: #ffffff */ tag or something similar, so if people want to add dark mode support on their plugin they can do that. But anyway, thank you for replying, I'll check out ui-theme.

fqueiruga:

Original comment link

Raw content of original comment:

AFAIK ui-theme is unmaintained, only simple-theme is active. I'm not really sure what your goal with modifying all css files is, is it at runtime? still looks really intense and brittle (changes on the main css would always break the dark mode)

tasigabi97:

Original comment link

Raw content of original comment:

That's exactly what I want to avoid. My goal with it would be to be more persistent. You would just need to add a css comment on the line that would look different on the dark theme, so in 1 css file you could define the support for the dark-mode plugin. For example you have in the main css: body

{ background-color: #ffffff; /* D@RK: #000000 */ }

If in a new Jenkins version you decided to rename the css tag to like '#body', but you still have that comment, the program can still substitute it when dark mode is on.This way you only have 1 css file but it has a dark mode and a normal mode. It wouldn't be at runtime though. Only at startup, plugin upgrading, installing or removing. It would cache the substituted css in a folder, and render it if a view needs it.

That's exactly what I want to avoid. My goal with it would be to be more persistent. You would just need to add a css comment on the line that would look different on the dark theme, so in 1 css file you could define the support for the dark-mode plugin.
For example you have in the main css:
body

{

background-color: #ffffff; /* D@RK: #000000 */

}

If in a new Jenkins version you decided to rename the css tag to like '#body', but you still have that comment, the program can still substitute it when dark mode is on.This way you only have 1 css file but it has a dark mode and a normal mode. It wouldn't be at runtime though. Only at startup, plugin upgrading, installing or removing. It would cache the substituted css in a folder, and render it if a view needs it.

fqueiruga:

Original comment link

Raw content of original comment:

I don't know how well would that play on normal UI development. I think it would be a bit of an annoyance to need to always remember the dark mode.

My ideal solution would be to use CSS variables that a dark theme could override. Example:

// Jenkins core stylesheet
:root {
    --body-background: #fefefe;
}

body {
    background-color: var(--body-background);
}


// On the dark theme stylesheet
:root {
    --body-background: #000;
}

I think it's the only way to make it so that the changes will scale. It still has coupling problems, as the CSS variables would then become an API that plugin stylesheets could use. It also needs some deep refactors and changes to happen, but no lesser than having to add a dark comment to all styleshets.

I don't know how well would that play on normal UI development. I think it would be a bit of an annoyance to need to always remember the dark mode.

My ideal solution would be to use CSS variables that a dark theme could override. Example:

// Jenkins core stylesheet
:root {
    --body-background: #fefefe;
}

body {
    background-color: var(--body-background);
}


// On the dark theme stylesheet
:root {
    --body-background: #000;
}

I think it's the only way to make it so that the changes will scale. It still has coupling problems, as the CSS variables would then become an API that plugin stylesheets could use. It also needs some deep refactors and changes to happen, but no lesser than having to add a dark comment to all styleshets.

fqueiruga:

Original comment link

Raw content of original comment:

tasigabi97 The neo2 theme for simple-theme-plugin has a dark mode option: https://github.com/TobiX/jenkins-neo2-theme/tree/master/less Maybe you'll find it interesting.

thinkmassive:

Original comment link

Raw content of original comment:

fqueiruga it looks like the neo2 maintainer removed dark mode the day after you posted that, saying it looked bad and was unmaintainable: TobiX/jenkins-neo2-theme@fc74c10

I look forward to the day when jenkins can match the rest of my dashboards in dark mode, will be glad to test prerelease work when it's available.

fqueiruga it looks like the neo2 maintainer removed dark mode the day after you posted that, saying it looked bad and was unmaintainable:
TobiX/jenkins-neo2-theme@fc74c10

I look forward to the day when jenkins can match the rest of my dashboards in dark mode, will be glad to test prerelease work when it's available.

oleg_nenashev:

Original comment link

Raw content of original comment:

Another dark theme which is kinda abandoned: https://github.com/camalot/jenkins-dark-stylish

After the initial discussions in the UX SIG we agreed to add the Dark theme to the Jenkins UI/UX hackfest project ideas. The event will take place on May 25-29: https://www.jenkins.io/events/online-hackfest/2020-uiux/

Another dark theme which is kinda abandoned: https://github.com/camalot/jenkins-dark-stylish

After the initial discussions in the UX SIG we agreed to add the Dark theme to the Jenkins UI/UX hackfest project ideas. The event will take place on May 25-29: https://www.jenkins.io/events/online-hackfest/2020-uiux/

oleg_nenashev:

Original comment link

Raw content of original comment:

tasigabi97 are you working on it actively at the moment?

See https://plugins.jenkins.io/dark-theme
Installed on 35% of Jenkins instances

Navigation Menu

Repository navigation

[JENKINS-61480] Dark Theme #11421

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[JENKINS-61480] Dark Theme #11421

Description

Activity

jenkins-infra-bot commented on Mar 14, 2020

jenkins-infra-bot commented on Mar 16, 2020

jenkins-infra-bot commented on Mar 16, 2020

jenkins-infra-bot commented on Apr 1, 2020

jenkins-infra-bot commented on Apr 1, 2020

jenkins-infra-bot commented on Apr 2, 2020

jenkins-infra-bot commented on Apr 2, 2020

jenkins-infra-bot commented on Apr 2, 2020

jenkins-infra-bot commented on Apr 2, 2020

jenkins-infra-bot commented on Apr 2, 2020

jenkins-infra-bot commented on Apr 2, 2020

jenkins-infra-bot commented on Apr 3, 2020

jenkins-infra-bot commented on Apr 29, 2020

jenkins-infra-bot commented on May 15, 2020

jenkins-infra-bot commented on May 15, 2020

timja commented on Nov 24, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions