Re: Gnome Key Binding Standard



Hi again.

Well, I seem to have started something over - fine.
First of all, I said the bindings I presented were only examples.
Second, it seems that the crucial issue here is the _default_ for
these bindings, or wether they shouldn't be fix anyway.

I realize this _is_ UNIX.
But *what* are "standard" UNIX key bindings?!?

Those of EMACS?
(which I personally don't use very often any more, but that's me)

Those of VI, the shell, any tty?
(they don't fit the concepts of existing GUIs very well)

Those of Netscape?
(which resemble, but are not actually identical to the Emacs
 and the Motif style)

Those of standard Motif apps?
(which resemble and [over?]extend Windows etc key bindings)

And so on...
So UNIX does not really give a good example of a consistent key
binding model (though Emacs certainly has great influence in the
shell/tty app area).

I agree on having "sane" defaults. But fact is:
You definitely can't have everything in _ONE_ default, as it has
been (in)directly pointed out in some of the replies:
 Many things _are_ incompatible, and { keys } is a limited resource.

I do not intend to exterminate Ctrl+K as "Cut To EOL" for everybody
just because I don't need it (currently, yes, I'm much quicker doing
Shift+End then Ctrl+X than Ctrl+K, but that's me).
I like/am used to many of the standard Motif key bindings (others will
not), and I'm not a regular Emacs user (others are). 

I think one has to decide wether Gnome wants to

(1) create a _new_ standard with the binding defaults it supplies
    (some kind of mixture of compatible bindings?);

(2) adhere to one or more existing standards, possibly based on user's
    choice (eg an Emacs theme, a Netscape theme, a Motif theme etc).

With the latter, I think, individual configurability of each and
every binding would not be _that_ important any more (anyone with
a demand for her/his personal key binding standard could create
her/his own theme anyway).

For (1), however, who is going to decide upon what gets into a
universal standard, what doesn't? This kind of standard will not
catch at all in the case of people truely devoted to Emacs style
or those truely devoted to Motif style or whatever.

Therefore, I think (2) with a _choice_ among existing standards is
much more favourable.
The main goal is a consistent interface for the (one) user or
a workgroup of users.
Putting consistency among _all_ users is virtually impossible!

HOWEVER, the original intent of my mail was to start a discussion
upon a list of abstract key names and the methods of dealing with
them. Making them truely abstract means that barely anything may
be bound to them later on (from standards to individual stuff).

And concerning abstract key names, I think Paul Hepworth's idea of
a "dynamic" binding database that gets extended by every application
registering a new abstract key name is quite worth more than one
thought.

Cheers
Alex



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