basics widgets: Reordering the sliders

[paul-pw]

Is your feature request related to a problem? Please describe. when editing an Image in the basics widgets group, I want to first adjust the exposure, then maybe the saturation, then do some kind of Highlights adjustment.

Describe the solution you'd like To make my workflow faster, I'd like to be able to reorder the sliders in the basics widgets to suit my workflow (exposure slider at the top, then saturation...)

Additional context I'm not talking about reordering the pixel Pipe. Just about being able to reorder the sliders in the basics widgets for a better workflow (which may not be following the pixel pipe from bottom to top.)

[Nilvus]

I'm not talking about reordering the pixel Pipe. Just about being able to reorder the sliders in the basics widgets for a better workflow (which may not be following the pixel pipe from bottom to top.)

Yes, but all darktable modules are ordered regarding the pixel pipe, like layers. And it's the same in basics for consistency. So changing it would break the darktable logic. And it's important as it is logic. In software like Photoshop or Gimp, we don't change layers regarding how we process images but in logical display order. That's the same in darktable, in all darkroom tabs.

[parafin]

Dunno, I think it should be allowed here, because it would serve the purpose of this feature IMHO.

[ptilopteri]

I would also like this, a "visual" change in the widget, order of sliders, and not a procedural change.

would be handy.

[paul-pw]

Yes, but all darktable modules are ordered regarding the pixel pipe, like layers

IMO the basics widget is just a pretty interface for the real stuff: the modules. As I understood it, the purpose of the basics widget is about simplifying the editing for new users and speeding up the workflow of more experienced users. And being able to reorder the sliders in the basics Widget would improve both purposes.

I don't have any experience in UI/UX but I think this kind of thing could be implemented in the "manage presets" menu of the modules. Any other Ideas how to implement this from a UI/UX perspective? (maybe ctrl-shift click and drag?)

[Nilvus]

The main downside I see is that it could confuse many users. Moving them in all tabs is pipe order, so having a different tab with a different logic will not help. @paul-pw: shift+ctrl+drag&drop is already used to move module pipe order in other tabs)

Apart of that, and that's a big point I think, you're right, this part is different than other tabs. But we need to avoid confusion to users. Not so easy. Considering your arguments, It could be the good place to not use pipe order to display sliders, but how we deal with other tabs and avoid confusion? That's the main point if we want that.

@AlicVB: as you write this part, what's your view on that?

[AlicVB]

Well, I agree that it would be handy and it's the only place where it's doable, due to basic widgets limitations (esp. the fact that there's no multi-instance) But, like @Nilvus, I'm not really in favor of doing that for the following reasons :

• consistency between the different dt parts
• pipe order is important to understand what happen when and so to understand what you're doing...
• evolution of the basics widgets features (what if one decide to add multi-instance at some point ?)
• risk that some users misuse the basics widget to "replicate" classic modules. After all, you add a fold/unfold feature to the module name line, and you have some sort of "cheap" module replication. And that's absolutely not what we want imho, as that will only cause some more confusions incomprehension, features requests or issues, etc...

That said if there's a consensus on this, and we are able to clearly define the "red" line, I won't oppose ;) For the implementation, we have to keep in mind following things :

• we need to have 2 "sorting order" : automatic, to follow pipe order and manual, as defined by the user and don't follow pipe order.
• we need to take care of the case where there's multiple widgets of the same module.
• as @paul-pw said, the best place imho is in the preset manager, not directly on screen.

[paul-pw]

having a "sorting order: manual" and a "sorting order automatic" should be quite simple.
Having multiple widgets is the more difficult part.

The problem is if we have duplicated modules, how do we decide if one included in the "basics widgets"

Solution 1:

• just include every duplicate of the selected widgets in the basics widgets tab. (say i have the exposure module 2 times: it would also show up 2 times in the basics tab)

Problem:

• might be confusing to some people.
• What if I only want to see a few of multiple duplicates in the basics tab. (quite an edge case)

Advantage:

• less setup effort for the user.

Solution 2:

• allow adding multiple instances of one module already from the module presets manager
• now the user can specify which sliders of which modules they want to see in the basics tab from the presets manager.

Problem:

• "why do I have two instances of exposure after selecting this module preset?"
• might be even more confusing to some people in the beginning

Advantage:

• more control over what shows up in the basics tab

another note: having the module sort order also moved to the modules presets manager would help define which duplicated module goes where (having a sort order with 2 times exposure doesn't define which of the two exposure modules goes where in the pipe right now) but this is probably highly controversial and better be discussed some other time

---

both of those solutions don't discuss how to deal with a custom module order. but with solution 2 it should be possible to deal with multiple modules and a manual sort order in the basics tab.

as a UI, I think having a drop-down next to the + of the basics tab in the preset manager with "automatic sort order" and "manual sort order" and then arrows (if manual sort order is selected) to move the modules in the basics tab up and down could do the trick.

[AlicVB]

Well, maybe I was not clear enough (sorry for my English) : currently, if there's multiple instances of a module, corresponding basic widgets are disabled on purpose. What I've said, is just that if we go with custom ordering, this will make very difficult and tricky to eventually add this feature in the future

Now I repeat, I would prefer to avoid all this, as it may cause more confusions and frustrations for users than anything...

[parafin]

Maybe I'm missing something here, but what is the idea behind basics widgets? I always thought it was about customized GUI module that could accommodate user's workflow. Order of the widgets is IMHO an important feature to that end. Otherwise it looks like work just stopped half-way...

So regarding multiple instances - most obvious solution is to mark widgets with iop name somehow (if iop does have multiple instances), then custom ordering doesn't matter.

[paul-pw]

@AlicVB

• evolution of the basics widgets features (what if one decide to add multi-instance at some point ?)

• we need to take care of the case where there's multiple widgets of the same module.

I know that multiple instances of one module is currently not suportet by the basics tab. But that was not my point. I tried to propose a solution on how this might be possible in the future and not be conflicting with a "manual" sort order in the basics tab.

@parafin

Otherwise it looks like work just stopped half-way...

have to agree with that. At the moment the basics tab is Just the enabled modules tab simplified and with a pretty UI. That is already pretty great. but having a manual sort order would just make it that much more usefull for me and probably for many more people as well.

[AlicVB]

Here's the "historic" of this feature :

1. providing a replacement to the basic adjustment module. This module has serious conception problem, esp. due to the fact that it put at the place in the pipe action which should happen at different places (@aurelienpierre can explain that better than me) Not to speak that it mainly duplicate algorithms already present in other modules. So the idea was to propose a gui with widgets linked to different modules.
2. then it has been extended to propose some sort of "gui" shortcuts for a few widgets (each module was responsible to decide which widgets to propose)
3. then it has been extended to propose directly all registered bauhaus widgets, like we do for shortcuts.

So at this stage, basics widgets can serve as an "entry door" for beginners as well as a gui for a quick access to some modules widgets often used for more experienced users (like GUI shortcuts). But that should not replace modules : that's why we don't have added masks, presets, multinstances, etc... That's why as soon as there's multiple instances of a module, this feature is disabled...

Now don't get me wrong, I agree that reordering here could be handy, and coding that should be quite easy, but we absolutely need (imho) to first decide of what to do with at least the following points :

1. how to keep consistency and avoid confusion for "average" users regarding the pipe order (the fact that basics widgets may have different order than modules, the fact that reordering basics widget is not the same than reordering modules, the fact that pipe order matters in final rendering but not click order, ...)
2. how to avoid basics widgets feature to become an "out of control" monster ? (yes it's exaggerated, but once many user will be used to misuse this feature, what will happen ?) There's already quite some pressures from users to have module reordering regardless the pipe order, I fear that basics widgets could become an "alternative" for them...

That's because I'm not able to propose correct answer to those points, esp. 1. that I'm in favor of reordering, but let's see other opinion...

[parafin]

I myself don't think there's any confusion - if we take analogy to basic adjustment module - order of controls inside the module have no effect on processing. So it's hard for me to propose solution for this, but I'll try - how about adding a button that will quickly trigger the sorting order between pipe and custom? That will, I think, convey the message that custom widget order has no effect on actual processing - clicking that button won't change the image, only the GUI appearance.

[github-actions[bot]]

This issue did not get any activity in the past 30 days and will be closed in 365 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.