Re: Signals question...

[Bruno Tavares <bat ip pt>]

> key events actually go to the toplevel window from X, and gtk routes them to
> the correct place.  so, for better or for worse, this is behaving as designed.
>  ahem.
>
> there's an "editing-done" signal on the GtkCellEditable, but no
> "editing-begun" signal, so you can't really trap the editing state.
>
> so next we have to look at the bigger picture...
>
> what are you using key-press-event for?  is it something that could be
> accomplished effectively (or even more-correctly) by using accelerators?
Well, i use the key-press-event to grab, lets say, 'n' application wide.
I need to jump to next item (its not so trivial as the next node in
tree) every time anyone presses 'n' within the main window. Except of
course in the "editing case". So, probably, it could be done with
accelerators but i don't know enough about it.
Can you enlighten me?

> what happens  if you connect your key-press-event handler with
> signal_connect_after?  (this will cause your handler to be run after the
> default handler, which gives gtk a chance to mess with it first.)
Well, in this case the editing of that one key takes place and then i
grab the event and change focus, so... it wont solve the problem.