Havoc Pennington wrote:
> > bind "<ctrl>g"
> > {
> > "debug-msg" ("<Ctrl-G>")
> > "clicked" ()
> > }
>
> It's simply that GtkEntry has no "clicked" signal. It does have an
> "activate" signal which is what happens when you press the Return key
> normally.
Sorry, it's not that simple! GtkEntry not having a "clicked"
wouldn't/shouldn't stop the previous "debug-msg" from happening - and it
doesn't happen. Similarly, the F16 debug never happens. And anyway, if you
*do* mismatch a signal in this way, you get a Gtk warning.
As I indicated in the follow-up email, and have since tried & failed to
properly follow through, the *window* gets the key-press events (even
though GtkWindw seems not to have a key-press event or anything similar,
so it can't be caught/injected; somehow the blah_key_pressed routine in
gtkwindow.c is called.
When there's a 'normal' object with focus (like a button), this key
event gets passed to the widget 'correctly', and at this point the
binding's widget-path is what I'd expect, and it matches.
When a *text entry* object (GtkEditable) field has the focus in a
window, it seems to not be given the event in the same way as everything
else, and when the binding code gets called, the widget-path is still
merely "GtkWindow".
I have to admit to having given up trying to understand what's going on
enough to counter it :-(
IMHO, it's a bug, if not only because the binding code's called in the
wrong place/environment. But there may bve a good reason.
--
=====================- http://www.thalesgroup.com/ -=====================
Neil Bird Principal Engineer |
work - mailto:[EMAIL PROTECTED] | $> cd /pub
personal - mailto:[EMAIL PROTECTED] | $> more beer
_______________________________________________
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list