#2045 NORM Untriag: Discussion of GTK focus bugs

[Zarro Boogs per Child]

#2045: Discussion of GTK focus bugs
--------------------+-------------------------------------------------------
 Reporter:  Eben    |       Owner:  dcbw     
     Type:  defect  |      Status:  new      
 Priority:  normal  |   Milestone:  Untriaged
Component:  sugar   |     Version:           
 Keywords:          |    Verified:  0        
--------------------+-------------------------------------------------------
 As I've been playing around with things, I've seen a lot of entirely non-
 intuitive shifts in focus.  I'm not sure which of these are bugs and which
 are default GTK behavior, but this ticket serves as a place to report
 focus issues and sort out which are bugs, which are expected behavior, and
 what we do about them in either case.


 '''Text fields:''' As a prime example, I'd like to discuss the basic
 single line text field.  Take, for instance, the text field used to name
 any activity.  When this text field has focus, the left and right arrow
 keys move the cursor left and right as expected.  The up arrow key, which
 should move the cursor to the beginning of the line, does nothing.  The
 down arrow key, which should likewise move the cursor to the end of the
 line, instead removes focus from the textfield entirely, jumping instead
 to a tab, or when there is no tab, into the activity itself.

 '''Popups:''' Likewise, the search toolbar in the journal allows jumping
 from one option menu to the next.  This should be done with tab.  Left and
 right arrows should not have an action when the popup is closed; They
 should be reserved to show and hide submenus when it is open.  Up and down
 should, obviously, move through the options in the list when it is opened,
 as they do now.  However, when the list is ''not'' open, they should have
 the action of opening it.  Right now, they simply jump through the items
 without opening the list.

 '''Toolbar:''' When the focus is inside the toolbar, for instance in the
 name entry field, the tab button completely bypasses all of the other
 buttons within the toolbar, jumping immediately to the tabs themselves,
 and then into the activity.  The focus should run through all items in the
 selected toolbar before dropping down to the tab bar.

 '''Journal List View:'''  I'm not sure how to categorize this, but there
 is no keyboard support at all, it seems, in the Journal.  The up/down
 arrows jump into and out of the main view, instead of doing any kind of
 scrolling at all.  At the very least, we need to support scrolling in this
 view.  In truth, we need internal focus within the entries in order to
 allow making selections, resuming activities, and navigating to detail
 view.


 These are a few of the problems I've found so far.  Most of these seem to
 have a common root: As a general rule, the arrow keys should never be used
 to switch focus between two controls.  The tab key serves this purpose
 nicely.  The arrow keys should always be reserved for navigation within
 the focused widget.  This keeps a logical separation between the arrow
 keys and the tab key, and eliminates the possibility of losing focus,
 inadvertently switching contexts, or otherwise confusing the navigation of
 the interface via the keyboard.

-- 
Ticket URL: <http://dev.laptop.org/ticket/2045>
One Laptop Per Child <http://laptop.org/>