Re: Gnome Key Binding Standard (dynamic database)

[Alex Achenbach <achenbac stud uni-frankfurt de>]

Paul Hepworth wrote:
> 
> The specific bindings are not important; they are user-configurable
> (globally).
> What is important is that these bindings exist.

yep.

> Also, any application should be able to add new keybinding names and
> recommended value (if it conflicts with a user binding, either have no
> binding, or immediately ask use (the keybinding engine does this, not the
> application)).
> E.g.  if a new application does a "foo" operation, it could register a "foo"
> keyboard binding with the keybinding engine.  (It might suggest shift-ctrl-F
> for the recommended binding, which will be used unless the user already has
> already bound shift-ctrl-F to something else.)  After this, a future
> function that uses "foo" will automatically get this binding.
> There should be a base set of keybinding names that are guaranteed to be in
> the binding engine's database (even if unbound).  Applications that use
> additional binding names should register these bindings as part of startup
> (if they are already bound, the attempt to reregister will do nothing).

A "self-extending", "self-consistent" binding database editable by the
user
I actually think this is a great idea, better than any static database.
There should be a validity check that no single application uses "foo"
and
"tee" both assigned to the same actual key (of course application A
using
"foo" bound to key X and application B using "bar" also bound to key X
is
not a problem at all).
One might even consider having _all_ applications use ONLY registered
key
bindings, ie registering all key bindings that they need, so that all
those not in the existing database yet will be added.
Another advantage of this would be that there is a single point of
service
when changing any common or even totally application-specific binding
(as there is no difference in handling of common and specific bindings,
 all may be editable in the database, directly or by choosing themes).

The keyboard theme thing is easily implemented:
To choose a theme when no database exists means to choose a basic
database.
To change a theme later means to change the affected database entries.
Any new entries in the database not covered by the theme will stay
intact.

> Also, the original proposal mentioned that "more than one key may be bound
> to a single name" or something like that.
> To clarify, this means BOTH that a single keybinding may consist of a
> sequence of more than one key (Ex:  Ctrl+K, Ctrl+D in sequence) AND that you
> may have multiple (parallel) key sequences bound to the same name (e.g. both
> Ctrl+S and F2 bound to fileSave means I may use either ^S or F2 to save).

I wasn't clear there, I actually meant the equivalent use of several
single
keys. However, bindings with sequences of keys should be possible as
well,
right.

Cheers
Alex