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=531274It 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@...
>
http://mail.gnome.org/mailman/listinfo/gtk-devel-list_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list