After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 89780 - Treeview: signal_button_press_event needs connect_notify()
Treeview: signal_button_press_event needs connect_notify()
Status: RESOLVED NOTABUG
Product: gtkmm
Classification: Bindings
Component: TreeView
2.4
Other Linux
: Normal minor
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on: 126213
Blocks:
 
 
Reported: 2002-08-03 12:42 UTC by Steve Przepiora
Modified: 2016-02-02 15:20 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
example of the bug (3.12 KB, text/plain)
2002-08-03 12:44 UTC, Steve Przepiora
Details
modified example from the tutorial to demonstrate this bug (1.83 KB, text/plain)
2003-09-03 13:25 UTC, Sven Grottke
Details
Python script (works) (605 bytes, text/x-python)
2003-09-03 14:19 UTC, Sebastian Rittau
Details
C++ program (does not work) (1.06 KB, text/x-cc)
2003-09-03 14:20 UTC, Sebastian Rittau
Details
treeview_signal_working.cc (752 bytes, text/plain)
2003-09-04 12:18 UTC, Murray Cumming
Details

Description Steve Przepiora 2002-08-03 12:42:25 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.
Comment 1 Steve Przepiora 2002-08-03 12:44:15 UTC
Created attachment 10239 [details]
example of the bug
Comment 2 Murray Cumming 2002-08-03 19:30:18 UTC
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.
Comment 3 Murray Cumming 2002-08-05 19:02:36 UTC
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. 
Comment 4 Murray Cumming 2002-08-21 07:37:37 UTC
Unless you demonstrate that this is a gtkmm bug then I will close it.
Comment 5 Murray Cumming 2002-08-24 18:31:28 UTC
Closing. It might be a GTK+ bug, but someone would have to investigate
that.
Comment 6 Sven Grottke 2003-09-03 13:25:50 UTC
Created attachment 19697 [details]
modified example from the tutorial to demonstrate this bug
Comment 7 Sebastian Rittau 2003-09-03 14:18:08 UTC
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...
Comment 8 Sebastian Rittau 2003-09-03 14:19:24 UTC
Created attachment 19700 [details]
Python script (works)
Comment 9 Sebastian Rittau 2003-09-03 14:20:28 UTC
Created attachment 19701 [details]
C++ program (does not work)
Comment 10 Sven Grottke 2003-09-03 15:00:56 UTC
One more thing, signal_event IS called, even with event type
GDK_EVENT_BUTTON, so I suppose the event disappears somewhere inside
gtkmm.
Comment 11 Murray Cumming 2003-09-04 08:09:36 UTC
I'd really rather have a C test case than a Python test case.
Comment 12 Murray Cumming 2003-09-04 12:18:04 UTC
Created attachment 19726 [details]
treeview_signal_working.cc
Comment 13 Murray Cumming 2003-09-04 12:23:28 UTC
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.
Comment 14 Murray Cumming 2003-09-14 03:50:46 UTC
s/unless/in case/
Comment 15 Murray Cumming 2003-09-26 06:58:05 UTC
We should mentin this signal in the Combo class's doxygen comments.
Comment 16 Yevgen Muntyan 2006-06-24 11:18:44 UTC
(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.
Comment 17 Murray Cumming 2006-06-25 18:13:27 UTC
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.

Comment 18 Yevgen Muntyan 2006-06-25 18:54:13 UTC
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.
Comment 19 Ralf Stephan 2006-10-25 10:14:12 UTC
Don't know if it matters: the same happens with the on_motion_notify signal.
Comment 20 Kjell Ahlstedt 2016-02-02 15:20:01 UTC
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.