A checkbox that provides a global Dark Theme configuration.

        1. chrome_Dn1yvh9t3A.png
          chrome_Dn1yvh9t3A.png
          3 kB
        2. dark.png
          dark.png
          41 kB
        3. regex.png
          regex.png
          43 kB

          [JENKINS-61480] Dark Theme

          Hello guys!

          Could you give me advice in connection with the implementation?

          Gábor Tasnádi added a comment - Hello guys! Could you give me advice in connection with the implementation?

          Oleg Nenashev added a 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

           

          Oleg Nenashev added a 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  

          Félix Queiruga Balado added a comment - - edited

          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/

           

          Félix Queiruga Balado added a comment - - edited 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/  

          Gábor Tasnádi added a comment - - edited

          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_nenashevfqueiruga

          By the way, the current design looks like this

          Gábor Tasnádi added a comment - - edited 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 added a comment -

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

           

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

          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.

          Félix Queiruga Balado added a 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.

          Oleg Nenashev added a comment -

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

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

          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.

          Gábor Tasnádi added a 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.

          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)

          Félix Queiruga Balado added a 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)

          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.

          Gábor Tasnádi added a 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.

          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.

          Félix Queiruga Balado added a 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.

          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.

          Félix Queiruga Balado added a 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.

          Alex Miller added a comment -

          fqueiruga it looks like the neo2 maintainer removed dark mode the day after you posted that, saying it looked bad and was unmaintainable:
          https://github.com/TobiX/jenkins-neo2-theme/commit/fc74c10f27d66e25c65f436a3ac7ad68dc652caa

          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.

          Alex Miller added a comment - fqueiruga it looks like the neo2 maintainer removed dark mode the day after you posted that, saying it looked bad and was unmaintainable: https://github.com/TobiX/jenkins-neo2-theme/commit/fc74c10f27d66e25c65f436a3ac7ad68dc652caa 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 added a 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/ 

          Oleg Nenashev added a 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/  

          Oleg Nenashev added a comment -

          tasigabi97 are you working on it actively at the moment?

          Oleg Nenashev added a comment - tasigabi97 are you working on it actively at the moment?

            oleg_nenashev Oleg Nenashev
            tasigabi97 Gábor Tasnádi
            Votes:
            3 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated: