Proposal: Keyboard Input & Themes

[Allan Robertson Black - Sun Scotland - Senior Project Engineer <Allan Black uk sun com>]

This something which I've been mulling over for a couple of months now,
and
it actually came from two separate directions: firstly, when working on
GTK/Gnome apps, I've found it awkward to work with keyboard input.
Secondly,
I've seen (various places, e.g. discussion on www.gtk.org) people asking
for
some form of 'keybinding-themes'.

I don't want to criticise the existing system of using "key_press_event"
and
"key_release_event", since it's completely flexible and works in all
cases.
However, it _can_ be tricky to use at times, e.g. in the typical "word
processor" scenario:
        To catch key presses for typing text, you need to connect a
signal
        handler to the top-level window (seens to be the general
consensus
        on how to do this).

        In order to prevent two objects from reacting to the same
keypress,
        (I believe) you need to make use of some carefully-placed calls
of
        gtk_signal_emit_stop_by_name. I have had to do this to spin
buttons
        to prevent keystrokes intended for the spin button from being
picked
        up by the editor.

So ....

What I have been thinking of, is an additional method for delivering
keyboard input to applications.

The existing method of signal handlers should continue exactly as it is.
(However, in the longer-term, hopefully this method would only be used
internally by widgets, or in special cases.)

Applications may request the delivery of keystrokes in the following
way:

        gtk_key_connect(GtkWidget *w, GtkKeyFunction key, callback,
data)
        gint callback(GtkWidget *w, GtkKeyFunction key, gpointer data)

The GtkKeyFunction can be the GDK-provided keysyms, e.g.:

GDK_Return
GDK_Shift_L
GDK_A
etc.

Or it may be a higher-level symbol, e.g.:

GTK_KEY_Alpha
GTK_KEY_Upper
GTK_KEY_Digit
etc.

Or it may be higher-still 'functional keyboard symbols', e.g.:

GNOME_KEY_Close
GNOME_KEY_Cut
GNOME_KEY_Undo
etc.

The last group of symbols may be registered by the desktop system at
init
time (just as Gnome widgets can register their own signals). The GTK key
system shouldn't care what they are; only that they exist and are
meaningful.

This would allow applications to bind callbacks to the 'intended
function'
of a keystroke, without the programmer having to hard-code specific
keys,
e.g. Control-X for 'Cut'.

It would then be possible to provide 'keyboard themes' at the desktop
level,
by setting up the appropriate definitions of the functional symbols.
Although
the issue of keybindings is a Desktop issue, it would require a certain
amount
of support (transparent support, that is) from the Toolkit in order to
make it
work with, for example, the menu system.

In addition to the above, it would also be possible to provide something
which I think of as 'contexts'. This would allow keystrokes to be
delivered,
based on a nested setup, where keystrokes are required to have a
slightly
different meaning, depending on the 'context'.

This is probably best described by example:

1) A dialog box wants to use Escape to cancel the dialog. Normally
Escape is
   used by the main application to clear editor settings (e.g. like vi).
   The app has a handler connected to the Escape key in the 'default'
   context. The dialog box creates a new context and registers a handler
   against the Escape key in this context. (Little gain from a new key
   system in this case, but read on ...)

2) Menus. Suppose an application has Control-S as a shortcut for 'Save'
in
   the File menu. Also, 'S' is a valid shortcut for the Save function
when
   the menu is popped-up. You may then use either Control-S or Alt-F/S
to
   invoke the Save menu item.

        -------------------------
        | _F_ile  _E_dit
        -------------------------
        ----------------------
        | _N_ew    Control-N |
        | _O_pen   Control-O |
        | _S_ave   Control-S |
        | etc.               |
        ----------------------

   Control-S is defined in the default context, so will invoke the Save
   function directly.

   Alt-F is defined in the default context and will pop-up the File
menu.
   The 'S' key is defined within the context of the File menu, and will
   invoke the Save function. This keystroke will not be delivered to any
   handler in the default context.

3) Widgets e.g. spin buttons or text entries may define their own
contexts
   so that keystrokes may be claimed independently of parent widgets.
Keys
   such as Tab or arrow keys could be defined in all contexts, and could
   then be used to switch focus from widget to widget.

I realise this is a bit of a brain dump :-) and needs quite a bit more
thought, but I'd like to know what people think of this as a general
idea,
particularly the bit about themes.

I reckon I can visualise about 70% of the implementation of something
like this,
but I need to do some serious digging in the menu code :-)

Function names (e.g. gtk_key_connect) are arbitrarily chosen, so could
be
anything. Also, 'context' could be 'focus layer' or something like that,
so
the 'default context' would be called the 'top layer'. etc. etc.

Also, it _may_ be possible to implement something like this using the
existing signal system, but I doubt it. We'd probably end up with a
signal
name per key/combination of keys, which I reckon would be bad.

Any thoughts?

Allan