Re: Proposal: Keyboard Input & Themes

Allan Robertson Black - Sun Scotland - Senior Project Engineer <Allan Black uk sun com> writes:

> This something which I've been mulling over for a couple of months
> now, and it actually came from two separate directions: firstly,
> when working on GTK/Gnome apps, I've found it awkward to work with
> keyboard input.  Secondly, I've seen (various places,
> e.g. discussion on people asking for some form of
> 'keybinding-themes'.
> I don't want to criticise the existing system of using
> "key_press_event" and "key_release_event", since it's completely
> flexible and works in all cases.  However, it _can_ be tricky to use
> at times, e.g. in the typical "word processor" scenario:
>         To catch key presses for typing text, you need to connect a
>         signal handler to the top-level window (seens to be the general
>         consensus on how to do this).
>         In order to prevent two objects from reacting to the same
>         keypress, (I believe) you need to make use of some carefully-placed
>         calls of gtk_signal_emit_stop_by_name. I have had to do this to spin
>         buttons to prevent keystrokes intended for the spin button from
>         being picked up by the editor.
> So ....
> What I have been thinking of, is an additional method for delivering
> keyboard input to applications.

Hmm, it seems that you aren't familiar with the GtkBinding system. You
can't really be blamed for that, because it never has been documented
other than some mails to the GTK+ mailing lists, but it is basically
meant to be a solution to these issues.

I've put a chapter from a book project I'm working on at:

This is written for GTK+-1.2, so it doesn't include some changes we 
have for GTK+-2.0, but it basically gives an overview about how
key bindings work. (People should feel free to print this chapter out
for personal use, but don't redistribute it.)

There are still some outstanding issues that we definitely need
to get to for key presses in GTK+-2.0, in particular:

 - The handling of multiple keyboard groups for accelerators / bindings
   isn't right. (See

 - The GtkAccelGroup and GtkBindingSet are distinctly hard to use
   from language bindings.

But we've had some high-level structures here for quite some time, and 
need to work from that base.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]