Re: selectable labels

[srlytle_list yahoo com]

> > > Try to control ghex from keyboard, for example. When you are inside
> > > editor/viewer, alt-f will not bring you to menu. In fact, I could not
> > > figure out how to get to the menu.
> > 
> > Same in gnotepad, unless you give focus to the status area first, which
> > isn't exactly intuitive  :o)  (Plus you can only do that with the mouse,
> > which rather defeats the purpose!)
> > 
> 
> The problem there is that GtkText eats the Alt-f as "move forward
> word." Our new rule is that the editable widgets don't get to use Alt-
> shortcuts by default (but Emacs die-hards can set them to do so in
> their .gtkrc).
> 
> Although the new GtkTextView does still eat Alt-f at the moment, Owen
> is making me change it. ;-)

while i understand the motivation for this, i don't think it is a good idea.
first off, for those of us die-hards, we are still left with the original
problem it would seem. (although i guess you might be able to map some other
key to globally bring up the file menu? i don't know, never really used
.gtkrc, but then, most of the time, alt-f is a good way to bring up a
menu). second, it consumes a huge subset of the available keyspace - 
really only leaving the control keys and multiple-modifier keys (although
i tend to use a lot of those for window manager stuff). Finally, it doesn't
really address the fundemental issue of fixing focus - it is acceptable
for the same key to have different meanings depending upon what you are
doing, in fact desireable, but this requires that there is a gauranteed
way of moving focus around, which we don't really have right now (that i
have been able to find).

so we have worked around the problem and lost half of our not-text-character
keyspace to get one feature (menus) to work, and still depend on the
discipline of widget-writers to follow this convention. this might hold
ok for the gtk widgets, and even gnome, but is unlikely to be followed
universally outside of these high-profile projects.

can't we just have a single keystroke (defaulting to something sane, eg.
alt-esc, and configurable in .gtkrc) that is gauranteed (unless explicitly
overridden by the application) to either

1. move focus from a child to it's container parent
or
2. move focus to the toplevel

i don't know which would be better, but i think either would do. assume
that alt-esc is mapped to move-focus-to-toplevel (i don't know if
this is a sane choice). the user is editting text, using alt-whatever
to navigate. when he wants to access the menus, s/he hits alt-esc,
focus leaves the editable widget, hits alt-f, and the file menu comes
up.

i can't claim to understand gtk_focus too well. i've used it a lot,
but i almost never get it right the first time, and what i typically
end up doing is telling everyone that they can't focus, and then
hand out keypresses at the application level myself with a simple
state engine. thus if my thinking is flawed the above might not make
any sense. still, i think something more fundemental than the proposed
"don't use alt-anything" is needed, and i think the fundemental 
problem is the ability of a widget to grab focus, and never give
it up. notice the final sentence of the original post:

> > > editor/viewer, alt-f will not bring you to menu. In fact, I could not
> > > figure out how to get to the menu.


seth