GNOME Bugzilla – Bug 407242
GtkScale: Up/Down keys decrease/increase value, which is opposite to expectation
Last modified: 2018-04-18 19:14:17 UTC
Please describe the problem: On a GtkHScale with focus, using the keyboard arrows to move the slider leads to strange behavior with up/down arrow keys. See for example the one on gnome-screensaver-preferences. Steps to reproduce: Actual results: If you press the left button, the slider moves left, decreasing the delay to show the screensaver. If you press right, you increase that same value. However, pressing up (wich conveys this idea of more/raise/increase), in fact it DECREASES the value, while pressing down will INCREASE the value. Expected results: Someone may see what is more logical with RTL languages. But in LTR, what makes more sense is: * right/up : increase the value * left/down : decrease the value Does this happen every time? Yes. Other information: Original bug: http://qa.mandriva.com/show_bug.cgi?id=27914 This is, indeed, much more annoying when refering to a partition size, at a stage (distro installer) where you may have no mouse working, but only keyboard.
Created attachment 95784 [details] [review] change behaviour of cursor key and mouse wheel movements in a right angle to a scales direction This patch should fix this bug. The patch also applies to mouse wheel movements. It changes the meaning of up/down movements on horizontal scales to higher/lower and of right/left on vertical scales to higher/lower. The change of cursor key behaviour applies to all widgets derived from GtkRange. The change of mouse wheel behaviour does not apply to scrollbars because I think there the current behaviour is right.
I've attached a patch that should fix this issue. It was diffed against gtk+ 2.10.13. If a patch against against current svn is desired I can supply that too.
any reviewers ?
*** Bug 688335 has been marked as a duplicate of this bug. ***
Guys, this is a bug on gtk3+ as well. David's patch was rebased and a changed a little. So, please, could someone review?
Created attachment 231865 [details] [review] gtkrange: fix behavior of keys and mouse scroll Now, the behavior is: - Horizontal: * increase the value: right, up, page_up, scroll_up * decrease the value: left, down, page_down, scroll_down - Vertical: * increase the value: right, down, page_down, scroll_down * decrease the value: left, up, page_up, scroll_up - Horizontal Inverted: * increase the value: left, up, page_up, scroll_up * decrease the value: right, down, page_down, scroll_down - Vertical Inverted: * increase the value: right, up, page_up, scroll_up * decrease the value: left, down, page_down, scroll_down Patch based in an old patch from David Riebenbauer
I don't think this correctly handles the Right-to-Left case. It just completely ignores the should_invert() stuff for horizontal ranges, which is not right. I.e. if a horizontal rtl widget is flippable then we need to do the inversion of left/right (although not on up/down). Also, isn't it wrong to always invert scroll wheel delta for horizontal ranges. Doesn't that depend on whether the scroll wheel even is vertical or horzontal?
Thanks Alexander for the review. I'll try to address your issues in another patch. I can't give you a timeframe right now, but I'm working on it.
Not sure if this bug is still active, but I think we're seeing the same problem in porting pnmixer to gtk3 (https://github.com/nicklan/pnmixer). In our case it manifests as having scroll wheel events move the slider in the wrong direction. That is, mouse wheel up will increase the value, but move the slider to the left, when it should move to the right, and vice-versa. Note that this behavior occurs with the horizontal slider in gtk3-widget-factory, so you can use that as a test case too.
Indeed, working on PNMixer right now. We have a slider that may appear horizontally or vertically depending on user settings. Here is the behavior I observe: - Vertical inverted * increase: left, up, page_up, scroll_up, * decrease: right, down, page_down, scroll_down To me the left/right is slightly confusing here. OK it's no big deal, when seeing a vertical slider I would never have the idea to hit left/right anyway, I would just use up/down. But I don't know how other users brain work :) - Horizontal * increase: right, down, page_down, scroll_up * decrease: left, up, page_up, scroll_down This is more of a problem. Even if the slider is horizontal, I would still think about rising the value with up, and lowering it with down. Seems logical to me, and probably to you too, right ? It's even more confusing since the mouse mapping is the opposite as the keyboard mapping... I can do more tests if you need. Is it acknowledged as a bug ? Is it worth I dig a bit into this and come with a patch ? Would someone review it ? Cheers !
*** Bug 720586 has been marked as a duplicate of this bug. ***
*** Bug 621898 has been marked as a duplicate of this bug. ***
While counter-intuitive, I doubt this can change in GTK+ 3. Maybe in GTK+ 4; I don't know.
See also https://bugzilla.gnome.org/show_bug.cgi?id=739806 which discusses the equivalent behaviour when scrolling.
(In reply to Arnaud Rebillout from comment #10) > Even if the slider is horizontal, I would still > think about rising the value with up, and lowering it with down. Seems > logical to me, and probably to you too, right ? It's even more confusing > since the mouse mapping is the opposite as the keyboard mapping... yup, put simply: pressing the Up key should increase the value, just like scrolling up does, and vice-versa. (In reply to Alexander Larsson from comment #7) > Also, isn't it wrong to always invert scroll wheel delta for horizontal > ranges. Doesn't that depend on whether the scroll wheel even is vertical or > horzontal? Albeit not directly related, this was a bug that I fixed by https://git.gnome.org/browse/gtk+/commit/gtk/gtkrange.c?h=gtk-3-22&id=91064360037fed243af588807e49e10ab6683dcb
(In reply to Alexander Larsson from comment #7) > I don't think this correctly handles the Right-to-Left case. It just > completely ignores the should_invert() stuff for horizontal ranges, which is > not right. > > I.e. if a horizontal rtl widget is flippable then we need to do the > inversion of left/right (although not on up/down). This isn't the case for Fabiano's patch, which does take inversion into account: in fact, it changes things so that we *only* care about inversion for horizontal keys if the range is horizontal, i.e. parallel to the pressed key - so we don't unexpectedly make the left (start) facing keys increase the value for inverted vertical ranges (but not non-inverted ones). It's good to ignore :inverted there, but IMO what it omits to consider is RTL on vertical ranges: Carlos and I were discussing this and feel that H scrolls on V ranges should probably honour RTL, so end/start respectively increase/decrease the value, not just always right/left. I would assume this also applies to the keys. If so, more work is needed to make this patch take that into account, and I think it'd probably be worth fixing the vert/RTL thing at the same time. In any case, a patch that changes behaviour - whether or not it's 'good', it is probably *expected* by now - seems too contentious to push to GTK+ 3 at this late a stage. Probably it should be GTK+ 4 only?
I think the best way to resolve this is to share the logic with a fix I've written (and am now exhaust(ive|ed)ly testing) to fix* directions of scrolls vs value movements, at Bug 791802. Once I've finished testing that, I'll probably just post the patches over there, and if accepted, they'll fix this one too. (Bug 739806 is not really related to this, as it's an inherent limitation of natural scrolling at present. Hopefully there'll be new protocol to let us fix that soon.)
*** This bug has been marked as a duplicate of bug 791802 ***
That bug fixed this in master, which will become GTK+ 4. At the moment, I'm not pushing this to GTK+ 3, as that is meant to be super-stable now, and there's concern that people by now have gotten used to the current key behaviour and would not welcome a change (even if it matches scrolling and is more semantically correct!)