Questions regarding the Darktable theme

[anon16817310]

Hi all. Sorry for the double post. I was on my phone and somehow I managed to get my message posted and deleted simultaneously.

I was browsing the darktable.css file and saw the following guidelines:

• keep just enough contrast in the UI to make text readable, but not
  too much to avoid distractions from the picture,
• avoid sharp and unnecessary details for the same reason (shadows,
  borders, colors, fancy bits). Use plain shapes and flat design.
• keep 50 % distance between background and foreground colors for active controls
• keep 30 % distance between background and foreground colors for labels and info
• keep 10 % distance between background and foreground colors for insensitive controls
• events are ± 20 % from the normal color
• borders and accents are ± 5 % from the background
• buttons and control follow Google Material Design principles :
  Material Design
• create optical margins by aligning content properly, not by using borders.

Indeed, darktable’s ui is very flat, and needs to be so to be able to edit better. Where my interest got piqued was when I read that buttons and control follow Google Material Design principles.

I then went to the material design website and understood that the system relies on elevation to make the UI understandable:

All Material Design surfaces, and components, have elevation values.

Surfaces at different elevations do the following:

• Allow surfaces to move in front of and behind other surfaces, such as content scrolling behind app bars
• Reflect spatial relationships, such as how a floating action button’s shadow indicates it is separate from a card collection
• Focus attention on the highest elevation, such as a dialog temporarily appearing in front of other surfaces

Elevation can be depicted using shadows or other visual cues, such as surface fills or opacities.

What I took away from the various pages in the site is that in Material Design:

• The UI is organized in various planes at different elevations.
• The higher the elevation, the more important that plane is.
• Contrast, color, opacity or shadows are the means to achieve that plane separation.

That said, and going back to the general guidelines in darktable’s theme, if contrast, color and opacity are not really useful because we need the UI to be as close to middle gray as possible, and only subtle variations of grey are possible, would it be a bad idea to explore the use of (very subtle) shadows? It seems to me that in UI, much like in a picture, contrast of some kind is critical for understanding.

I’ve put together a very rough mockup of what shadows in the UI could look like. It is not a proposal of any kind, and I’m not a designer. This is just meant to spark some discussion regarding the possibility of better element differentiation in the UI, not really regarding which screenshot is more popular or “looks better”, since that will be subjective. Since the themes in darktable are css, I would imagine that making these kind of changes if they improve anything for users would be rather trivial.

the current UI for comparison:

Also the material design links regarding elevation, light and shadows, for reference:

Material Design

Material Design

[kofa (István Kovács)]

Hi, thanks for the theme! One thing I’ve noticed that the shadow at the top affects the small review and the histogram area, which, I think, should be kept intact.

[anon16817310]

You are probably right. I might have gone overboard with some shadows as well. My point was not to actually create a theme and say: “this is what darktable should look like”. But rather try to start a conversation regarding the use of depth and shadows to make the UI more understandable at first glance.

[rvietor]

@anon16817310

Since the themes in darktable are css, I would imagine that making these kind of changes if they improve anything for users would be rather trivial.

Not necessarily, as soon as you start having to differentiate elements that were considered the same (as far as styling goes) before. You can get all kinds of unexpected consequences when changing one element.

But as it doesn’t require any kind of compilation or installation, the css code is easy to change locally.

Also, I note from the design guidelines you quoted:

@anon16817310

• avoid sharp and unnecessary details for the same reason (shadows,
  borders, colors, fancy bits). Use plain shapes and flat design.

Your mockup kind of goes against that.

[anon16817310]

@rvietor

Not necessarily, as soon as you start having to differentiate elements that were considered the same (as far as styling goes) before. You can get all kinds of unexpected consequences when changing one element.

But as it doesn’t require any kind of compilation or installation, the css code is easy to change locally.

I should have added: compared to developing diffuse or sharpen, color calibration and the like.

Also, I note from the design guidelines you quoted:

@anon16817310

• avoid sharp and unnecessary details for the same reason (shadows, borders, colors, fancy bits). Use plain shapes and flat design.

Your mockup kind of goes against that.

Exactly. These guidelines seem to consider shadows “fancy bits”. They also reference material design, where precisely shadows play an important role.

It’s a tricky line to walk, to have a flat, low contrast, greyscale interface and be able to differentiate UI elements clearly.

Again, I wasn’t advocating for any particular solution, but, if the reference is material design, elevation and shadows (even though subtle and unobtrusive) should be design elements to take into consideration.

[Nilvus]

@anon16817310

It’s a tricky line to walk, to have a flat, low contrast, greyscale interface and be able to differentiate UI elements clearly.

That’s exactly the hard thing. I’m the main author of the darktable grey theme. I spent quite a lot of hours to try to find the better balance between all those things and it’s a pain. Of course, everything could be improved and I would love some good ideas. And thanks for trying to propose something.
Anyways, as pointed by @rvietor, your mockup is against Material design guidelines and I think any good design as it added some distractions and unnecessary details.

Unfortunately, there’s sometimes just some “physics” (if we could say that that way for virtual things!) that can’t be beyond. It’s easy to have great contrast and so really good visibility in white or black themes (apps) as they are just on the edges of and so white on black or black on white, and you have the more important contrast possible. Starting for the middle, with middle grey reduce by 2 possibilities. Just as simple as that.

[KristijanZic]

I would not put any any additional shadows. I think it could wrongly affect the UX as the shadow under the top and bottom panels indicate that all the other panels can scroll below the top and bottom when in fact they can’t.

I find that with added shadows I loose the point of the grey theme that should be as simple as possible to not distract the user and to bring his color and contrast perception to the point of being as neutral as possible.

Lastly, Darktable does not follow material design style.

[anon16817310]

@Nilvus

That’s exactly the hard thing. I’m the main author of the darktable grey theme. I spent quite a lot of hours to try to find the better balance between all those things and it’s a pain. Of course, everything could be improved and I would love some good ideas. And thanks for trying to propose something.
Anyways, as pointed by @pedrorrodriguez your mockup is against Material design guidelines and I think any good design as it added some distractions and unnecessary details.

Thank you for your work on the darktable theme. It is indeed a difficult task. The mockup was not meant as any serious proposal (I’m no designer after all), and I definitely got a bit carried away adding shadows. What I think it does show is that it is possible to keep a low contrast theme, but still have distinct ui elements (panels, bars, etc.) through the use of shadows and elevation, which are important material design elements.

Unfortunately, there’s sometimes just some “physics” (if we could say that that way for virtual things!) that can’t be beyond. It’s easy to have great contrast and so really good visibility in white or black themes (apps) as they are just on the edges of and so white on black or black on white, and you have the more important contrast possible. Starting for the middle, with middle grey reduce by 2 possibilities. Just as simple as that.

Precisely because this problem is why I’m in favor of exploring this option a la material design (elevation and shadows). If we can’t use luminosity, colors or opacity as elements of contrast, perhaps shadows are the solution (smaller, fewer, perhaps in different places that in my mockup…).

[anon16817310]

@KristijanZic

I would not put any any additional shadows. I think it could wrongly affect the UX as the shadow under the top and bottom panels indicate that all the other panels can scroll below the top and bottom when in fact they can’t.

Definitely my mockup is not the ideal solution. It was only meant to illustrate a point. I spent an hour fiddling around in gimp, while @Nilvus has spent many hours working on the actual theme.
[/quote]

I find that with added shadows I loose the point of the grey theme that should be as simple as possible to not distract the user and to bring his color and contrast perception to the point of being as neutral as possible.

Simplicity would still be the goal. I find google apps quite simple in their design, yet they are full of shadows, overlapping planes and animations. Again, my mockup was far from perfect and not meant as a replacement for the current theme. I was just trying to make a point.

Lastly, Darktable does not follow material design style.

According to the darktable.css file it does:

• buttons and control follow Google Material Design principles

[KristijanZic]

@anon16817310

According to the darktable.css file it does:

• buttons and control follow Google Material Design principles

As you can see from what you quoted, that is only for buttons and control flow. None of your changes fall under either of those categories.

@anon16817310

I find google apps quite simple in their design, yet they are full of shadows, overlapping planes and animations.

Making Darktable look more like a generic android app or like a website from the bootstrap era with that top navigation would not differentiate it in any way and it’s not even a native app to android.

I’d propose that you add the shadows via CSS theme tweaks textbox in the darktable preferences > general.
But it doesn’t make any sense for Darktable to start using Material Design visual language since those were made primarily for mobile apps. Not to mention much less complex apps.

It makes more sense to rewrite Darktable as a Flutter app if you want it to follow MDG instead of trying to modify GTK in such a heavy manner even if it’s basically heavily themed in DT already.

[anon16817310]

It seems like this is a bit of a sensitive topic for you. The good news is that nothing has changed, and you can continue to enjoy the flat theme. I’m merely bringing up an issue for discussion.

@KristijanZic

As you can see from what you quoted, that is only for buttons and control flow. None of your changes fall under either of those categories.

You are right, however is it sensible to cherry pick elements from another project’s design sheet? What are we basing those choices on? If we are already choosing to use certain elements why not others when they could improve our own UI issues?

@anon16817310

I find google apps quite simple in their design, yet they are full of shadows, overlapping planes and animations.

Making Darktable look more like a generic android app or like a website from the bootstrap era with that top navigation would not differentiate it in any way and it’s not even a native app to android.

Please, do not put words in my mouth. I hope you can give me the benefit of the doubt, the same way I do with you. I never said that darktable should look “like a generic android app or like a website from the bootstrap era”.

What I am saying is:

• that darktable has a challenge with its theme. It is not easy at first glance to make sense of what is a panel, what is a button, or what is a tool bar. This is by no means any criticism on the work that @Nilvus has done, merely feedback and food for thought.
• The UI needs to remain flat and close to middle grey.
• Since luminosity and color contrast are out of the question, other ways should be found to provide clarity to the ui.
• Even though darktable is very technical and users are expected to make an effort to learn its ways, unwillingness to improve certain issues (in this case readability) is not something to aim for. In some ways darktable is amazing, and in some ways it needs work. If we can’t try to provide feedback, and discuss, no progress can be made. Getting too attached to not even an interface, but a theme, when there is potential for improvement, doesn’t seem like it would help anyone.
• Since we are already taking material design as a reference for some UI elements, looking at their solution for darktable’s UI contrast problem only seems natural. Not to make darktable an “android app clone”, but to use what works for them. If someone like my mother can make sense of any Google app without prior training, and understand what is what, they are doing something right. Granted, darktable is way more complex, but the design principles still apply. And I’m sure the people at Google test these designs quite a bit beyond the “I like how this looks” standard.

I’d propose that you add the shadows via CSS theme tweaks textbox in the darktable preferences > general.
But it doesn’t make any sense for Darktable to start using Material Design visual language since those were made primarily for mobile apps. Not to mention much less complex apps.

It makes more sense to rewrite Darktable as a Flutter app if you want it to follow MDG instead of trying to modify GTK in such a heavy manner even if it’s basically heavily themed in DT already.

Shadows and my mockup are irrelevant. I only made it to illustrate a point. What matters is some form of visual contrast to make a middle grey interface understandable. I’m sure I’m wrong in many ways, but it’s not about me either. If you have a solution to this problem, I think we all would love to hear it.

[anon16817310]

In fact let’s break it down even further, so that things become more clear.

These are the main elements of darktable’s UI:

• A top bar (which come to think about it, and since vertical space is always limited, could be narrower)
• A toolbar right below the top bar
• The image preview
• A toolbar right below the preview
• An image strip at the bottom
• Two side panels

These are common elements found in applications, websites and mobile apps.
Currently in darktable’s theme we seem to have a kind of “toolframe” around the image preview, with very similar shades of grey, which at first sight makes the UI more difficult to understand (always in my own experience):

This is the issue I’m talking about, and the motivation for this thread.

It doesn’t even have to be the Material design way. Other raw developing applications deal with this in a different way: Lightroom has a slightly darker theme, and uses borders and shadows. Capture one has an even more contrasty flatter interface, no shadows, but with borders and color accents. We don’t have to be a clone of any particular application or design guidelines, but what they (material design, lightroom, capture one) have in common is a clear separation of elements in the UI.

The way they treat text in the UI is also different. They have a very subtle (something like a 1px) drop shadow, which makes the text stand out from the grey background and makes it easier to read.

Beyond being visually appealing, I think we can all agree that their UI’s are relatively easy to grasp, even though they are complex applications as well.

Since a close to middle grey UI is better for editing, creating ways to separate UI elements is even more critical to darktable than to these other applications.

[Brian_Innes]

One other issue. Would the shadows be hard wired into the software? Or would they be reliant on whatever desktop environment / operating system the user is using? e.g. would there be an issue if the user was using a lightweight window manager, without any effects / shadows enabled, compared to a user using something like Gnome?

[KristijanZic]

@anon16817310

It seems like this is a bit of a sensitive topic for you. The good news is that nothing has changed, and you can continue to enjoy the flat theme. I’m merely bringing up an issue for discussion.

Well, I’m just sharing my opinion that I’m not convinced by your arguments. I think MDG is not particularly suited for this kind of project and even if it was, would it be a good idea to look like an Android app or an Electron app? I seriously don’t like that esthetic, especially since darktable doesn’t even run on any DE that follows MDG so it will look out of place on any runtime it runs on.

@anon16817310

You are right, however is it sensible to cherry pick elements from another project’s design sheet? What are we basing those choices on?

If it makes sense to do so then yes.

@anon16817310

If we are already choosing to use certain elements why not others when they could improve our own UI issues?

You are assuming there are design issues.

Imo it would be best if you tried to make your own theme, take darktable.css rename it to darktable-material.css and go for it. It can be hard to find which rules apply on which widgets tho. At least I find it hard since gtk inspector is awful compared to web or android one.

@anon16817310

Lightroom has a slightly darker theme, and uses borders and shadows.

Darktable has a darker theme too and uses borders where it makes sense. As for the shadows, even Android is trying to be more modern and is getting rid of them in all their new designs.

I’ll give you an example, do you see any shadows here?

Elevation shadows are an old concept and are rapidly going away. That’s why google introduced a new design language with Material You. It’s radically different from the current MDG. Using MDG in 2022 would be like beating a dead horse.

I think you should really look into Material You. I think it’s more Dartable’s style both in form and function than MDG.

[anon16817310]

@KristijanZic

Well, I’m just sharing my opinion that I’m not convinced by your arguments. I think MDG is not particularly suited for this kind of project and even if it was, would it be a good idea to look like an Android app or an Electron app? I seriously don’t like that esthetic, especially since darktable doesn’t even run on any DE that follows MDG so it will look out of place on any runtime it runs on.

As I mentioned above, nobody is talking about making darktable into an android app. The fact that you or I don’t like a certain aesthetic is beside the point, since taste is subjective. You might light something I don’t and viceversa. I am talking about the challenges of creating a good, easy to see low contrast theme. That I think we can agree is a more objective and productive topic for discussion.

@anon16817310

You are right, however is it sensible to cherry pick elements from another project’s design sheet? What are we basing those choices on?

If it makes sense to do so then yes.

How would we know that it makes sense to do so?

You are assuming there are design issues.

I assume there are design challenges with making a very low contrast middle grey theme, as confirmed by @Nilvus, who actually created it. I am already used to the current one, although the lack of contrast between elements makes it less pleasant to use for me. Dealbreaker? No. Would it be nice to improve it? Totally. How? That’s what we can discuss.

Let’s look at it from a different perspective: Would you say a picture is easier or more difficult to look at and understand if its histogram is all squeezed up right in the middle with very little local contrast? That’s what I’m talking about. Since we can’t expand global contrast, because that would be detrimental to editing, it would be great to find ways to increase local contrast in darktable’s UI. What those ways are is again up for debate.

Imo it would be best if you tried to make your own theme, take darktable.css rename it to darktable-material.css and go for it. It can be hard to find which rules apply on which widgets tho. At least I find it hard since gtk inspector is awful compared to web or android one.

I can think of many better things to waste my time on than a theme that only I will use, thanks

@anon16817310

Lightroom has a slightly darker theme, and uses borders and shadows.

Darktable has a darker theme too and uses borders where it makes sense. As for the shadows, even Android is trying to be more modern and is getting rid of them in all their new designs.

A darker theme wouldn’t solve the issue, since for editing the interface should be around middle grey.

I’ll give you an example, do you see any shadows here?

These themes are high contrast ones. They don’t address the issue I raised. If the UI needs to be around mid grey and low contrast, this is not the answer (not because of taste, mind you, they look perfectly fine to me).

Elevation shadows are an old concept and are rapidly going away. That’s why google introduced a new design language with Material You. It’s radically different from the current MDG. Using MDG in 2022 would be like beating a dead horse.

The needs (in terms of contrast) for a raw developing software and a google app are different, so they can afford to push contrast in their themes as much as they want. If contrast is high, shadows can become unnecessary (see Capture One). Even so, there are minimal drop shadows in your screenshots.

[KristijanZic]

I give up, you want to implement design language that’s already past its time.
Please take a look at Material You or wait until all the documentation is released and move from there. It’s a waste of time to implement something now that’s almost 10 years old and in a process of actively being replaced. Not to mention it’s weird to do in gtk.

[Nilvus]

@anon16817310

• that darktable has a challenge with its theme. It is not easy at first glance to make sense of what is a panel, what is a button, or what is a tool bar. This is by no means any criticism on the work that @Nilvus has done, merely feedback and food for thought.

A grey theme/app is always a challenge, due to the fact that it is a grey theme. It’s impossible to have an Ui as readable as a white or black app/theme. Anyway, I disagree on your statement that is not easy to understand what is a panel, a button or a toolbar. Limits are clear, except if you screen is not correctly calibrated or really too low luminosity (on a 100% sRVB screen correctly calibrated and 90cd/m², limits are clear). The only thing that is not always clear is some combobox limits. I also tested many things by now without finding a better way. I don’t know which OS and/or apps, desktop environments if you use Linux, but how we understand an UI depends also on that. I’m sometimes lost in Windows 10 UI and some limits on widgets and it’s probably more because I use Linux and hate Windows that just issues on Windows 10 UI (even if I think Windows 10 has a really bad UI/design).
Consider also that Gtk library (library used for the UI of darktable) doesn’t support all CSS possibilities. I have had some ideas to improve the UI that were not possible just because of that. So some things possible by CSS for a website are not possible for Gtk apps. Another difficulty!

Be sure that I don’t see for my part any criticism on my work. I have just the impression that you don’t know/understand all limits and so what is possible/good to do. All things (or nearly all) are compromise. Of course, things are more complex. The UI/theme could be improved, it’s sure, but not to be so more readable. I really think it’s an error to believe that. Or with a complete rework. This will also provide other issues, like force all users to learn from scratch how to use the app. I spent so much time and Aurélien Pierre who make the new UI (I then create and improved the grey theme on his work) also. We both make a lot of tries, and regularly improve the UI. You should also see that proposal like shadows cause other issues. And we have had other proposals for other people that have other issues.

@anon16817310

• The UI needs to remain flat and close to middle grey.
• Since luminosity and color contrast are out of the question, other ways should be found to provide clarity to the ui.
• Even though darktable is very technical and users are expected to make an effort to learn its ways, unwillingness to improve certain issues (in this case readability) is not something to aim for. In some ways darktable is amazing, and in some ways it needs work. If we can’t try to provide feedback, and discuss, no progress can be made. Getting too attached to not even an interface, but a theme, when there is potential for improvement, doesn’t seem like it would help anyone.

Good statements here. For last one, the difficulty is to found other ways that really improve the UI and not add other issues.

@anon16817310

• Since we are already taking material design as a reference for some UI elements, looking at their solution for darktable’s UI contrast problem only seems natural. Not to make darktable an “android app clone”, but to use what works for them. If someone like my mother can make sense of any Google app without prior training, and understand what is what, they are doing something right. Granted, darktable is way more complex, but the design principles still apply. And I’m sure the people at Google test these designs quite a bit beyond the “I like how this looks” standard.

Material design provides good guidelines and some are used in darktable. But that remains Google guidelines and it’s not the only good ones nor the only good design.

@anon16817310

Shadows and my mockup are irrelevant. I only made it to illustrate a point. What matters is some form of visual contrast to make a middle grey interface understandable. I’m sure I’m wrong in many ways, but it’s not about me either. If you have a solution to this problem, I think we all would love to hear it.

That’s the point, limits are easy to find, understanding why the limits are there is a more difficult thing to find and understand, and find the good solutions is something really hard!

That’s all what we have each time limits are posted: no good proposal by now to fix them without implementing new issues/limits. As I already said, it’s really great to test, now that we confirmed that shadows are not a good solutions, I don’t see any reasons to continue more on shadows and on grey theme limits.

[anon16817310]

Thanks for the reply.

Anyway, I disagree on your statement that is not easy to understand what is a panel, a button or a toolbar.

Perhaps I exaggerated a bit, but I think you get my point.

Let me see if I got everything straight:

• A grey theme will always be challenging no matter what. It will always be less readable than a black and white theme.
• The Gtk library that darktable uses doesn’t support all CSS possibilities found on websites, which limits possibilities.
• You and Aurélien Pierre have spent a lot of time on this UI, so a rewrite is not possible (I never meant anything like that, it doesn’t sound like it makes sense).
• Shadows are a bad idea, since they cause other issues, and potentially old fashioned.
• It is difficult to improve the UI without introducing new issues.
• Material design’s guidelines are good, but they are not the only ones or the only good ones.

Did I miss anything? I actually can understand and agree with all these statements. Even though it will be difficult to improve this theme, would you mind if I made a list of the issues I see and share them here anyways? Perhaps there is still a way to improve them. If not, at least we tried.

[KristijanZic]

@anon16817310

Even though it will be difficult to improve this theme, would you mind if I made a list of the issues I see and share them here anyways? Perhaps there is still a way to improve them. If not, at least we tried.

By all means, I’m sure nobody would object to that. Feedback is always good

[Nilvus]

@anon16817310

Did I miss anything? I actually can understand and agree with all these statements. Even though it will be difficult to improve this theme, would you mind if I made a list of the issues I see and share them here anyways? Perhaps there is still a way to improve them. If not, at least we tried.

This seems complete to me and excellent summary. You point all important statements here (and first time I see that and it’s really pleasant to read. Thanks). Of course, this way, I’m totally on for having issues you see (be precise if possible).

You could share them here but I think it would be better if you could post it as an issue in darktable Github. Is it possible for you? If yes, I propose you to do it and ping me in Github issue. Thanks.