Re: proposal: substantial change to keyboard-driven action handling
On Tue, 2008-05-06 at 10:47 -0400, Paul Davis wrote: 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). ignorant Some people have mentioned that the DOM way of passing events first down and then up in the hierarchy (or was it the other way around?) would be very useful to GTK+. Something tells me that this should be tied to your proposal, but I'm not sure how :) /ignorant [I know I've had to do some hacks in the past to deal with keyboard accelerators that weren't being processed at the right spot in the hierarchy... no real idea if that could have been helped with the scheme above.] Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: proposal: substantial change to keyboard-driven action handling
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@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
proposal: substantial change to keyboard-driven action handling
(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
Re: proposal: substantial change to keyboard-driven action handling
There needs to be a 1:1, configurable mapping between any tuple of these 3 properties and some action within a GTK application. Why on Earth would you require that mapping be 1:1:? What you need is that action is a [mathematical] function of the 3-tuple. There is nothing wrong with invoking the same action for two different keys. I wonder how this can be done while maintaining some measure of ABI stability. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: proposal: substantial change to keyboard-driven action handling
On Tue, 2008-05-06 at 11:57 -0400, Morten Welinder wrote: There needs to be a 1:1, configurable mapping between any tuple of these 3 properties and some action within a GTK application. Why on Earth would you require that mapping be 1:1:? What you need is that action is a [mathematical] function of the 3-tuple. There is nothing wrong with invoking the same action for two different keys. You're absolutely correct. I was using sloppy language when I used the term 1:1. What I was trying to get at (unsuccessfully) was that there should be one, and only one, way to find out what action should be invoked for a given key event. I wonder how this can be done while maintaining some measure of ABI stability. One thing that I forgot to add to my message was that I consider GtkAction to be a very suitable starting (and perhaps end) point for the kind of change I am proposing. My app (http://ardour.org/) is already doing some of its own key handling (mostly to deal with one of the bug reports I cited) using a mapping between GtkActions and key event tuples. --p ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: proposal: substantial change to keyboard-driven action handling
On Tue, 2008-05-06 at 15:31 -0400, Paul Davis wrote: I consider GtkAction to be a very suitable starting (and perhaps end) point for the kind of change I am proposing. That sounds quite sensible. We've been increasingly focused on GtkAction as the rendezvous point for concentrating GUI responses instantiated by user or programmatically all over applications, and are looking at piling more functionality into it. As it stands right now GtkAction isn't quite generic enough (for example, it's all hard wired to use stock icons only, so if you've got UI elements that have the temerity to have nothing to do with stock functions and therefore have no stock icon, you can't take advantage of the create_*() functions) but in terms of having a unified handler for callbacks from different parts of a program GtkAction is great. AfC Sydney -- Andrew Frederick Cowie Operational Dynamics is an operations and engineering consultancy focusing on IT strategy, organizational architecture, systems review, and effective procedures for change management. We actively carry out research and development in these areas on behalf of our clients, and enable successful use of open source in their mission critical enterprises, worldwide. http://www.operationaldynamics.com/ Sydney New York Toronto London signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: proposal: substantial change to keyboard-driven action handling
On Wed, 2008-05-07 at 11:38 +1000, Andrew Cowie wrote: As it stands right now GtkAction isn't quite generic enough (for example, it's all hard wired to use stock icons only, so if you've got UI elements that have the temerity to have nothing to do with stock functions and therefore have no stock icon, you can't take advantage of the create_*() functions) but in terms of having a unified handler for callbacks from different parts of a program GtkAction is great. I can't say this has bothered me. I do not use the create_*() API at all, but instead wrap everything related to actions into my own (C++) ActionManager class, which is a singleton. You can see the API here: http://viewcvs.ardour.org/filedetails.php?repname=Ardourpath=% 2Fbranches%2F2.0-ongoing%2Fgtk2_ardour%2Factions.h Note that the calls that specify keysmodifiers are never used, and I should remove them. Ardour does all keybinding via an accel map file that is explicitly loaded. Almost none of our actions are related to stock operations (and we have at least 200 actions so far). They are represented in the GUI by menu items and buttons. The one thing that is very irritating at present is that its not possible to attach keybindings to an action if there is no proxy for it (unless you use GtkBuilder). --p ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
