GNOME Bugzilla – Bug 89780
Treeview: signal_button_press_event needs connect_notify()
Last modified: 2016-02-02 15:20:01 UTC
I have a tree with a pixbufrenderer and a textrenderer, I have attached a callback for on button press, and activated(the example doesn't have the activated handler). When clicking on the text widget the signal handler is not called, also when pressing the space bar when the text widget is highlighted will not call the activated handler. Things seem to work fine when clicking on the pixbuf, also the button release event is called when expected all the time. If I subclass treeview and override on_button_press_event it works. I have found a rather complex work around by subclassing treeview and overriding on_button_press_event, I pass into the new class my handler I want called and the new class will call it when I get an on_button_press_event.
Created attachment 10239 [details] example of the bug
Please simplify this example: 1. The bool column doesn't seem to be relevant. 2. Please just use the default cell renderers by using the templated append_column() method. This will reduce the code size. 3. We only need one row to test this.
If you had simplified this example yourself then you would see that it is an issue with editable cells. The "row_activated" signal is not sent if the cell is editable. I guess that's because activation is "handled" by the cell renderer itself - it puts the cursor in the text box. But that might not be intentional. For that, and/or the issue of the button_press_event signal handlers not being called, maybe you should recode this as a simple GTK+ example and submit it to them.
Unless you demonstrate that this is a gtkmm bug then I will close it.
Closing. It might be a GTK+ bug, but someone would have to investigate that.
Created attachment 19697 [details] modified example from the tutorial to demonstrate this bug
Attached two more examples: one python script that prints out "button press" whenever a mouse button is pressed over the tree view, and one (equivalent) C++ program that should do this, too, but doesn't. Reopening...
Created attachment 19700 [details] Python script (works)
Created attachment 19701 [details] C++ program (does not work)
One more thing, signal_event IS called, even with event type GDK_EVENT_BUTTON, so I suppose the event disappears somewhere inside gtkmm.
I'd really rather have a C test case than a Python test case.
Created attachment 19726 [details] treeview_signal_working.cc
Here (treeview_signal_working.cc) is a version (also simplified) that works. It's been discussed lots on the list, but this is the first time that I've checked my theory. You need to use connect_notify() (equivalent to using connect() with the extra false parameter) to handle the event before the treeview/renderer, because the standard handler stops the further handling of the signal, with its return value. pygtk defaults to connecting before, which probably causes more, other, problems. I think overiding on_button_press() would be more intuitive, and should work. I'll leave this open unless something thinks that we can make connect() do the right thing automatically, but I don't see how it could know.
s/unless/in case/
We should mentin this signal in the Combo class's doxygen comments.
(In reply to comment #13) > Here (treeview_signal_working.cc) is a version (also simplified) that > works. It's been discussed lots on the list, but this is the first > time that I've checked my theory. You need to use connect_notify() > (equivalent to using connect() with the extra false parameter) to > handle the event before the treeview/renderer, because the standard > handler stops the further handling of the signal, with its return value. > > pygtk defaults to connecting before, which probably causes more, > other, problems. This is nonsense. It's gtkmm problem that it doesn't properly handle return values of signal handlers (in this case it just lets gtk read garbage from the stack as a return value); while pygtk does right thing.
Yevgen, firstly, please be nice. It's a condition of using this bug reporting system. Secondly, please provide a test case to prove your theory, or at least some further explanation about how you came to this odd conclusion - such as "lets gtk read garbage from the stack as a return value". It doesn't make sense to me at all, and the existing behaviour makes sense to me in terms of what the code does.
I apologize for producing nonsense myself. Indeed, "it just lets gtk read garbage from the stack as a return value" is not right, I misread the code. But, it's indeed nonsense that "pygtk defaults to connecting before, which probably causes more, other, problems". And it's true that "pygtk does right thing". Sorry for popping up here, it was caused by a bit of conversation/investigation of a WTF thing on irc.
Don't know if it matters: the same happens with the on_motion_notify signal.
Signal handlers for many X event signals are not called, if they are connected after the default handler, which is the default behaviour for SignalProxy:: connect(). Connect your signal handler before the default handler, either by using connect() with the optional 'after' parameter set to false, or by using connect_notify(). This is discussed in the gtkmm tutorial, https://developer.gnome.org/gtkmm-tutorial/stable/sec-xeventsignals.html.en#signal-handler-sequence Whether connect()'s behaviour is good or bad is also discussed in bug 126213.