Re: proposal: substantial change to keyboard-driven action handling

[Stefan Kost <ensonic@xxxxxxxxxxxxxxx>]

Hi,
Paul Davis schrieb:
> (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

A short while ago I filed:
http://bugzilla.gnome.org/show_bug.cgi?id=531274
It would be good to ensure that the new implementation also handles 
action-signals with parameters.

Thanks for bringing this up.
Stefan

> 
> 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. 
> 
> 
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list@xxxxxxxxx
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-devel-list