But what happens is that the 'focus' signal fires the callback both when
the GtkComboBox gets and loses focus. The callback connected to the
focus-out-event never fires.
You may want to file this as a bug. In some cases knowing that focus has
changed may not be good enough. Someone will one day probably need to know
exactly if the widget received or lost focus. 'focus-in-event' and
'focus-out-event' should work properly.
Indeed they should.
As I mentioned earlier in the post that started the thread, I suspect it
having something to do with GtkComboBox being a composite widget.
However, it would be nice to have an opinion of someone who is more
familiar with the innards of PHP-GTK, in order to determine whether it is
strictly a GTK issue and if so, can it be overridden in PHP-GTK?
Hi André,
GtkComboBox is derived from GtkBin, which is a non-windowed widget, and yeah normally you'd expect to be able to override the behaviour with GtkEventBox - but I think you're probably right about the widget being too complex for that. Just to give you some idea, the original piece of code in GTK+ source opens up with:
/* WELCOME, to THE house of evil code */
BTW, if it's a bug at all it'll be a GTK+ bug - the only way it's useful to report it to the PHP-GTK team is as a documentation bug. We don't do a great deal with GTK+ signals.
I changed your script a little to experiment with this stuff:
function printFocus($combo, $direction) {
if($direction) echo ($direction)."\n";
}
$combo->connect('focus', 'printFocus');
// output refers to Gtk::DIRECTION_TYPE; 2 == Gtk::DIR_UP, 3 == Gtk::DIR_DOWN
3
2
3
2
The 'focus' signal doesn't carry a GdkEvent, just an enum telling you which direction keyboard focus came in from or is going out to. I haven't played with setting up an entire ComboBox (with treestore et al) - I'm hopeful you'll find that the GtkTreeview lurking within the private structure will allow for focus-in/out events, which would make some sense here. (But the treemodel alone definitely will not).
- Steph