Re: Gnome Key Binding Standard -- Basic Issues

[Alex <achenbac stud uni-frankfurt de>]

Neil Vachharajani wrote:
> 
> On Wed, 1 Jul 1998, Alex Achenbach wrote:
> 
> > 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.
> 
> We would have to be very careful allowing applications to add their own
> bindings to the database.  If two applications add two different bindings
> for the same function, because their developed simultaneously or one
> developer didn't know about the others key binding, then the database will
> get bloated with many, many duplicates for the same action.

The last sentence of the quote says that an application should not
be allowed to change an existing entry.
For example, if application A already set up a new entry, binding
key "Ctrl+V" to "paste-clipboard", an entry "paste-clipboard" exists,
and no application (neither A nor whichever) may change that.
Keys should not even be addable to an already bound function (so that
suddenly more keys mapped to the same function than before).

Existing definitions (= map of one key, or maybe multiple keys
[if that was the initial application or user setup], to a function)
should be left alone by applications altogether.

HOWEVER, (and you might have meant that from the start) this leaves
a risk of two applications implementing a new function that has not
been "standardized" before, with different symbolic names,
eg "paste as column", named "paste-as-column" by one application,
but "paste-clipboard-as-column" by another; these two (differently
named, but with equivalent semantics) would cause a duplication
in the database.

We would not be safe against that, unless a means of registration of
new functions at some central location was provided.

To post-fix an existing duplication, maybe the database should
provide a special feature of not directly binding a symbolic name
(eg "paste-as-column") to a key, but of defining it as equivalent
to another symbolic name (eg "paste-clipboard-as-column"), as in

	equiv("paste-as-column", "paste-clipboard-as-colum")
	bind("paste-clipboard-as-column", "Ctrl+Shift+V")      .

Surely, you could also ommit automatic extension of the database.
This may mean that a new application does not have certain keyboard
functions available from the start (not in the database), but instead
adds new entries to a second database of optional keys, which are not
used unless moved to the normal database by the user (leaving it up
to her/him to make them work).
However, this does not prohibit potential duplications in symbolic
names, though they are more likely to be detected by the user.

Alex