Project

General

Profile

Bug #11818

Unintuitive user interface behaviour in darkroom modules

Added by Heiko Bauke 5 months ago. Updated 4 months ago.

Status:
Triaged
Priority:
Low
Assignee:
-
Category:
Darkroom
Target version:
Start date:
11/14/2017
Due date:
% Done:

20%

Affected Version:
git master branch
System:
all
bitness:
64-bit
hardware architecture:
amd64/x86

Description

Recent changes in the user interface (see bug #11815 and related) still do not prevent unintuitive user interface behavior in darkroom modules.

Example 1:
  • Open the »base curve« module.
  • Reset to the defaults.
  • Choose »three exposures« from the »fusion« menu via left mouse click.
  • After pressing »three exposures«, the popup menu immediately disappears. The mouse courser is now over the »exposure bias« slider, which gets also changed (because mouse button is still pressed) to a value that depends on where exactly one has clicked on »three exposures«. I think this is a undesirable behavior.

I was able to fix this by

diff --git a/src/bauhaus/bauhaus.c b/src/bauhaus/bauhaus.c
index 29d9787c6..006da7358 100644
--- a/src/bauhaus/bauhaus.c
+++ b/src/bauhaus/bauhaus.c
@@ -440,7 +440,7 @@ static gboolean dt_bauhaus_popup_button_press(GtkWidget *widget, GdkEventButton
   {
     dt_bauhaus_widget_reject(darktable.bauhaus->current);
   }
-  dt_bauhaus_hide_popup();
+  // dt_bauhaus_hide_popup();
   return TRUE;
 }

@@ -600,8 +600,8 @@ void dt_bauhaus_init()
                    G_CALLBACK(dt_bauhaus_popup_button_press), (gpointer)NULL);
   // this is connected to the widget itself, not the popup. we're only interested
   // in mouse release events that are initiated by a press on the original widget.
-  // g_signal_connect (G_OBJECT (darktable.bauhaus->popup_area), "button-release-event",
-  //                   G_CALLBACK (dt_bauhaus_popup_button_release), (gpointer)NULL);
+  g_signal_connect (G_OBJECT (darktable.bauhaus->popup_area), "button-release-event",
+                    G_CALLBACK (dt_bauhaus_popup_button_release), (gpointer)NULL);
   g_signal_connect(G_OBJECT(darktable.bauhaus->popup_area), "key-press-event",
                    G_CALLBACK(dt_bauhaus_popup_key_press), (gpointer)NULL);
   g_signal_connect(G_OBJECT(darktable.bauhaus->popup_area), "scroll-event",

But I am not sure if this is the right way to fix this. I am not a GTK expert.

Example 2:
  • Open the »base curve« module.
  • Reset to the defaults.
  • Choose »three exposures« from the »fusion« menu via arrow-up and arrow-down keys plus enter.
  • Hover the mouse over the »exposure shift« slider and change the slider via mouse wheel.
  • Pressing arrow up button now will not adjust the »exposure shift« slider, as one might expect, instead values of the »fusion« menu are changed.

(Contrary, changing the value of the »fusion« menu by hovering over this menu and using the mouse wheel transfers keyboard focus to the »fusion« menu such that further changes to the »fusion« menu via the arrow keys are possible, which exactly what I would expect.)

Example 3:
  • Moving keyboard focus to sliders is kind of difficult/odd. I see several options, all have mostly unintended side effects:
  1. Mouse click left on a slider gives keyboard focus to sliders but also set the slider to a value that corresponds to the click position.
  2. Double mouse click left resets the slider, but also gives keyboard focus to the slider. Resetting the slider is not desirable if only minor adjustments are intended.
  3. Mouse click right opens the bent-curve popup, a second right mouse click closes the popup and finally gives keyboard focus to the slider. I really do not what to click twice just to be able to make fine adjustments to a slider via arrow keys.

Related issues

Duplicated by darktable - Bug #11789: Clicking an option on a popup menu also clicks the option beneath the menu Duplicate 10/26/2017

Associated revisions

Revision ba338e07
Added by Tobias Ellinghaus 4 months ago

Some fixes to bauhaus sliders as suggested by Heiko

This is more or less what Heiko Bauke suggested in bug #11818.

History

#1 Updated by Roman Lebedev 5 months ago

Heiko Bauke wrote:

Recent changes in the user interface (see bug #11815 and related) still do not prevent unintuitive user interface behavior in darkroom modules.

Example 1:
  • Open the »base curve« module.
  • Reset to the defaults.
  • Choose »three exposures« from the »fusion« menu via left mouse click.
  • After pressing »three exposures«, the popup menu immediately disappears. The mouse courser is now over the »exposure bias« slider, which gets also changed (because mouse button is still pressed) to a value that depends on where exactly one has clicked on »three exposures«. I think this is a undesirable behavior.

Which system, which display manager? Wayland?
Does not happen here with normal X + KDE

I was able to fix this by

[...]

But I am not sure if this is the right way to fix this. I am not a GTK expert.

Example 2:
  • Open the »base curve« module.
  • Reset to the defaults.
  • Choose »three exposures« from the »fusion« menu via arrow-up and arrow-down keys plus enter.
  • Hover the mouse over the »exposure shift« slider and change the slider via mouse wheel.
  • Pressing arrow up button now will not adjust the »exposure shift« slider, as one might expect, instead values of the »fusion« menu are changed.

(Contrary, changing the value of the »fusion« menu by hovering over this menu and using the mouse wheel transfers keyboard focus to the »fusion« menu such that further changes to the »fusion« menu via the arrow keys are possible, which exactly what I would expect.)

Example 3:
  • Moving keyboard focus to sliders is kind of difficult/odd. I see several options, all have mostly unintended side effects:
  1. Mouse click left on a slider gives keyboard focus to sliders but also set the slider to a value that corresponds to the click position.
  2. Double mouse click left resets the slider, but also gives keyboard focus to the slider. Resetting the slider is not desirable if only minor adjustments are intended.
  3. Mouse click right opens the bent-curve popup, a second right mouse click closes the popup and finally gives keyboard focus to the slider. I really do not what to click twice just to be able to make fine adjustments to a slider via arrow keys.

IMHO the recent changes to this arrow handling should be reverted.

#2 Updated by Heiko Bauke 5 months ago

Hi,

Roman Lebedev wrote:

Heiko Bauke wrote:

Recent changes in the user interface (see bug #11815 and related) still do not prevent unintuitive user interface behavior in darkroom modules.

Example 1:
  • Open the »base curve« module.
  • Reset to the defaults.
  • Choose »three exposures« from the »fusion« menu via left mouse click.
  • After pressing »three exposures«, the popup menu immediately disappears. The mouse courser is now over the »exposure bias« slider, which gets also changed (because mouse button is still pressed) to a value that depends on where exactly one has clicked on »three exposures«. I think this is a undesirable behavior.

Which system, which display manager? Wayland?
Does not happen here with normal X + KDE

I tested again under Ubuntu 17.10 64 bit with Ubuntu desktop (a slightly modified GNOME 3) with Wayland and (alternatively) X.org. The described behavior can be observed if the Wayland display server is used, but not with the X.org display server.

#3 Updated by Roman Lebedev 5 months ago

Heiko Bauke wrote:

Hi,

Roman Lebedev wrote:

Heiko Bauke wrote:

Recent changes in the user interface (see bug #11815 and related) still do not prevent unintuitive user interface behavior in darkroom modules.

Example 1:
  • Open the »base curve« module.
  • Reset to the defaults.
  • Choose »three exposures« from the »fusion« menu via left mouse click.
  • After pressing »three exposures«, the popup menu immediately disappears. The mouse courser is now over the »exposure bias« slider, which gets also changed (because mouse button is still pressed) to a value that depends on where exactly one has clicked on »three exposures«. I think this is a undesirable behavior.

Which system, which display manager? Wayland?
Does not happen here with normal X + KDE

I tested again under Ubuntu 17.10 64 bit with Ubuntu desktop (a slightly modified GNOME 3) with Wayland and (alternatively) X.org. The described behavior can be observed if the Wayland display server is used, but not with the X.org display server.

Yep, there is a reason the wayland is blacklisted
https://github.com/darktable-org/darktable/blob/bfe8004389fb1f4b0839eaeae969fb74dac10df7/src/common/darktable.c#L769-L774

#4 Updated by Tobias Ellinghaus 5 months ago

I can trigger 1) if i click the list entry, keep the mouse button pressed and move the mouse around with the button still pressed.
Regarding reverting, I'd rather remove the whole arrow key thing. It's causing more harm than good. The best solution would be someone who knows GTK to come up with a proper fix/redesign.

#5 Updated by Roman Lebedev 5 months ago

Tobias Ellinghaus wrote:

I can trigger 1) if i click the list entry, keep the mouse button pressed and move the mouse around with the button still pressed.

Regarding reverting, I'd rather remove the whole arrow key thing. It's causing more harm than good. The best solution would be someone who knows GTK to come up with a proper fix/redesign.

This particular regression you will be able to fix by adding `gtk_widget_grab_focus()` or something into the `dt_bauhaus_*_scroll` callbacks, i guess.

#6 Updated by Tobias Ellinghaus 4 months ago

  • System changed from Ubuntu to all
  • % Done changed from 0 to 20
  • Status changed from New to Triaged

I think point 1 and 2 are solved now. If you have any idea how best to solve number 3 – giving focus to the widget without clicking it – I'd be interested to hear about it. Currently I have no solution for that.

#7 Updated by Roman Lebedev 4 months ago

  • Duplicated by Bug #11789: Clicking an option on a popup menu also clicks the option beneath the menu added

#8 Updated by Heiko Bauke 4 months ago

Hi,

Tobias Ellinghaus wrote:

If you have any idea how best to solve number 3 – giving focus to the widget without clicking it – I'd be interested to hear about it. Currently I have no solution for that.

I built darktable from the current git master. Now focus is given to the slider by hovering the mouse over the slider. The problem is that the slider pointer jumps to the position of the mouse pointer immediately when the slider gets focus This behavior is worse than before. It is virtually impossible not to apply unintended changes. (Open the color look-up module (or any other module with several sliders) and move the mouse cursor from below the module upwards into the direction of the lightness slider and watch how the module's sliders jump around.) A possible solution might be:

  • Give the focus to the slider when the mouse cursor is above the slider but do not modify the slider pointer's position when the slider gets the focus.
  • Allow to change the slider pointer's position via the mouse wheel and arrow keys (as it is presumably the case now).
  • Allow to adjust the slider pointer's position via the mouse when the left mouse-key is pressed down while the mouse cursor is moved to the left or to the right. Adjust the slider pointer's position such that the horizontal distance between the mouse cursor and the slider pointer remains constant while the mouse cursor moves.

#9 Updated by Tobias Ellinghaus 4 months ago

I tried for a minute, moving the mouse over the sliders, but nothing happened. Did you also press some keys, mouse buttons, ...?

#10 Updated by Roman Lebedev 4 months ago

Heiko Bauke wrote:
...

...

Let me rephrase houz's confusion.
Does it still happen for you with normal X?

#11 Updated by Heiko Bauke 4 months ago

Roman Lebedev wrote:

Heiko Bauke wrote:
...

...

Let me rephrase houz's confusion.
Does it still happen for you with normal X?

I completely removed my darktabe installation, checked out git master, and recompiled from scratch. The problem (as described in my last post) has disappeared now. I can neither reproduce it under Wayland nor under X.org. I assume there was some kind of misconfiguration on my side. I will report if problems pop-up again.

#12 Updated by Tobias Ellinghaus 4 months ago

Thanks for checking!

#13 Updated by Roman Lebedev 4 months ago

  • Target version changed from 2.4.0 to 2.6.0

Also available in: Atom PDF