Skip to content

Conversation

masterpiga
Copy link

Adds two themes that improve module separation in the grey themes (elegant, icons) while respecting as much as possible the philosophy of the grey themes.

The themes were initially implemented as user.css edits in a post on Pixls.us.

They make headers a bit darker, add a rounded inner corner and a pastel-green accent to active module indicators:

image

…able-icons-grey-rounded-accents) that improve module separation in the gray themes.
@pehar1
Copy link

pehar1 commented Oct 18, 2025

I use your code along with numerous other customizations. But new themes for every little adjustment? I fear an endless list of themes if that became common practice. In my opinion, user.css is exactly the right place for such customizations.

@TurboGit
Copy link
Member

Note that there is no code duplication. Those themes are just adding some defs on top of current themes. I have no strong opinion. I do prefer having this in dt when it is generally useful. To me it is the case here. I do think the header is a bit too dark to my taste. @masterpiga can you post a new screenshot of a shade with 0.6 instead of 0.7 for the header? TIA.

@victoryforce
Copy link
Collaborator

I fear an endless list of themes if that became common practice.

This is my fear too. So far, we have 10 themes that cover all the options for choosing characteristics that are important to the user (the presence of icons, the level of background brightness, the contrast of the text). What should we do with rounded corners? Add them as an option to all other themes, doubling their number? Only to some? Then why only to some?

We don't want a combinatorial multiplication of the number of themes by adding new themes for each new customization, do we?

I think it is worth doing a poll on the PIXLS forum and if these improvements (rounded corners, better separation) do not meet with significant criticism and a noticeable number of downvotes, then simply make these changes to the existing themes without adding new ones.

@masterpiga
Copy link
Author

masterpiga commented Oct 19, 2025

@TurboGit

I do think the header is a bit too dark to my taste. @masterpiga can you post a new screenshot of a shade with 0.6 instead of 0.7 for the header? TIA.

Sure, here there are some lighter variants (nit, the shade parameter needs to be increased to lighten things up, not decreased):

0.7 (current impl)

0p7

0.75

0p75

0.8

0p8

0.85

0p85

0.9

0p9

@pehar1

I fear an endless list of themes if that became common practice. In my opinion, user.css is exactly the right place for such customizations.

I think that theme proliferation in itself is not bad, as long as themes are sufficiently different from each other. In this case I think that they are, in everyday usage the difference is quite noticeable imho. On the other hand, it would be nice to be able to group theme variants together (e.g., all grey themes). Also, naming can be improved. Currently all theme names start with darktable which is a bit redundant. If there is interest I could look into implementing a hierarchical menu for the themes (e.g., prefix-based) which would give us more latitude to introduce more theme variations.

As for user.css, the main issue is that contributed snippets (such as the one in my original post) are not very easily discoverable. Hence the proposal of adding them as themes, since users in the forum seemed to appreciate them.

@victoryforce

Should I go ahead and do that or is it better if it's done by one of you devs?

@masterpiga masterpiga closed this Oct 19, 2025
@masterpiga masterpiga reopened this Oct 19, 2025
@masterpiga
Copy link
Author

Sorry, closed by mistake.

@dterrahe
Copy link
Member

dterrahe commented Oct 19, 2025

contributed snippets are not very easily discoverable

In theory we could add an "import snippet" button underneath the CSS box and provide a directory of them that can be easily combined. With descriptive file names. The vetting process for adding more should take into account if they step on eachothers toes. Conflicts could be manually fixed after importing but of course this would require much more knowledge.

We could even link to an online repository. KDE when I was still using it had this get-new-hot-stuff service. But since everybody seems to be on master anyway, a directory would effectively work as well.

@masterpiga
Copy link
Author

@dterrahe Actually I had advanced a related proposal in a post that did not get a lot of attention:

https://discuss.pixls.us/t/a-couple-of-ideas-to-make-theme-editing-a-bit-easier/53386

I was suggesting a tabbed view for the custom css so that one could easily keep several snippets around and switch between them on the fly.

@masterpiga
Copy link
Author

BTW, I have a tentative implementation to replace the combobox with a hierarchical menu for theme selection:

image

If you think that it makes sense I can submit a separate PR.

@dterrahe
Copy link
Member

Might be overkill and invite adding a whole layer to the theme-tree for every optional tweak. But since I would probably only use it once, I don't mind either. To some extend though I would prefer more attention being paid to the gtk4 port rather than adding more features that need porting.

I'd be OK with rounded corners just becoming part of standard elegant. The color accents are more controversial as maybe objectional to some on theoretical grounds. And others might prefer a different color, needing to resort to CSS anyway.

@masterpiga
Copy link
Author

Ok, I don't want to take cycles away from the migration work. I will start a poll in the forum asking whether changing the default grey themes is desirable instead. Further UI improvements around theming can be postponed to a later time.

@masterpiga masterpiga closed this Oct 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants