Re: GTK rc binding question

[Neil Bird <neil fnxweb com>]

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:neil bird uk thalesgroup com    |    $> cd /pub
   personal - mailto:neil fnxweb com                 |    $> more beer