Gnome Key Binding Standard -- Basic Issues



Hi again.

So we have it back on top - the key binding thing...

Just this: Please don't be narrow-minded or short-sighted!

Many of you are talking about what's normal for them, or what
they are used to, or what they hate (with some implied, though
wrong, tendency to generalize their opinions as universal).

The point is: None of you know universal standard bindings of
keys! Me neither. There is
	emacs, netscape, standard motif, windows, amiga, mac
and whatsoever.

A "Gnome key binding standard" will never make it if eg the
"standard motif people" cannot set up Ctrl-X as Cut (which is
typical for motif) if somebody else finds this has to be Exit
(which is common in other contexts), or if one demands Alt
(or Meta) as the accelerator modifier instead of Ctrl because
he/she wants Ctrl to work for emacs line editing, and so on.
It's not just a few keys to agree on, it's too many of too
different versions of key bindings, and there are no (*no*)
standard Unix key bindings to refer to (not even in tty's,
remember del/bspace and the like?).

So the basic goal of a Gnome Key Binding Standard should be:

NOT to put each and every choice of key binding in the hands of
applications!
(Cf. motif, which put key bindings in the hand of applications,
 and see what netscape made of it, for the better or worse...)

Everybody is used to his/her style of key bindings, let him/her
have it!

What's even more important:  Consistency among applications!

If you put raw bindings in the hand of applications, this will
certainly (cf. motif and netscape, and many, many others)
give rise to inconsistencies all along.

If all the programmers (which I'm one of) once and for all got
rid of the idea of controlling everyting, and rid of being too
"static", this would be a first step for the better.

For the key binding thing, this means: Applications should *not*
bind operations to *keys*, but to abstract symbols detached from
whatever a concrete keyboard layout may look like. That is, you
bind a "copy to clipboard" operation to a "copy-to-clipboard"
user command, and the like. Then, in a global configuration
file/program, the *user* is able to bind that "copy-to-clipboard"
command to whatever key she/he likes.
This is demanding: The database of these abstract symbols has to
be reasonably large enough, but this could (principally) easily
be done by allowing applications to *extend* the database by new
entries (as defaults, changeable by the user later on).
However, applications must *not* be allowed to _change_ the data
base as far as existing entries are concerned.

And that's that.  Have a nice discussion!   ;-]

Alex


-- 
_____________________________________________________________________

   Alexander Achenbach              achenbac@stud.uni-frankfurt.de
_____________________________________________________________________



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