I’m not any kind of developer so frankly I have no idea what I’m talking about, but I have had a little idea I was hoping more knowledgeable people could comment on:
I’ve been experimenting quite a bit with darktable theming over the last few days, and it’s made me appreciate how much can already be achieved with CSS. Small changes like module borders, typography, slider handles and active-state indicators can make a surprisingly large difference to the usability of the interface.
One thing that still stands out to me is the histogram.
For me, the issue isn’t the histogram itself or the information it presents—it’s that it feels visually disconnected from the rest of the UI. Most of the interface can now be styled into a coherent set of “cards” or panels, whereas the histogram is essentially a graph sitting directly on the background. It doesn’t feel like an instrument.
I spent a little time investigating with GTK Inspector and discovered that the histogram is created as a main-histogram widget in src/libs/histogram.c, but I couldn’t find a way to target it from user.css. If I’ve understood things correctly, it doesn’t currently expose a CSS node or class that theme authors can style.
Would it be feasible to expose the histogram container to CSS (or wrap it in a stylable frame) without changing the default appearance? That would let themes optionally add things like a subtle border, padding or background if they wanted to, while leaving the stock UI unchanged.
I’m interested in the capability rather than a particular design. It seems like a small addition that could give theme authors a bit more flexibility and help the histogram integrate visually with the rest of the interface.
In Gtk, you can assign a “name” (id) to any widget. It is as simple as:
gtk_widget_set_name(my_widget, "my-unique-id");
Once you do that, you can target all the elements with that name with a rule like:
#my-unique-id {
...
}
Note that in the HTML standard ids are supposed to be unique within the DOM, whereas in Gtk they are a bit abused and multiple elements can have the same id, so a # rule can in principle target several elements at once.
In this case, you may want to add an id to the histogram widget itself, and maybe also its containers.
I agree that this should be done more consistently throughout the codebase, so that one does not have to resort to fancy selectors to style a specific element.
I didn’t look at this specific part of the code, so I don’t know if there are already IDs in the proximity of the histogram. But as explained above, adding them is trivial.
If you know exactly what you would like to target (as you already know, you can use the Gtk inspector to find out which widget implements what) let me know and I can (help you) prepare a PR.
I’m comfortable with inspector tool in web pages but at the moment GTK inspector is a bit of a black box.
ChatGPT tried to help out by suggesting:
#main-histogram {
border: 3px solid red;
}
or
GtkEventBox#main-histogram {
border: 3px solid red;
}
as selectors, but it doesn't do anything, hence the question about whether the histogram widget actually exposes selectors to theme css...
I guess in the ideal world we would have a full list of selectors then anyone could entirely customise the look and feel without it being an exercise in detective work and no one could ever complain again about the UI!
Personally I'm very with a theme someone made available online, but I just wanted to refine it a bit.
If there is an id assigned, there is no way to know what the id is without looking into the code (or the Gtk inspector). Your chances of getting it right by chance are not very high
What is the process that theme writers use? Obviously there isn’t a selector guide you can just look up. Are they having to pore over GTKinspector to identify every single selector? Good on them if they are, but it would be better if the very wonderful custom css feature was something that everyone who is not a dev but knew a bit of css could use effectively.
I have no desire to turn my darktable install into a Star Wars skinned novelty or any nonsense like that, but I do want to make little usability tweaks here and there. For example, the theme I was using hid the vertical scroll bars until you moused over them, which seems to miss the point a bit, so I changed mine so I can always find them with a quick glance. Tiny tweaks like that. It took a surprising amount of time to identify the right selector within the css, but I got there in the end. But it is much more difficult when the selector is not even enabled to the css (or you can’t be sure if it is).
As I said, I’m not a dev, I can’t write C or whatever is required, but css is easy enough to learn that non-devs can actually contribute something. Especially if it were easier to identify the selectors!
