A couple of ideas to make theme editing a bit easier

Software darktable
,
1

Hi all,

I started playing around with DT theming a bit and I found some areas for improvement that would significantly streamline the process of developing new themes.

As I am not familiar with DT’s codebase or GTK, the main purpose of this thread is to understand (a) whether any of these proposals are feasible within the current stack, (b) whether they are sensible and desirable and (c) how much work they would entail.

Also, maybe some of the things that I am proposing are already possible in one fashion or another and I just don’t know. In this case, I would be very grateful is someone could elucidate.

Identifying the right selector for UI elements

Finding out the correct CSS selector to target a specific element is not easy. The GTK inspector helps to some extent, but then there are widget types, classes and pseudo-classes that add to the problem. Going through darktable.css helps, but even so there is a fair amount of guesswork involved.

Possible solution

Add an “Inspector” mode to the UI that would let one click on one element and print/copy to the clipboard the selector to target that element. Bonus points, also list all the pseudo-classes that could possibly apply to that specific element (i.e., :active or :checked).

Interacting with the UI while editing user.css

Since the preferences window is modal, while one is editing the custom CSS one cannot interact with the UI (i.e., see how a change would affect the lightroom, the darkroom, the quick settings, etc.). The process of iterating. by editing, saving, closing the prefs, playing with the UI and opening the prefs again is a bit convoluted.

Possible (alternative) solutions

  1. In the preferences, add a button to open the CSS editor and make it a non-modal child of the main UI, so that when the prefs window is closed the CSS editor stays around. Keep the button to save and apply the changes together with the CSS editor.

  2. If the UI is in Inspector mode (see above), open the prefs window as a non-modal window.

  3. Add a command line flag to watch user.css for changes, or to reload it every N seconds, so that one can directly edit it in an external editor (that would be vim, of course) without going through the preferences window.

Report validation errors in the UI

If there is an error in the custom CSS, the style is still partially applied and there is no notification of a parsing error. This makes it very difficult to understand whether a CSS rule did not trigger because of an error, or because of a wrong selector. The error is visible in the terminal if you started DT from there, but switching back and forth is cumbersome.

Possible solution

Show a popup window with the validation error, as printed in the terminal.

Quickly toggling between different versions of user.css

It would be useful to be able to quickly swap the contents of users.css with something else, e.g., for before-after changes. It could also be useful to try out some new style without having to backup up the previous version.

Possible solution

Make the custom CSS a tabbed view, where users can add tabs at will and decide from which tab to source the CSS to apply. These would be saved as user_{i}.css in the config dir, or in a monolithic user.css file using special comments as separator.

Looking forward to your comments, thanks!

1 Like
2

Additionally, it would also be nice to have more fine grained ways to target UI elements.

Two things that come to mind:

  • For every module, add a class module_{module_name} to all the elements of its UI, so that individual modules can be styled separately. I am mostly thinking about “module order” here, which shares the same UI elements with the other modules but it’s not laid out as all other modules.

  • For every module, add classes module_state_enabled_{true|false} and module_state_selected_{true|false} to all the elements of its UI, so that one can, for example, style the header of active and selected elements differently. I understand that this should be possible in GTK4 using the :has pseudo-class and looking at some properties of the child elements, but in GTK3 this is not possible (TTBOMK) and anyways a direct selector would make for much cleaner CSS rules.

1 Like