New interface in darktable 2.7 (dev)

Yes, probably but the only thing that won’t be irritating is to do “just nothing”. Sadly, whatever you do there is always someone who won’t be pleased. I don’t know how to have a GUI to fit everyone, in dt or in any other software.

Simply, don’t remove features that some people likes. This is like with the topic about removing EXIF info from the histogram - at the end of the day, it is imho better than it was before (we can hide it, we can choose different placement, we can finally choose what we want to see). Same here, making this configurable was a big step forward and I doubt anyone complains about it. But this PR could be probably splitted to 2: one that makes everything configurable (and preserve previous styling) and one that adds new shiny L&F.

There will always be people who want the old way. If we never removed features (were the icons a feature even? Not really I think) that a some liked, we’d never get anywhere.

Omelet, eggs, breaking.

Also, the obligatory it is free software, the source code it there, you’re free to omit any commits you don’t want. You’re free to run 2.6.x for the rest of your life! :smiley:

3 Likes

UX but yes, it is.

The problem is we could do omlet without breaking eggs in this case.

It seems to me that the main purpose of this overhaul is to get everything in the css for theming. It defies logic then that these icons should be just discarded rather than themed.

1 Like

Earlier in this thread it was explained that the icons were not that great, they took up to much room with the new module renaming feature, and not every module had an icon so it was inconsistent.

It’s also been explained that some people find these icons useful even if you do not.

If they are themed then you can turn them off… While I can expand on them.

1 Like

One problem is about who has commit rights. In a project like dt or RT that’s not an easy decision.
Another problem is how good is the teamwork. Imho that’s the more essential question which also can give the answer to the first question…

Just my 2 cents as I followed the discussion on #darktable irc

Edit: Forgot to mention the main point (from my perspective being a dev of RT (not dt)): With the exception of no brainer bug fixes we never push big changes to dev (master) without consense

Edit: Disclaimer: I kind of like the changes to the dt gui made by @anon41087856

4 Likes

That’s plain wrong as explained again and again. It is very difficult to do in CSS all the tweaking done on each and every widget directly in C.

But this discussion goes nowhere. I’m fine with people not liking that. That reminds me the first GNOME Shell with many removed features. At some point you need to restart clean to ensure that in the future you’ll be able to do better.

That’s the whole point here. And instead of talking we should try to come with yet a better CSS or alternatives ones for each to have the choice about the GUI.

That will be my last post on this thread.

6 Likes

Hello everyone,

DISCLAIMER:
I have never liked the old Darktable interface and especially its icons.
Therefore, my personal opinion is likely biased…

These past months, I have followed the commits in the Darktable’s GitHub web-page with great attention because of that.
I have tried Darktable several times in the past years, mostly on Windows 10, because I consider it more features completed compared to RawTherapee (no clone tool, no masks etc).
In the end, however, I have always sticked with RawTherapee because of its GUIs which I consider more attractive for my needs.

As regards this discussion, to make it short I am persuaded that:

  • You can always stick with the stable version;
  • You can code it yourself whatever it suits you and propose to the community;
  • You can hire someone to code it for you.

Needless to say, in an ideal world everything concerning the GUIs (icons, themes, shortcuts etc) should be configurable…
In practice, this takes a HUGE amount of time!
Users generelly strongly underestimate the time and skills needed for this task…
IMHO, It is impossible to satisfy everyone’s needs concerning the software interfaces!
Adobe Photoshop elements, for instance, has different workspaces: basic for beginners, expert etc
Just think at how much it is different a software for a smartphone (GUIs which are easy to navigate and no cluttered) and one for a Pc Desktop (GUIs with plenty of panels).

Let’s take an example such as LibreOffice [1] which has million of users and many private software companies working on it (Collabora, RedHat etc)
Andreas Kainz [2] is the designer of most of the new icons added these past months. His work on this taks is wonderful IMHO.
Lately, he worked hard on improving the Sifr Theme which has mono color icons [3].
He works as a volunteer, that is he is not officially paid by anyone but he delivers them just for fun, in his spare time.
If you take a look at his patreon web-page he has only 9 sustainers (patrons), which means 27 dollars a month whereas LibreOffice has millions of users all around the world…

In the long distant past, personally, I was a strong supporter of monochromatic icons with gray themes as background because I considered them much more professionals and also less distractive to work with.
I couldn’t believe why my older colleagues didn’t like them at all!
At present, I am much older and my sight is not as good as in the past. Funnily enough, now, I prefer icons with colors myself, not monochromatic ones!
For instance, now, I like very much the standard GUIs of Gimp [4] since I find it easier for me to work with: I can tell the difference of the different tools much more easily.

Thanks a lot indeed for your past comments: I have read them with great pleasure :slight_smile:

[1] https://www.libreoffice.org/
[2] Andreas Kainz is creating Icons and UX designs for LibreOffice and KDE | Patreon
[3] LibreOffice White Sifr Icon Pack - Gnome-look.org
[4] /chapter: Interface-Basics / GIMP

1 Like

Hmm… It seems these icons are pngs located on my system in:
…\darktable\share\darktable\pixmaps\plugins\darkroom

Change the name of this folder and you effectively switch these icons off.

Simple. No need to write these out of the code at all. If you want the icons off by default then…

Well, I can’t imagine most of the dev’s don’t already know this

Thanks! Great look! Make the cursor bigger is a good choice, on the 2.6 version I have problems centering the cursor :slight_smile:

1 Like

Do the screenshots below from Lightable and Darkroom show the new expected appearance of the new GUI? I’m bit confused specially regarding Darkroom, which seems to show two different types/sizes of fonts…

I think it goes in wrong direction (at least, not in the direction I hoped it will go), sorry for that. I want to find a solution, not argue.

Anyway, I think, I found solution for the ‘missing icons’ problem. I can simply add:

background-image: url('path to module image');
background-repeat: no-repeat;
padding-left: 20px; //or something

on the #modulename #iop-panel-label.

Now, I cannot get ID of the specific module/iop AFAIK. I’ve hack this a bit using module->name() and it is working, so maybe I’ll write a few line of code in the next week.

2 Likes

Nice one.

I don’t know if it’s beyond the scope of what you’re planning but it’d be ideal if the path part of the url could be taken from the css…

I think some of the module names may be more of a problem in this regard. I mean, ‘contrast brightness saturation’ is a bit long winded isn’t it.

I’ve changed some of these by hacking the binaries but I don’t want to be doing that every time there’s a new version. So how about a way to change these names legitimately. A plugin name setting in darktablerc would be good.

And this works with which version of GTK ?

A post was split to a new topic: Darktable Raster masks explained

Tested only with 3.24.5 and 3.18. It works in both cases (except, It complains about min-width, min-height and :disabled pseudo class on 3.18). background-image with images url and background-repeat landed in GTK in 2011 according to the source code, so ~GTK v3.5.

CSS has always been more capable than one would expect, even the older versions. I am sure that a lot more could be customized. :sunny: