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