After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 125894 - GtkHScale: thumb is moved to wrong direction by key-pressing on BiDi locale
GtkHScale: thumb is moved to wrong direction by key-pressing on BiDi locale
Status: RESOLVED NOTABUG
Product: gtk+
Classification: Platform
Component: Widget: Other
2.2.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks: 76219
 
 
Reported: 2003-10-31 05:23 UTC by chinen
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed patch (based on CVS 2003/Nov/19) (2.65 KB, patch)
2003-11-28 05:11 UTC, chinen
none Details | Review

Description chinen 2003-10-31 05:23:56 UTC
Overview Description:
On the BiDi local, the Up (Ctrl-Up, PgUp) and Down (Ctrl-Down, PgDown) keys
move thumb of rtl GtkHScale in the wrong direction

Steps to Reproduce:
1. Run testgtk program in ./gtk+-2.2.x/tests on a BiDi locale (e.g. he_IL)
2. Press `range controls' button.
3. Set focus on GtkHScale widget.
4. Change value of GtkHScale using one of Up/Down keys.
   The thumb moves to reverse direction. <-- Problem!!

Actual Results:
Thumb of GtkHScale is moved to the left with *Up keys and to the right
with *Down keys

Expected Results:
Thumb of GtkHScale should be moved in the direction of Home with *Up keys.
It should be move in the direction of End with *Down keys.
When GtkHScale has rtl direction, Home is from the right and End is from
the left.

Additional Information:
We think the following steps would fix this issue.
1. Open gtk/gtkrange.c and see gtk_range_scroll().
2. When GtkScrollType is GTK_SCROLL_STEP_UP, GTK_SCROLL_STEP_DOWN,
   GTK_SCROLL_PAGE_UP or GTK_SCROLL_PAGE_DOWN, Delete the following code:

   |  if (should_invert(range))
   |     call_something()
   |  else

However, after the above-mentioned steps are applied, PageUp/PageDown keys
cannot move the thumb.
The reason why they can't do is that they are interpreted twice.
(On non-Bidi locale, the thumbs moves every other places.)
  PageUp:   GTK_SCROLL_PAGE_LEFT and GTK_SCROLL_PAGE_UP scroll types
  PageDown: GTK_SCROLL_PAGE_RIGHT and GTK_SCROLL_PAGE_DOWN scroll types

If this double handling itself is designed behavior, we suppose
the value of the last argument of add_slider_binding() for PageUp/Down
should be replaced at gtk_scale_class_init() in gtkscale.c:
  PageUp:   GTK_SCROLL_PAGE_LEFT  --> GTK_SCROLL_PAGE_BACKWARD
  PageDown: GTK_SCROLL_PAGE_RIGHT --> GTK_SCROLL_PAGE_FORWARD
Comment 1 chinen 2003-11-21 02:32:17 UTC
We prepared a patch for this issue.
Could you please look at it?

  http://www-124.ibm.com/developerworks/oss/linux/patches/?patch_id=1206

Thank you,
Comment 2 chinen 2003-11-21 02:43:03 UTC
Sorry. I forgot to clarify which version the patch is effective for.
We created the patch based on CVS tree on 2003/Nov/19.

Thanks,
Comment 3 chinen 2003-11-28 05:11:01 UTC
Created attachment 21879 [details] [review]
Proposed patch (based on CVS 2003/Nov/19)
Comment 4 chinen 2003-11-28 05:14:29 UTC
I'd like to attach a patch here.
It is the same one as the patch at the above-mentioned URL.

Thanks
Comment 5 Matthias Clasen 2003-12-13 01:38:59 UTC
This is behaving as designed. There are visual and logical keybindings
on GtkRange.
left, right, up, down are all visual, up==left and down==right
home, end, +, - are logical keybindings which change direction with
the text direction
Comment 6 Semion Chichelnitsky 2003-12-14 10:31:09 UTC
I can't agree here. In case of horizontal range up==left and 
down==right only for ltr direction. Up and down should be logical.
Question about PgUp and PgDown remains open. If double moving of 
thumb is designed?