proposal: substantial change to keyboard-driven action handling

[Paul Davis <paul linuxaudiosystems com>]

(I've been grousing about the way GTK's handles keyboard bindings in the
most general sense for some time now, and was suddenly motivated to try
to write up a proposal for what I think needs to be done. Feel free to
shoot me down)

CLAIM
-----

GTK's handling of keyboard-drive events is a mess

EVIDENCE
--------

Bugzilla

#501379, #324039

Multiplicity of ways to specify binding methods:

1) GtkAccelMap loaded from file
2) <accelerator> nodes in a GtkUIManager definition
3) accelerators specified when constructing menu items
4) per-widget bindings in a GtkRC file
5) <accelerator> defined on a widget via GtkBuilder
6) hard-coded focus navigation keys

Multiplicity of code paths support key-driven action:

1) GtkWindow event handling via gtk_accel_groups
2) GtkWindow event handling via mnemonic activation
3) GtkWidget event handling (via gtk_bindings)
4) focus navigation using hard-coded keyvals

PROPOSAL
--------

A GTK key event consists of a few critical pieces of information: 

  * a keyval 
  * a modifier state
  * whether the event is a press or release

There needs to be a 1:1, configurable mapping between any tuple of
these 3 properties and some action within a GTK application. This
mapping should be the only way that a given key event tuple
(key,modifiers,press/release) ever causes that action to occur. An
action is represented by a closure.

Any given GtkWidget has zero or more maps that connect a key event
tuple to a closure. When a key event is received by a GtkWindow, the
window first allows the focus widget to look up an event in its
map(s) of tuples/closures. If the event matches a given tuple, the
closure is invoked. If there is no focus widget or the focus widget
does not report that the key event has been handled, the GtkWindow
does the lookup in its own map(s).

A GtkWidget can have a series of such maps, searched in a defined
order. It can share a map with other widgets. Maps are reference
counted. 

All other mechanisms for creating or handling key-driven actions
should either be removed or rewritten to use this single internal
mechanism.