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 60690 - Behavior of left and right arrows strange when widgets are vertically aligned
Behavior of left and right arrows strange when widgets are vertically aligned
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
1.3.x
Other Solaris
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
: 106627 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2001-09-18 12:44 UTC by padraig.obriain
Modified: 2011-02-04 16:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch to make arrows not wrap (698 bytes, patch)
2003-04-02 19:06 UTC, Soren Sandmann Pedersen
none Details | Review

Description padraig.obriain 2001-09-18 12:44:27 UTC
Run the test program testgtk and click on "radio buttons" button.

Press Tab key to get focus to first button. Press right arrow key and focus
changes to second button. Press right arrow key again but focus does not
move.

Press Up arrow key to get focus to first button. Press left arrow key and
focus changes to third button. Press left arrow key again but focus does
not move.
Comment 1 Owen Taylor 2001-09-19 18:52:47 UTC
Basically,what is happening is that right takes you
out of the dialog to the right, you reenter from the left,
and when you enter a container and don't have more information
you enter in the middle.

gtkcontainer.c:old_focus_coords() is meant to handle situations
similar to this by getting "more information" by looking 
at the position of the last focus widget, but doesn't
seem to handle the case where you focus out of the window
and back in. I'm not sure how easy this would be to fix.
Comment 2 Luis Villa 2002-01-22 21:29:51 UTC
Adding GNOME2 keyword to all keynav bugs per sander's request. You can filter on
the phrase 'luis doing GNOME2 work' to catch all instances of this so that you
can ignore them.
Comment 3 Owen Taylor 2002-01-24 01:06:15 UTC
This is not simple to fix; we'd have to add a 

 _gtk_window_get_last_focus_widget() 

To get it right for gtkcontainer.c, and have to
export that to get it right in general. Since arrow
keys for navigating focus have all sorts of other
problems, moving it off the 2.0.0 milestone.
Comment 4 Pasupathi 2002-08-09 06:29:45 UTC
I don't see the above behavior anymore and seems to be fixed. But 
given the lifetime of the bug, not sure where and when it got fixed. 
Padraig or Calum: Can you confirm ?
Comment 5 Calum Benson 2002-08-09 10:29:53 UTC
pasu: I'm still seeing this in last night's build (9-Jul).
Comment 6 Calum Benson 2002-08-12 10:58:51 UTC
Oops, that's 9-Aug, not 9-Jul :)
Comment 7 Rich Burridge 2003-01-22 15:34:45 UTC
I think I'm now seeing this problem with gcalctool (a calculator
program). If you start gcalctool in basic mode, the "7" key 
initially has keyboard focus. Keep hitting the right arrow key and 
the keys to the right of it are selected (correctly), but after
the "Clr" key, the next one selected is "0", where I was expecting
either "7" or "4" (not sure what the spec. says).

Owen, is there anything I can do programatically to work around 
this if it's really hard to fix? 
Comment 8 padraig.obriain 2003-01-22 15:46:20 UTC
The same problem occurs with gnome-calculator.
Comment 9 Owen Taylor 2003-01-22 16:56:49 UTC
You could connect to the ::focus signal on the GtkTable that
holds the button, do your own thing and return TRUE to indicate 
that you've handled it. Probably wouldn't be that hard to get 
whatever behavior you expect, though I'm not sure it is worth
the effort.
Comment 10 Rich Burridge 2003-02-27 17:59:57 UTC
*** Bug 106627 has been marked as a duplicate of this bug. ***
Comment 11 Rich Burridge 2003-02-27 18:02:24 UTC
Note that I attached a small patch to bug #106627 that
correctly handles the Tab focus direction case. This
might be of interest to others that have an immediate need
to work around this problem. For completeness it would
have to handle the "edge" cases for all the other directions,
in all three modes, so it would start to get large/ugly.
The real fix should be to handle the overall problem (i.e
this bug).

Comment 12 Soren Sandmann Pedersen 2003-03-21 20:34:17 UTC
What happens here is that when focus is at the edge of the window
and you press right arrow all ::focus implementations from the focus
widget up will return FALSE. This will make the GtkWindow::focus()
method set_focus_child (NULL) in all containers and then try
focusing again. Since there is no current focus at this point, the
default container::focus() implementation will focus the middle
widget in the left-most column. What widget that is, is essentially
unpredictable.

Possible solutions:

	- Make all containers maintain a "last focus". Then the
          focus implementation could just use this instead of
          calculating an "old focus". Note that the implementation
          of this could probably use the implementation in
          gtkpaned.c, which could then be removed.

	- Make arrow keyboard navigation not wrap around. Doing this
          would require special casing arrows in GtkWindow::focus.
          Home and End navigation could probably be added.

Comment 13 Soren Sandmann Pedersen 2003-03-21 20:54:54 UTC
I should add that the solution to this bug will have implications for
bug 54047.
Comment 14 Soren Sandmann Pedersen 2003-04-02 19:06:10 UTC
Created attachment 15397 [details] [review]
patch to make arrows not wrap
Comment 15 Owen Taylor 2003-04-02 19:48:49 UTC
I'm fine with this change for HEAD. I'd rather not do
it for GTK+-2.2; not that I think it would break anything,
but just on a general idea of avoiding behavior changes
in the stable branch.
Comment 16 Soren Sandmann Pedersen 2003-04-02 21:52:04 UTC
committed to HEAD