Re: Open API bugs, 25 June

[Havoc Pennington <hp redhat com>]

Calum Benson <calum benson ireland sun com> writes: 
> Is it safe to assume from this list that all the keyboard navigation
> bugs are unaffected by the API freeze, and will be fixed at some later
> (pre library freeze) date?  If not, they need to go on the list
> too...

Some of the keynav stuff may require API additions/changes. I don't
think we've thought this through fully. 

It's sort of hard to know what API changes are involved in keynav
until someone has time to try implementing all the keynav stuff, but I
think there's a solid month of work there.

Appended is an old mail I sent speculating on API changes the keynav
stuff might imply.

I'm not sure how this relates to the freeze.

Havoc

From: Havoc Pennington <hp redhat com>
Subject: keynav issues
To: gtk-devel-list gnome org
Date: 13 Apr 2001 18:22:55 -0400


Hi,

Some issues that will probably come up trying to get keynav right,
some of these no doubt involve API changes and/or feature creep.

Calum's document: http://developer.gnome.org/projects/gap/keyboardnav.html

 - F10 focuses menubar. Need a way to discover "the menubar"; needs to 
   be a user-configurable binding. Should discover the menubar as with 
   mnemonics, but should be configurable as with binding set or
   accelerators. Also, if two menubars, F10 should cycle between them.

   Suggest binding set on GtkWindow, plus a hack of some kind to 
   register/unregister menubars with GtkWindow.

 - In message boxes, simply the mnemonic letter (without Alt) should 
   work to activate buttons. 

   This would presumably mean that we'd have some call 
   gtk_window_set_mnemonics_unmodified() or the like, to be used
   with windows that you would never type into.

 - Enter and Escape

   Calum suggests that these correspond to OK and Cancel, and that
   they not exist in dialogs that have other buttons.

   The way these work in GTK now is that Enter corresponds to the 
   default button (which is highlighted specially) and Escape 
   corresponds to clicking the window manager close decoration (the X
   in the titlebar). Should this change?

 - Arrow keys off by default, but used for navigation in specific
   contexts such as radio groups. Need mechanism for doing the 
   radio group nav.

 - lock accelerators by default

 - F8 to focus GtkPaned handle - how do we do this F8 binding? 
   should take effect if any child of the GtkPaned has focus.

 - Toolbars have no keynav, need a container_focus implementation 
   for GtkToolbar I'd guess

 - Pop-up tooltip on a widget - requires some concept of "tooltip for 
   this widget." Accessibility API seems to require same.

In general we need to go through Calum's document and do a diff
between current GTK behavior and desired behavior, and file bugzilla
reports for each required modification to current behavior. Any
volunteers?  ;-)

Havoc