Module Group Improvement Mockup

Should I create a new topic for this?

Anyway, this is a fast mockup, it’s really nothing major. It would probably require less work than the current system where you have an editor etc. Also here is a fast reasoning behind the idea (nothing in depth) just to get some quick feedback.

The thinking behind this is to show all modules by default and remove the option to hide and show modules. Currently we hide modules because we don’t use all of them and since we have only 3 module groups those modules that we don’t use really get in the users way.

Problems if we show all modules on the current system:

  • user has to scroll a lot
  • not used modules are obstructing users view (that’s why we hide them) and creating the mess b/c they are mixed with active modules in groups.

Even if the user hides the some modules, he still has too much of them in the groups for any particular image. And while he might not use all the modules in any one image, he generally uses them all when editing day to day.

Problems persist even if we hide some modules:

  • having too many not active modules mixed with active modules on any particular image
  • non active modules obstructing the access to the active ones
  • active modules making it hard to find a particular unactive module.
  • obviously not having quick access to the hidden module
  • Module discovery is greatly reduced (we all know users like to stick with defaults)

From the other apps we can see that they don’t hide the features. Photoshop, Lightroom, Capture One, Gimp, Krita afaik don’t hide any of their features. They do ofc have preferences but also a lot more features but they try to not hide any of it.

Since everybody would love to have node editor for Darktable but we are all also scared to actually do that radical change because that would potentially be the end of new users for darktable, let’s think how we can improve.

What do node editors usually have?

  • a menu of modules sorted in groups (many groups)
  • a node editor viewport where we place and connect nodes
  • assume in this case a node values editor where you edit settings of a particular node

So let’s create just that but instead of a node editor, a node/module list like it is now.

So this is how it would work. All the current groups would be just a place for 2 tabs, “active modules tab” and “all modules tab”. Inside the “all modules tab” there would be “module groups” with modules in them. Those couldn’t be edited and you couldn’t change their order in the “all modules tab” also you couldn’t see duplicate modules there, just a number of duplicates.

All editing would be performed in the “active modules tab”.

This would solve a problem where we would have all modules shown but any particular module would be easily discovered and found because there would be more module groups.

Right now to find a module you are searching it in the constantly changing module groups because they show duplicates and they show editing sliders, masks, everything so you will never be able to find your module by feel and quickly.

This would solve that, those module groups would not be changing as you edit, you wouldn’t see editing sliders, masks etc there. Just lists of modules.

And yes, I know a search bar exists and you can get to anything that way. Instead of defending myself against that argument that I’m sure someone will cling on to, I’ll just ask; then why do we even have any non active modules shown right now? So that’s answers that.

Anyway here is a mockup, anyway scales are a bit off, don’t worry about the icon design those are just meaningful placeholders etc but you’ll get the gist:

Another feature one might want to add is a context menu in the image viewport. I’ve notices right mouse click right now does nothing on the image anyway.

I’ve created a new topic for you :wink:


Nice, thanks!

Here’s another idea just for fun:

With this I think we could get rid of “all modules tab” altogether. I wouldn’t like that but it’s an option and even a better one I’d say since you aren’t getting away from the “active modules tab” ever. and are not clicking around with the mouse all over the screen. It’s very, very fast. But I know it’s not for everyone :slight_smile:

1 Like

So to make my edit I’m click the all modules tab, finding the right group, expanding that group, activating a given module, going back to the active module tab, possibly expanding that module again, then making my module adjustments?

Not necessarily. I’d hope when the user adds new module, he will be automatically jumped to the activate modules with that module already opened. I guess that behavior could be exposed in the settings. But I imagine this would be the default.

That’s just one click more from what we currently do. And you gain much more back. I’ll explain:

There is a trade-off because you have one extra click to get to the module to activate since you need to click on the “all modules tab” and the “group” (the group part is one extra click) but I think you’ll gain that speed right back and earn more with the consistent, not changing UI, no scrolling, without duplicate and expanded modules with fixed module order alphabetically (w/o affecting the pipeline) so you can develop muscle memory and memorize where everything is, it would be easier with more groups that make more sense and you’ll be flying trough those in no time.

Right now you can’t get that speed since the UI and lists are constantly changing as you edit. Also how would you get to the hidden module (not using search)? Also modules aren’t sorted alphabetically. It makes sense under the hood and in the active modules group, but in other groups it’s just a mess.

I think this makes sense, right?

That sounds confusing for new users… Also what if I want to turn on several modules at a time? Am I jumping back and forth?

Why is search not a valid way? Its what I was using for 3.2.1

The thing I really dislike about this proposal is that we are still showing every module. That is super overwhelming for new users and a criticism that darktable gets every time there is a review. IMHO, by default we should present a handful of modules for someone to learn at first, then they can go find whatever other module they need. We are closing in on that currently.

1 Like

No it doesn’t that’s literally how every other app does it. Only darktable duplicates UI 3 times between a group, favorite group and active group module. I think you are just used to Darktable module redundancy. But I don’t believe that’s the case with new users. Editing a same module/node in two/three places. I don’t know any other software that does that.

Maybe it doesn’t even need to be a setting in the settings to change behavior. A default one could be provided that would satisfy everybody.

  • If you want to jump right away you click the name, and if you don’t you click the + icon.


  • If you want to jump right away you click the left button, if you don’t you click the right one or the middle one.

Because that’s a wildcard. An argument could be made that we can get rid of everything and just use the search.

Is it? Can you really prove that?

Here’s my thinking.
A new user doesn’t know how to use Darktable anyway so he goes in the more modules trying to find familiar features or lightroom equivalents. There he is faced with an endless unordered list of modules without any descriptions as to what they do nor being sorted in any logical way.

If he just had a nice groups, then he could start making sense as to what each group is for and start to develop his own workflow.

In my proposal, he would have these nice tooltips already available for all modules in the groups and he could take advantage of the online help questionmark shortcut.

Whatever you do it won’t be good if you are doing it by hiding features and forcing users into a particular workflow. Photoshop doesn’t have a noob UI for new users. Especially not as the default.

Here we are venturing into onboarding which is non existent in Darktable. omg, I have so much more ideas right now to address the issues you’ve raised. I’ll stop editing this comment and will wait for more feedback :sweat_smile:

1 Like

My gui solution would be this:
Tab 1: pipeline
Tab 2: adjust (or properties)
Tab 3: mask

Tab 1 is like ‘active modules’ now, albeit with ‘inactive modules’ showing as well (but only those added by the user, not every module in dt). It would be exactly like Photoshop layers, which are easy to navigate and many new users would be familiar with. Turning a module off wouldn’t make it disappear, and you wouldn’t have to go hunting through various tabs to find modules you tried, but turned off. Default modules could be the main ones in scene-refferred pipe. Underneath this would be buttons for styles, pipe order, load favourites, and ‘modules’ menu, which opens up complete list of modules, split into categories. Search bar stays, but shows you items in the menu. Making adjustments would not happen in tab 1. This avoids all the scrolling of current design.

Tab 2 is where adjustments are made - moving sliders etc… Again, like Photoshop ‘properties’. Say what you like about that program, but their layers interface is tidy and easy to follow. When you open a module from menu, it automatically turns on and takes you to tab 2, to save the inevitable clicking to get there. You can also turn module on/off from tab 2 so you don’t have to keep revisiting tab 1.

Tab 3 is for all the masks. Separating these again negates all the scrolling.

I personally don’t mind how the modules in menu are grouped - I use favourites and search bar. Splitting things into categories like ‘sharpening, denoise, colour, tone, etc…’ seems easier to understand than the new grouping, albeit with the drawback of many modules belonging in multiple categories. But if modules were simply a name in a menu, instead of a module to be opened and adjusted in a tab, then having it appear in multiple categories would be less of an issue.


I like it but masking is a whole other beast. I wasn’t even considering touching that in the module groups feature request or idea.

Btw are you saying that mask manager should be on the Tab 3 or all the modules with masks etc? I don’t quite get it, any visuals?

Won’t have time today to do a mock up on Christmas, but maybe tonight.

I mean mask manager (pushing sliders, drawing shapes, etc) is in tab 3. You would only show the masking options for currently selected module in tab 1 (pipeline). Just as tab 2 (adjust) would only show adjustment options for currently selected module.

I dont know the code complexity of splitting things up in gui this way. If it doesn’t work then you could not worry about tab 3, and put the masking options in tab 2.

It is fine as is. The current layout isn’t unreasonable. Open to refinement but not drastic changes. BTW, yours is similar to Photivo.

Yes you can start with the recent fstoppers article, then jump to the petapixel one, then into the dpreview forums if you can stomach that. Its a constant criticism, too many modules and too many modules that duplicate functionity. I find them both to be valid criticism. But we can’t just get rid of modules.

I disagree. I think new users would be delighted to find a handful or two of modules and some instruction on how to apply them. We should push new users into the scene referred workflow. Do we give them base curve just because we have it? No way!

The “guide on how to apply modules” is already underway in the new dtdocs project, which has reorganized the user documentation and added sections on how to apply modules.

Great, write it down and let’s get it into an issue.


Actually on a second thought, I disagree myself. It’s really an onboarding issue there.
there should be an onboarding window at first launch. That might solve at least some issues for the new users and a user should be able to choose the “UI level” from there.

I have ideas but I’d like to do a mockup again first as I’m just getting lost in my own thoughts when describing.

1 Like

I like this idea! Please do not let it die.

I’m kind of lost here trying to figure out what this is all about. Maybe someone can clearly state what problem is being discussed? Are we trying to make darktable look like photoshop or photivo? Are we trying to see how many tab changes we can make while using one module? Are we trying to make darktable easier to use or harder to use? I’m thoroughly confused.

The other thing I’m confused about is that darktable’s been released for less than 24 hours and there is a discussion about changing the interface. Has anybody had a chance to use it yet or did everyone take one look and decide it should be changed?

Personally I like the new interface. I’ve been using it for several months because I compile daily. I’ve a few modules spread between 4 tabs. The most used modules are in the first tab and I keep filmic, exposure, and crop and rotate open all the time, since it’s what I use most. I simply move my mouse up and down and make the edits I want. No scrolling, no tab jumping. It’s simple. The other tabs have modules grouped together that I use together. If I need to do more processing to achieve the look I want, then I go to another tab that has already open modules and do what needs done. I also have some styles for noise reduction and desaturating certain problem colors that I apply when I need to, so most of the time I never leave the first tab.

I don’t have a magic tab yet :smiley:, but I think I probably need to create one.

If it’s ease of use, or simplifying for new users, then create presets with just a few modules. Write a tutorial. Make a video, or suggest one to Bruce Williams. By the way, did anyone try the workflow beginner or workflow scene-referred presets?

And finally when expressing an idea it would help if what you’re trying to express is clear to you, so that others might find it clear too.


It’s about being late to the party but partying anyway if that makes sense?

Yes, I use nightly repo but granted, I’ve been changing the groups to the old way so I can’t say I’ve given a fair chance to the new one. Be that as it may, these mockups address issues present in both old and new module groups.

I’m sorry for that, I should have involved myself into the discussion earlier. Since I haven’t, I’m doing it now. Just to give out my thoughts if nothing. I know nobody in their right mind will now change all the work they’ve done for this release but I’m providing an idea and mockups anyway.

It is perfectly clear to me but can’t possibly know if the same thing would work that well for others. Someone might make a better suggestion I haven’t thought of yet so that’s the purpose of this thread.

I’m glad that you do, I think I can get use to it too but it’s not really addressing any issues from the old interface. All of the problems remain. That may just be my opinion, but I’ve used DT a lot and I’m comfortable proposing a different UI.

I love that I can hide modules. I only use 18 on a regular basis so hiding the other 50 or so makes it much easier and less confusing. There are modules I would never use so hiding them is perfect. If I need them I can search for them, which is now even easier to use given searching for say “saturation” shows me all the modules relating to saturation.

I’ve taken the new “workflow scene referred” and tweaked this to my liking. So I now have 3 groups, base containing 9 modules, colour with 4 and other with 5.

I only use the active group to move the sequence of modules, which is by exception.


Ok here is my mock up gui. Current gui is perfectly workable, devs have done an amazing job, but I enjoy the discussion and might as well contribute while its here. This would be my ideal.

What problems does it solve? Well, not so much problems, but annoyances:

  1. Too much scrolling
  2. The same module appearing in multiple different places
  3. Modules that have been turned on and thus added to the ‘active modules’ section disappearing from that section after being turned off, requiring a search to find again.



*Only three tabs up the top (pipeline, adjust, mask). Current selected tab is ‘pipeline’.
*Modules menu, styles, reset and pipeline order presets below. [Not included here, but possible to add: A button to load favourites].
*The ‘inactive’ modules - those that have been added to the pipeline, but turned off, remain visible (so it is quick and easy to turn them back on again if desired).
*Modules cannot expand to show their adjustments (sliders, etc…).
*Selected module (module clicked) is highlighted - in this instance, it is filmic

User actions:
*Double clicking a module opens ‘adjust’ tab for that module. Clicking ‘adjust’ tab will do this for selected module.
*Some other click (eg. cntrl+click) opens ‘mask’ tab for that module. Clicking ‘mask’ tab will do this for selected module.



*Here we have the adjustments (sliders, etc…) of the selected module.
*Module can be turned off/on to see effect, easy access to presets, reset, etc…



*Here we see all the mask and blending options

Modules Menu:


*Clicking modules menu at bottom of screen brings up the list of categories (such as technical, grading, effects, or whatever they may be), and hovering over ‘category name’ reveals modules in that category (such as filmic, base curve, tone curve, etc…)
*Clicking on a module adds it to the pipeline, turns it on, and takes you to the ‘adjust’ tab. Modules menu disappears. [Maybe a cntrl+click if you want to add module to pipe but menu to remain, so you can add another module]
*Search bar has been moved here, and will find the module in the menu. It is not needed in old location, because all modules that have been added to the pipeline will be clearly visible in ‘pipeline’ tab. As items are typed, nearest match is highlighted in menu. Up down left right arrow keys can scroll through options. [Alternately, search could be kept in old location, but call the menu when typed. One less click. And hitting enter on current highlighted module could add it. No clicks. If typed module is already in pipe, it could perhaps open in ‘adjust’ tab.]

Default pipeline modules already there to start could be scene-referred, or display-referred (user choice in preferences), and of course, any combination could be easily loaded in one click as a style.

It can of course be made prettier, different icons, colours, etc… this is just to give an idea.

1 Like

Maybe not?

There isn’t a favorites group anymore and maybe we should rename active modules to review and adjust pipeline, since that’s what it’s used for.

@KristijanZic how long have you been using darktable? How many images have you edited using darktable? How many images have you edited in darktable thinking “I wish I had this feature that was in the software I’m really familiar with”?

I started using darktable at version 1.4. I had no raw development experience. I’ve dabbled with rawtherapee, lightzone, art, etc. I’ve watched lots of videos with lightroom, looking for concepts not keystrokes. Thankfully @RobertHutton had made some videos about using darktable so I could start muddling my way through it. It took a year for me to figure out how to operate darktable, using those videos and a lot of trial and error. My editing skills still really sucked because I still didn’t have a good understanding of raw development and how to use the tools skillfully, so one day I decided to learn Lua and write the Edit with GIMP script, since I knew how
to process images in GIMP and achieve the results I wanted. After years of using darktable, I can easily achieve pretty much any look I desire, because my skills have grown and the tools have improved. At this point my database contains ~500,000 images and I’ve edited 50,000+ of them. So at this point I know 50,000+ ways to edit an image and probably 35,000+ ways not to edit an image in darktable.

What point am I trying to make? Let’s say you’re a lightroom user and you’ve edited 10,000+ images. What you’ve learned is 10,000+ ways to not edit an image in darktable. Until you’ve edited a lot of images in darktable, using darktable as it is and not wishing for something else, then you don’t really understand the interface and what it’s shortcomings are. In other words, you need to know what’s broke, so you can think about how to fix it. Then learn a programming language that you can build user interfaces in (maybe python), and code up your ideas and click the buttons, move the sliders, change the tabs and see if any of your ideas still make sense. Probably what you’ll find is some are good, some are bad, and some you’ll wonder what you were thinking. User interface design is iterative. You code, you test, you fix. Sometimes you redesign and try again.

If you truly want to convince people that the user interface needs changed, and that developers should spend hundreds of hours doing it, then you’re going to need something that people can play with and see if they agree with your ideas.

A couple of years ago @aurlienpierre decided that color processing could be better in darktable. He learned to program in C, dove into the code, added color features that are incredible, and has become one of the top developers.

4 years ago I wanted a feature in darktable, so I learned Lua and added it. Since then I’ve added lots of features in the lua-scripts, become the lua guy as far as the C code is concerned, and I help maintain the lua-scripts repository.

There’s room for you to become the interface guy. Learn to code and build interfaces and step up to the table. But, I have a request. If you want to redo the UI, start with a pile of modules on one side and a finished image on the other, and come up with a way to get from the pile to the image, or come up with a way to get from the image to the pile (because sometimes it’s easier to work the problem backwards). Don’t make it look/work like lightroom, capture 1, affinity, rawtherapee, art, lightzone, photoshop, GIMP, etc.

You should also probably prepare yourself for when you present your design/prototype, because you’ll hear they don’t like it, it’s not pretty, they can’t understand it, it’s different, it’s not Tuesday, etc, etc, etc, etc, etc.


We should also understand that these types of discussions and asking questions are normal when implementing any kind of feature. Before any code is written or changed, it should be 100% clear what is going to need to be coded.