Re: advice wanted on controlling GtkEntry input filtering

[Paul Davis <pbd op net>]

>Hi all; I guess to start with, you should look at the drafting program
>I'm writing at www.efalk.org/Xdraft/dr2.gif so you know what I'm talking
>about.
>
>First thing I'm trying to do is control what characters a GtkEntry widget
>responds to.  As you can see, there are four GtkEntrys in the picture
>and they only display numbers.  I would like to arrange for them to
>completely ignore alphabetic characters.  The tutorials give methods for
>changing the contents of entries after the user has typed stuff in, but
>that's not good enough.  The reason is that there are several unmodified
>keys being used as accelerators (e.g. "x", "y", etc.) and I want the
>accelerators to work even when the GtkEntry widgets have keyboard focus.
>
>Is there a way to do this without subclassing the GtkEntry widget and
>rewriting its gtk_entry_key_press() function?
>
>(I tried connecting a callback to the GtkEntry's "event"
>signal and returning True, but that didn't work.  I tried calling
>gtk_signal_emit_stop(), but that worked too well, keeping the keystroke
>from reaching the accelerators either.)

Well, in GTK+ 1.2, returning TRUE doesn't work, and
gtk_signal_emit_stop_by_name() does, but it will have the
no-accelerator effect as well. 

But I don't understand why that would be a problem when a GtkEntry has
no accelerators (that i know of).

In GTK+ 2.X, returning TRUE will work.

>Secondly, I'm trying to restrict which widgets can receive keyboard focus.
>In essense, I want the tab key to move focus only between the four entry
>widgets.  Is there a way to explicitly control traversal order or do I
>have to clear GTK_CAN_FOCUS on every other widget in the program?

1) gtk1.2 has no way to control traversal order. gtk2.0 might, i'm not sure.

2) i gave up on the GTK+ focus model entirely for my app
   (ardour.sf.net). i installed a keyboard snooper, and i only allow
   key press/release events through to the regular GTK handling system
   when the application has explicitly said "allow focus to
   operate". the rest of the time, i use a custom-written keyboard
   management system that has the correct properties for my
   program, and GTK+ never sees key events after delivering them to
   the snooper. to make this easy to use, with widgets that i want to have
   "normal" focus, i connect a handler to their focus_enter and
   focus_leave events that turns on and off the "allow focus to
   operate" flag. so, when you click in a GtkEntry that is intended to
   be a regular enterable text field, GTK+ assigns focus there, and
   this enables the passthru of key events until focus leaves the
   widget.

3) yes, clearing GTK_CAN_FOCUS is the only approach to this that i
   know of.

>I've thought of an alternative way to handle the problem:  Is there a
>way to rig the DrawingArea so that it grabs keyboard focus and holds it
>permanently, and then sends select characters to the current GtkEntry
>widget?

that's basically what my use of the snooper does.

--p