Re: key snoopers

[Paul Davis <pbd Op Net>]

In message <y5wpuebc65n fsf icon labs redhat com>you write:
>
>Paul Davis <pbd op net> writes:
>> 
>> before you protest, consider a window with 300+ widgets, and the
>> requirement that "focus" be completely keyboard driven. imagine for a
>> moment that there is no mouse ... do *you* want to use TAB to get
>> around ?
>> 
>
>What are you planning instead?

the key observation here is that most of the widgets should never have
focus to begin with. short of using unset_flags(GTK_CAN_FOCUS) there's
no way to enforce this simply. so navigation between those many
widgets is just a nonissue. mouse clicks on them do something, but
they don't move focus around.

2 alternatives. The most important part will be focus driven by the
program itself. It knows what its done with the screen display, and it
knows what kinds of widgets should get focus and when. The second part
will be taken from DigiDesign's ProTools, where they have a small 9x9
table that allows the user to use the mouse to specify the focus mode
when there is room for ambiguity at a high level. One example is when
there are two lists on the screen that are both selectable using
letter keys (the list entries have letter designators in them). You
can't use the mouse pointer for this, since it may be doing other
things, and you certainly don't want to have to click on the list to
assign it focus, since that may have some other purpose. Another
example is whether to use the keyboard to drive the waveform editor or
the transport controls. This can change either in response to user/GUI
interaction, or because of internal programmatic changes. When the
latter happens, its made perfectly obvious with visual cues whats
going on. Once again, using the mouse for this is no good, because a
mouse click on a transport control button has a different meaning, and
may not be intended to transfer keyboard focus at all. This, of
course, is the general problem with the focus model in GTK: if you
click on a widget, it tends to be assumed that it has focus, and you
have to do several things to avoid it. Its much easier for me to start
with there being no default focus-follows-click anywhere and then add
it as its needed.

>I think the usual solution would be underline shortcuts. I know you're
>always writing bizarre GUIs without such things. ;-)

heh. where would they go ? there are hardly any menus anywhere ... i'm
a great believer in What You See Is All There Is GUI design. 

anyway, we (you included) already established a few months back that
there are other problems with using underline shortcuts when top level
key handling is used for any other reason, so thats out too :)

BTW, my feelings about this have been reinforced greatly in the last
week by writing a raw-keyboard (keycodes/press/release, not character
driven) curses-based interface to an "engine" that currently has a
Gtk-- interface. This new interface is primarily (but not solely)
aimed at blind users. Its taught me lessons about how to use the
keyboard efficiently for specialized applications (like running a 26
channel audio mixer with channel strips containing numerous
inserts). There would be no way to do the equivalent thing in GTK
without a key snooper, and I plan to take the lessons I've learned
from this new interface back into the GTK one.

--p