Darktable: Uniform module focus handling

[aurelienpierre]

What is focus ?

Focus is an internal GUI state flag that tracks which part of the GUI (module or else) is capturing events like key strokes and shortcuts.

Why is it important ?

Modules like crop and rotate or tone equalizer change their behaviour when they get the focus. Crop and rotate will show the whole image with framing guide when it has the focus, tone equalizer will replace the default cursor with its own interactive exposure cursor.

How is focus assigned ?

The last module that got user interaction gets the focus. The interaction needs to be a click over the module frame, which is a problem since most modules are packed with controls. Also, a click on the module header will collapse/expand it, and require a second click.e problem is t

What are the current solutions ?

Several attempts have been made to make focused module appear more clearly in UI (#5091 and #4927) and to assign it upon user request (#5041).

They are bad for 2 reasons :

1. focus is a state flag for developers commodity, not something users should be bothered with,
2. keyboard shortcuts are supposed to be faster ways to achieve something doable otherwise through the GUI, not the only access to core features (think touchscreen).

Proposal

For all modules

• Single click on module header should give the focus to the current module instead of collapsing/expanding it, as it is customary in all OS when clicking on windows.
• Collapse/expand module should be reassigned to double-click, which is the universal "open that shit" message through all OS, and optionnaly to Alt+Click as an alias, to avoid the constant pain of double-click.
• Having the focus or not should not change the view (crop, resize, rescale, distort) but only decide on the active tools available (cursor or control nodes over the view).
• Focus should not depend on collapse state.

For cropping and framing module

• Commiting frame bounds should not be made when focus is lost. It's too brittle and unpredictible.
• For perspective keyframe editing and cropping bounds editing:
  
  
  
  • buttons should be present in module to request editing mode (control nodes over the full-frame original image),
  
  
  • only when editing mode is enabled, the view will be changed to full frame and control nodes and guidelines will be presented,
  
  
  • editing mode will be exited upon user request with "Cancel" and "Ok" buttons, shown in module (not in image) to commit or discard changes.
  
  
• Expanding or giving focus to the module will be a no-op on the view until controls are explicitly required, in a similar manner to the perspective auto-correction module.

[elstoc]

I generally agree with you that the current solution is a bit of a compromise. A couple of initial thoughts...

focus is a state flag for developers commodity, not something users should be bothered with

Single click on module header should give the focus to the current module

You're trying to have it both ways here. Either focus is something the users shouldn't be bothered with or users should be able to assign focus with a click. If the latter, then having some way to indicate which module has focus is useful (window managers generally change the colour of the header bar but that's not the only way to do it)

double-click, which is the universal "open that shit" message through all OS

Is it though? Outside of the specific examples of file managers (open files/directories/applications) and text editing (select word/make text editable) I struggle to think of any other applications that make use of double-click at all. If you're talking about expanding and collapsing things, the most common method is with an 'expander' icon on the header bar to minimise/maximise windows (or indeed with a single click). Single-click to expand a collapsed module doesn't feel like a problem, though it seems reasonable that a single-click on an expanded module might give focus, perhaps with double-click to collapse. If we have a header icon (a triangle pointing up/down to indicate whether the module is currently expanded/collapsed) that's the single-click alternative.

Focus should not depend on collapse state.

Perhaps not, but some of the functionality associated with the focus does (tone equalizer)

[aurelienpierre]

You're trying to have it both ways here. Either focus is something the users shouldn't be bothered with or users should be able to assign focus with a click. If the latter, then having some way to indicate which module has focus is useful (window managers generally change the colour of the header bar but that's not the only way to do it)

Showing focus is fine, but asking users to willingly set it (and learn what it is) is not.

If you're talking about expanding and collapsing things, the most common method is with an 'expander' icon on the header bar to minimise/maximise windows (or indeed with a single click).

The expander icons were removed in dt 2.6 because modules already have 4 icons + a custom name in the header. Words are significantly longer in German or French, so the semi-standard 320px width gets fully used quite fast.

Perhaps not, but some of the functionality associated with the focus does (tone equalizer)

Forget what is done for now, that can be changed later. The matter is to have a consistent default.

[elstoc]

The expander icons were removed in dt 2.6 because modules already have 4 icons

Ok. Do we really need two different menus on the header? An alternative might be to combine presets and multi-instance menus into one.

[aurelienpierre]

If people have a lot of presets, that might result in an awful long menu. There is still the option of making menus hierarchical, but that doesn't solve the need for 2 clicks or more.

[elstoc]

Opening and closing a module should be a one-click operation too though. It's too common an activity to require double-click or alt-click. Modifiers and multi-clicks should be reserved for less common activities.

[aurelienpierre]

Giving focus should also be a one-click operation… Otherwise, we need sloppy focus (detect which module is hovered by the cursor and give it focus), which triggers another load of problems.

[elstoc]

Seems to me the solution to this is to stop modules having functionality that depends on gui focus then we can really stop caring about it. You've already suggested something similar for crop&rotate.

If a module has on-image interactive functionality (vignetting, crop & rotate, tone equalizer, graduated nd filter), it should be toggled on/off purely via an in-module control that can also be accessed from a keyboard shortcut.

[aurelienpierre]

Seems to me the solution to this is to stop modules having functionality that depends on gui focus then we can really stop caring about it. You've already suggested something similar for crop&rotate.

The case for crop and rotate is particular, since it commits changes silently when focus is lost, and changes the current view when it gets focus. Other modules simply take over the cursor, but nothing gets commited without interaction.

If you make access of specialized tools accessible upon click only, that's still an extra step each time.

[elstoc]

Ok how about:

• combine presets/multi-iop menus into a single hierarchical menu
• right-click accesses the full menu
• shift-right-click accesses presets submenu
• control-right-click accesses multi-iop submenu
• single click on a collapsed module expands it and assigns focus (and collapses other modules if user has set 'expand single module' preference)
• single click on an expanded module just assigns focus (perhaps then just click+drag can be used to reorder)
• reinstate the expand/collapse header button and use it to collapse the module

At the end of the day, if we want focus to be single-click and we want expand/collapse to be single-click, there's no escaping the need for another button. If we're not adding another button, then the modifier should be required for the less common operation (focus) and we're back to the status quo.

[johnny-bit]

The problem of focus + special case modules is weird from interaction design standpoint. darktable currently has just a handful of special-case modules requiring focus and clever handling of focus states so it's more of general fix for special case instead of fixing special case...

Why not treat those modules as special case? Or better yet - design desired interactions from ground up? Like @aurelienpierre - forget what is now, focus on what shall be and get that one correct. No "cool/ hidden features/ easter eggs" etc. Everything should be in GUI and GUI is very precious resource...

So how about designing interaction for modules? Fewer clicks are needed, prior art (eg how special case modules work now in dt, how those work in other apps, how we should tacke it) etc...

[elstoc]

I think a lot of the drawn mask behaviour is also dependent on gui focus.

[GrahamByrnes]

Some of it: there is the issue of masks in the mask manager, vs masks in the host module (ie exposure, retouch etc). That's one point where it's easy to get lost between the two modules, one of which is responding to what you are doing in the other, but then changing the interactions if you move the focus.
It also relates to what @jenshannoschwalm raised a while back: there are all sorts of masks lurking in the mask manager that were cast-off during history compression, so you think you have one mask over on the right sidebar, then you click on masks and you find a dozen.

[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.