Re: advice wanted on controlling GtkEntry input filtering

[Paul Davis <pbd op net>]

>(aside):
>> (ardour.sf.net)
>
>Damn, that's sweet.  I've been looking for decent audio software for
>linux; I even tried writing my own (www.efalk.org/audioedit/).  I've long
>since abandoned mine, I'll have to check yours out.

don't get too excited. its still at a very definite beta-stage. the
development process has focused on ensuring that the ultimate feature
set can be accomplished with the codebase, not on usability. also the
comparison program here is not soundforge, but digidesign's pro tools.

>> i installed a keyboard snooper
>
>I'm thinking of doing something similar; if I can capture the X,Y,L,A and
>tab keys, and process them manually, that should be sufficient.  I was
>going to add an "event" callback to my drawing canvas and entry widgets;
>is there a better way to do it?

this will supposedly work as well, but you should do it for the top
level window in which they are found instead the canvas and entry widgets.

>> 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.
>
>I couldn't quite follow how this works, could you explain in more
>detail?

you connect a handler to the focus-in event that tells the "key event
diverter" to "stop diverting". you connect a handler to the focus-out
event that tells the "key event diverter" to "continue diverting".

by diverting, i mean not passing events along to the normal GTK+
handling system. "blocking" might be a better term.

so, when focus enters a widget that you have installed these two
handlers for, the result is that it gets normal key events.  whenever
focus leaves that widget, the diverting of key events starts again.
no other widget will receive key events unless you decide to pass them
on for some reason from the diverter.

keep in mind, however, that if you have adjacents widget in the focus
traversal route that both have these handlers set, then TAB, for
example, will simply move the focus from one to the other. this might
be a problem in some cases, and returns you to the issue you started
with.

any better as an explanation?

--p