proposal: substantial change to keyboard-driven action handling

[Paul Davis]

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

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

[Paul Davis]

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

[Andrew Cowie]

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


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

[Paul Davis]

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=Ardour&path=%
2Fbranches%2F2.0-ongoing%2Fgtk2_ardour%2Factions.h

Note that the calls that specify keys&modifiers 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@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Stefan Kost]

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@...
> 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

[Federico Mena Quintero]

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

[Matthias Clasen-2]

Sorry for jumping late into this thread...

I think 'cleaning up the key event handling' is clearly a GTK3 topic.

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