Re: Unidentified subject!

[Tom Tromey <tromey cygnus com>]

Oskar> Alex Achenbach (achenbac@stud.uni-frankfurt.de) came up with an
Oskar> idea that applications should bind its commands to abstract
Oskar> symbols instead of "raw" keys.

Oskar> * Can applications use any name for its symbols? Yes, but the
Oskar> programmer should make sure there isn't an equivalent symbol
Oskar> with another name used by other applications. A style guide or
Oskar> "command symbol repository" would help alot.

This is just the standard namespace problem faced in every programming
language.  Solutions to the problem are well known, the simplest being
the adoption of a naming convention.

Oskar> * What if an app has a much more important command that should
Oskar> use the same binding as a common command? These cases are
Oskar> hopefully rare, and I don't know of a simple solution yet.

This should just never happen.  The user will come to rely on the
common key bindings working the same everywhere.  If an application
overrides one of the common bindings, presumably trouble will ensue.
(Of course, the user should be free to configure things the way he
likes.)

Oskar> Good or bad idea? Tell me what you think.

While I'm not completely sure that this can be meaningfully
implemented via an API and simple (non-programmable) config files, I
still think it's worth a shot.


The idea is basically a good one.  This is exactly how both Emacs and
the Readline library work.

With Readline, your application can register new command names, which
the user can bind (or rebind) in application-specific ways in his
.inputrc.

Emacs takes this a bit further, for instance making menu bars special
keymap entries.  (This isn't really the approach I'd recommend for
Gnome.)

It would also be good to take a cue from Emacs and specify that
certain key bindings are entirely reserved for the user.  Likewise,
handling multi-key sequences would probably be worthwhile.


Are you planning to work on this?

Tom