Re: advice wanted on controlling GtkEntry input filtering
- From: Paul Davis <pbd op net>
- To: "Edward A. Falk" <falk efalk org>
- Cc: gtk-list gnome org
- Subject: Re: advice wanted on controlling GtkEntry input filtering
- Date: Tue, 02 Jul 2002 08:51:55 -0400
>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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]