Sorry for the delay, @Nilvus. I can open a github issue, but a few things are unclear to me, and perhaps we can try to hash them out before? If it’s better to move the discussion to github let me know. Here are some of the issues and questions I have regarding the readability of the middle grey UI, in no particular order:
Why are there 6 (as far as I can perceive) different kinds of grey in the UI? There is one grey for the histogram’s background, a different one for the small image preview, another one for the module’s title bar and all around the image preview, another one for the body of the module, another one for the background of the main image preview, and yet a different one for the mask settings and module search bar. If we could reduce that number, even though all of them are close to middle grey, contrast could be improved.
Shadows have already been discarded as a solution, however the problem, in my opinion, still remains: there are several parts of the UI which are not clearly separated. The top bar (with version no. and lightable, darkroom, etc. buttons), the toolbar right underneath (view/sorting options), the left panel, the toolbar under the main image preview and the right panel. Since the UI needs to remain close to middle grey, and shadows are out of the question, why not consider very subtle borders when appropriate? Lightroom does this with a very thin black or dark grey border (perhaps a couple of pixels) around UI elements next to a lighter grey one.
That increases local contrast without affecting global contrast too much. Even though we don’t need to be a lightroom clone, that is another way of separating elements without using colors or contrast across the whole UI. They actually go way beyond, using shadows, and trying to make the UI look slightly more 3d or skeuomorphic. We can keep things flat and minimal, but borrow certain elements to fix this issue. This could also be applied to sliders.
Legibility of text: White text against a middle grey background is not pleasant to read. Here they use the same trick, an almost imperceptible (perhaps 1 px) shadow/border which is darker than the background, slightly offset, so that the text stands out a bit more.
Why is all the text lower case in darktable? (Not important, but a small pet peeve of mine). I find it a bit jarring, and makes the program look a bit less polished to me. Completely subjective, but on the other hand, I don’t know any other app/website that does that. It doesn’t seem like a design element that adds anything to the UI.
Buttons: Why do some dropdown buttons have a gradient? The rest of the buttons have a thin border. Shouldn’t they be the same, or at least similar? Also, darktable seems to use very geometric shapes in the ui, the icons, the sliders, etc. yet all the buttons are rounded. Why is that?
Also regarding borders: Why is there a thin border around the histogram/scopes, but not the small image preview, or any other main UI element?
To add contrast. So no, removing them will not improve contrast. That will be the opposite. I would also add that I don’t see some differences you see. About module title’s bar, its important to set it differently than inside the module, as a module could be expanded or not and we need to differentiate each state from other parts. It’s basics in UI!
Toolbar and main UI (panels and header) have exact same grey. I will even be more precise: this is set to put a grey color on whole UI, then toolbar inherit from that, as well as module header’s title (with a subtle border to see them). Then, a lighter grey is applied for module content background. We have set same specific background for all specific content (histogram, small image preview and all graph content inside modules). To be more precise, default places where small image preview and histogram have same background color (you could see that for the histogram before it is displayed). But all things with a grid have a specific background. It’s all about compromises between what’s around and what’s inside!. If you see different ones, you have a problem on your side (bad calibrated screen for example) but CSS is made that way.
About background of main image, this is a real middle grey. Other things, like main “darker” grey of panels and toolbars of the UI is for the contrast and so differentiate parts. Just needed!
Last thing: this is absolutely not related to grey theme. It’s the default setting on all themes.Grey theme only change which default colors, and set nearly nothing specific different except that.
I totally disagree with you here. All needed things are separated. Some things don’t need to be separated. Toolbar don’t need to be separated, and doing it will just overload the UI. And those toolbar are clearly separated from thumbnails or image depending on the view. And this is what is needed. And shadow in Lightroom view is just awful for me and unpleasant to see.
Lightroom is just not a good example. The UI use dark theme and it’s a good choice to give the impression that images are better but a bad choice for a good process of them. And that give what where their choices for the UI. WIth grey theme, choices are not the same. We need to remember that an UI is also choices regarding objectives of the software and so what we want to consider at first. It’s nearly impossible to have an UI without any limits issues, have the best one for the main objective and a beautiful one. It’s always compromises and what we consider more important than anything else. darktable team choices are those:
for all themes: have the less distracting UI as possible and so the more important place for the image and processing it
for grey theme: consider all known optic illusions and reduced them as far as possible for the better possible processing.
Last thing, I already tried really thin border and feedback (mine and testers) was just a no go!
Two things here:
please be careful about what is an issue or not. It’s not because you don’t like/find something on your taste, that is an issue. An UI consider some objective things but is also subjective (and I include myself too ; I disagree with you on some point, that doesn’t mean you’re right or wrong nor myself ; it’s just that we don’t have same view… and same eyes, same screen, etc.).
Sliders is another problem and, for myself, an issue. This had been improved but can’t be more by now. Most things can’t be fixed by CSS. This is some specific code and would need a rewrite. They’re already issue on that and had been discussed. I pointed it some times. On free software, next thing is to find someone that have skills AND want to spend time on it (mostly in its free time, so we can’t force anyone).
I disagree with the “no pleasant to read”. This is also completely subjective. I find that pleasant and I know I’m not the only one. Of course, as I already said, contrast is always better on a dark background (or black text in white background of course).
About a little border, I never tested that but I’m quite sure it will be worse and same result than what we tried on buttons. But I could test… Another thing possible is to increase white text. I had proposed that but have most of the testers who preferred actual white text. Actually, text is 95% white, it’s so possible to put 100%. You could see a discussion on that here: Grey theme: improve contrast, feedback request · Issue #6106 · darktable-org/darktable · GitHub (I also discussed it on other places like french darktable forums).
To put text to 100% white, just add following line in CSS editor in main settings:
@define-color fg_color @grey_100;
That show that you don’t know a lot of things on darktable and how it is made and evolving. This is absolutely nothing I’m concerned about and so not related to grey theme. It’s a choice from darktable creator’s on start. We are some that don’t like that but it’s hard to change as it’s now historic and creator’s, even if they don’t work anymore on darktable, keep an eye on it. If you search on Github issues, you could find an old issue, still opened, to capitalize text.
Just because, I can’t harmonize those with CSS, because they are not exact same dropdown and need so Gtk code refactoring to harmonize. And I don’t have any skills on Gtk/C/C++ coding. I only have CSS skills and so always improve all I see and can improve on the UI. For other parts, it’s the same as explained before: find someone that want AND can do the work.
All things that “pop out” are rounded: buttons, combobox, icons when you hover on it. Sliders are different for reason explained above about them.
To complete, as I understand, sliders and some combobox are old implemented code as specific widgets called bauhaus (and that was not really well implemented and so cause issues on some combobox and sliders). that was not done really good. And sometimes, refactoring something could not be really easy.
I don’t know what you talk about. I don’t see a thin border around the histogram/scopes (but maybe it’s my eyes):
To sum up this long answer (I will not do it each time): we could add some other difficulties/limits here. It’s really great to try to understand ans ask all that. What’s more difficult is that sometimes (often?!), things posted had already been discussed, have history or just nobody with skills, time and willingness to work on.
And last thing, the UI is nearly entirely customizable (except some points precised in this comment) with CSS. So you can make your own theme (learning CSS is quite easy and more easy than Gtk or C/C++ languages used to code darktable).
We can talk a lot on that but it’s sometimes better to propose some tested code!
You can see it’s much flatter and modern. Darktable definitely has room for UI improvements but I think it would require doing focus groups and professional UX and UI designers first understanding the software and then contributing their time and skills to propose the new and improved UI/UX for Darktable.
But even then, it would probably be a radical change and Darktable UI is not even that bad. In my opinion it’s actually very good and I like it a lot. So personally I think it’s great but I’m sure professional designers would find flaws and propose a better design. But that can be said about anything so…
As @Nilvus and many other developers have raised you, darktable in terms of UI themes, it is based on material design and uses a rather sober design based on grayscales for its light and dark versions. This design that has been polished with the passage of different versions is so that it can visually satisfy most users, in addition to providing a pleasant appearance always starting from the medium gray.
But that does not prevent you to create and use your own theme to personal taste by modifying the parameters of the .css and change them to your liking.
In my case as I spend a lot of time working in front of the screen, I always use all possible applications in their dark themes, darktable is one of them, I took as a starting point the dark theme and modified it to my liking.
I leave two screenshots for you to see it.
Thanks to the fact that the program uses .css you can modify it, but changing the whole conception of the user interface is something that takes time, dedication and effort, and you have to understand that this program is made by a small group of developers who use the little free time they have to improve the functionality of it.
Would it be possible for DT developers in the future to empower user themes that can change look and feel, module order, fonts, icons, windows, etc - like the way KDE has a theme configuration with an online library. That might take some programming changes for the developers but it also has the potential to transfer UI design to users who may, over time, add innovations in UI patterns and plugins that devs won´t have to hard code.
There’s a big difference between KDE and darktable. KDE is not just one application, it’s an application framework, and as such more comparable with Gnome and Gtk, the system darktable is using. So an additional theming engine for darktable wouldn’t make sense, in my opinion…
As for the parts of the interface you mention:
in darktable the shown module order is not just a user interface detail. The order in the GUI is actually the processing order (except for the history stack, where it reflects the order in which modules have been applied/last modified). So you can’t just change the ordering in the GUI without changing the processing order. Decoupling that would mean implementing a separate way to change the processing order of the modules (there are cases where that’s useful)
But it is possible to change the module order, for those who know what they are doing (not all permutations make sense, e.g. filmic before demosaicing…). Afaik, changing the module order is described in the manual.
If you were referring to the organisation of modules in groups, that’s already completely configurable. I think preferred groupings are also highly personal, and (given how easy it is to organise the groups) not really worthwhile to bundle in a theme engine.
Font, icons, etc.: that’s all themeable through CSS (see /usr/share/darktable/themes), and actually uses the Gtk theme engine afaik.
So from what I can see, the GUI is already themeable to a large extent.
So far, several threads have been discussing changes/improvements to the GUI, but no user-provided themes (css files) have appeared, afaik.
I’m trying be disciplined and follow a set of consistent steps.
I read in a recent thread that you should use the modules from bottom to top as they are shown on the right hand side, so in my setup it’s lens correction first, various other modules with filmic being last.
Darktable is already this. Always a work in progress.
This is pretty vague. What does it mean? You want a pink theme? You can already do that. Add icons to the processing modules? Already done. Change the font to comic sans? You can do that.
A framework messing up stuff if users adapts stuff they don’t understand has no value. Thats why most commercial software focussing on casual users bakes in most essential stuff (their users don’t want to bother about pixel pipes) dan provides an ui fooling them to think they could choose stuff to meet their needs.
A well informed user get‘s why there is a dependence between UI and pixel pipe in darktable - and just then he‘s able to make use of the capabilities.
You need to know the why if you use a tool designed to meet enthusiasts. Then you can achieve results other tools won’t provide.
For darktable developers thats the motivation to contribute to the project.
darktable doesn‘t ‚become‘ something, darktable is actively made to something just by those that contributes.
it may sound harsh, but you haven’t contributed to darktable yet and so you’re just another one of millions dudes around having good ideas how others could improve something but never started to do it themselves.
Foss is about contributing instead of requesting something without trying to understand why something is as it is.
You mean like some sort of “Theme Download” plugin, where users can download a theme of their choice from some sort of “online store front”? I really don’t see how that would be advantageous. Would the devs have to check the themes for compatibility? Could online downloadable themes be some sort of security issue?
Does having 1000 theme choices and 1000 icon options really improve usability?
Module order isn’t something to do with themes, it’s more to do with the pixel processing workflow under the hood.
Sorry for the very late reply. Been swamped with work recently. I appreciate that you took the time for such a detailed reply. I was merely trying to point out some issues I found with the theme, hoping that they might be useful.
I understand that the theme has already been tested, it works well enough, and decisions have been made, and that’s totally fine, even though to me they look unpolished, like the lack of capitalization throughout the interface. To someone else that might look fine, but it’s an arbitrary decision and has nothing to do with usability.
For the time being, I think that I’ll switch to the darktable-dark theme, since it is a bit easier for my brain to figure out. I can always press Ctrl+B to check proper exposure and contrast.
It is not arbitrary, we honor the initial decision made by @hanatos who hates capital letters. This has been brought up over and over. The beauty of free software is that you can change it if you want. I did change it once and I thought it was weird, so I changed it back.
Another interesting quote:
I’m so happy it is like this. Imagine how a ls -la | grep would look like: listAllHiddenAndNormalFiles() | globallySearchARegularExpressionAndPrint().
I am not sure this is entirely true. I think even when you create custom groups the modules get added to those in the default pipeline order…so lets say you wanted them in alpha order I am not sure you can do this…maybe I need to go back and check…I could be wrong on that…
I was referring there to the grouping in the interface, of course the order within a group is the pipeline order.
That is a part of the user interface that cannot be changed, as the gui order of modules is the pipeline order, so changing the ‘visual’ order of modules changes the ‘treatment’ order. I think I said just that in the point before the one you quoted
Additional note: once you have your grouping to your liking, youcan still have access to modules not in any of your groups by clicking on the header of a group. So you don’t have to include rarely used modules in your setup, just to have them accessible.
What I answer confirm that some things remains unpolished. Read again my answer. It’s easy to point things, it’s harder to make them improved. As soon as I see a thing to fix, if I can fix it, I do it. But for some, this need Gtk and C coding skills. And someone with those skills, and good design ones, to improve others.
I have a list of things that would be good to improved. I’ve learned some Cairo/Gtk code and recently proposed some new things. But for more, it will be harder. Learning to code take a huge amount of time. And life is short. Anyway, if I can improve things on my free time (and can keep time for others things in my life), I work on that. What about you?
Just as a reminder, darktable is made by passionnate people in their free time. They just develop what they want and can. And I think that darkable, regarding that, is a really well made, polished and powerful software.
