New key-binding system

[Owen Taylor <otaylor redhat com>]

I've been offline for a while getting moved to Redhat here,
and I see that a lot of effort has been expended on the
discussion of key-bindings.

In the GTK+-1.1 currently in development, there is already a
start at a flexible, configurable key-binding system.  To
give people something other than vi-emacs to talk about,
I'll briefly describe what is there and what the plans are:


Basic concept:
=============

Whenever a keystroke is received for a widget, and the
widget doesn't handle it directly, a _binding_ for
that keystroke is looked up by the default handler.

A widget that wants to pre-process keystrokes before
looking up the bindings can invoke the lookup directly
from its key_press_event handler

Keystrokes are bound to a series of "action signals"
which are just regular signals that were marked as
actions when they were created.

[ The details of examples below are rather invented, and are
  meant to show mostly the system, rather than the particular
  action signals that 

For instance, in the rcfile, you might have:

  bind "<Control>c" { "cut-clipboard" () }

or, rather fancifully,
  
  bind "<Control><Shift>p" { 
    "move-to-column" (0)
    "insert-string" ("(")
    "move-to-column" (-1)
    "insert-string" (")")
  }

Arguments can be specified for passing to the signal - 
they can be integers, strings, or even enumerations:

  bind "prior" { "move-vertically" ("page", 1) }

Where 'page' is an nickname for GTK_MOVE_PAGE. 
                         

Lookup:
======

Bindings are grouped into named binding sets:

binding "myeditable" {
  bind "<Control>c" { "cut-clipboard" () }
}

The attachment of binding sets to particular widgets
is specified, as for styles, by patterns:

  # bind all spinbuttons under MyWindow to "myeditable"
  widget "MyWindow*GtkSpinButton" binding "myeditable"
 
  # bind all entries within a GtkSpreadsheat widget
  widget_class "*GtkSpreadsheet.GtkEntry" binding "myeditable"

A new type of pattern has been introduced which binds
to a particular branch in the class heirarchy.

  # bind all widgets that derive from GtkEditable
  class "GtkEditable" binding "myeditable"

This now works for styles as well.


Priorities
==========

When multiple binding sets are attached to the same widget,
resolution is done:

 - First, by priorities that can be given explicitly 

  class "GtkEditable" binding : rc "myeditable" 

  [ Syntax not final ]

 - Second, by the order in which the patterns were given.
   Later patterns override earlier ones.

The three standard priorities are, in increasing order,
'gtk', 'application', and 'rc'. This is meant so that
bindings can reliably be overriden, without worrying about
the order they were given. Generally, the default 'rc'
priority for rc-files will be the only thing ever used in an
rc-file.

Also, when rc-files are reparsed with gtk_rc_reparse_all() [
New in 1.1 ], only bindings at the 'rc' priority are
cleared; because widgets and applications may create their
own defaults with gtk_rc_parse_string() [ or directly with
function calls on the gtk_binding API ]


Current Status
==============

Currently, pretty much everything except the actual parsing
of the RC files is there. Anyone who wants to take a look can
download the gtk+ module from:

  http://www.gnome.org/software/anoncvs.shtml

Since I think that we've drifted a bit too much into a
"closed" development model here, let me mention that if you
would like to be added to the list where we discuss random
details of exactly what we are changing in GTK+, drop me an
email. (Though we'll continue as currently to try to post
anything of even slightly general interest here)

Regards,
                                        Owen