Re: gnome key-binding standard



Tom Tromey <tromey@creche.cygnus.com> writes:

> Paul> I suggest that a per-user key binding database be maintained.
> Paul> Applications, rather than checking for "F3" for instance, would
> Paul> check for KeyBinding("search again"), etc.
> 
> I like this idea quite a bit.  I definitely think we should do it.

I've proposed this myself (about 6 months ago, to KDE) and no-one
liked it even though I thought it was a great idea =).

> Ideally I could use some nice GUI to set up key bindings on a global
> basis.  The changes would be "hot", too -- automatically propagated to
> all running apps.

Can you say CORBA?  (Probably CORBA events, though I still need to
look into that).  There are practical and performance issues, but
conceptually it would be nice if you had a single application that
configured keyboard behavior (vi/modal; emacs; windows; mac; user;
etc) and that it would be consulted for every event as to how to
handle it.  That doesn't have to be piss-slow--e.g., word processors,
etc, could maybe inheret from the event manager and cache keybindings
so they don't have to confer with this other app via IPC all the time,
and simply get an update event when they need to reload.

> 
> Paul> As a user, I could make Ctrl-L be the "search again" since
> Paul> that's what I prefer (from age-old brainwashing).
> Paul> (Interestingly, we have MANY different search again bindings in
> Paul> widespread use: ^L from wordstar (borland, etc.); F3 from M$;
> Paul> Ctrl-G from Navigator and Norton stuff, 'n' from vi, etc.)
> 
> One (hopefully minor) problem with the whole idea is that it assumes
> that the difference between various key binding styles is simply the
> key->action mapping -- and not fundamental differences in the actions
> themselves.
> 
> This assumption is false.  For instance, vi doesn't have any notion
> like Emacs' incremental search.  And Emacs doesn't have a vi-style
> search function bound by default.
> 
> Also, some differences are deeper: vi is modal whereas Emacs is
> (mostly) not.  Emacs has multi-key bindings, whereas vi seems to be
> (it's been years since I used it) single-key only.  Some styles (the
> Mac) delete the selection when you type; in Emacs this is configurable
> (I turn it off).
> 
> Probably these differences can be worked around without enormous
> effort.  libreadline manages it by providing both Emacs-style and
> vi-style actions, and letting the particular keymap in use choose the
> appropriate one.  Maybe this approach can be generalized as needed.

I'm trying to think of how to do this.  I envision that apps would
register a bunch of actions that they want to support--such as save,
exit, select all, paste, and so on--but they do NOT explicitely
respond to given key events.  Rather, they register callbacks (or some 
other implementation that accomplishes the same thing) and some event
manager calls these as appropriate.  The event manager knows what to
call based upon a given configurationn--e.g., with a mac-mode, alt-s
would mean "SAVE".  The app says call function "do_save()" on event
"SAVE", and so on.

so

		+--------------+
		| user events  |
		+--------------+
			|
			V
		+--------------+
		| event manag. |
		+--------------+
		     ^   |
		     |   V
                +--------------+
		|   app.       |
		+--------------+

(the feedback from the app--i think--is just the initial registering
of actions it wants to support).

> I think the default keybindings should be neither Emacs nor vi.  Both
> of these seem overly obscure.  Instead I think we should adopt "Motif"
> style bindings.  These are relatively simple bindings, reminiscent of
> Windows.

Agreed--windows (or motif, its close cousin) keybindings should be
the default.  But just likeyou can choose a different style (motif or
windows) in KDE w/a pull down menu, the kbd configurator should allow
you to choose, e.g., vi keybindings everywhere if you so desire.

(isn't "shampoo" a funny word??)

--

Steve Farrell



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]