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 729263 - GtkBuilder should provide an easy way to disconnect signals connected with connect_signals
GtkBuilder should provide an easy way to disconnect signals connected with co...
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Class: GtkBuilder
3.10.x
Other Linux
: Normal enhancement
: ---
Assigned To: GtkBuilder maintainers
GtkBuilder maintainers
Depends on:
Blocks:
 
 
Reported: 2014-04-30 12:06 UTC by Mathieu Duponchelle
Modified: 2018-04-15 00:31 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Mathieu Duponchelle 2014-04-30 12:06:15 UTC 
Right now it seems that the only way to disconnect the handlers associated to these signals is to use connect_signals_full and store the handler id at the application level.

This is extremely fragile and code that I'd better not have in my application, would be great to have a nice upstream solution for that.
Comment 1 Matthias Clasen 2014-05-01 01:11:57 UTC 
There's no need to disconnect signal handlers, if they remain connected for the entire lifetime of the object. The signal handler will be cleaned up when the object is disposed. 

That is really the situation that GtkBuilder's signal support is meant for. If you have signals that need to be dynamically disconnected and connected at runtime, you should do it from code.
Comment 2 Mathieu Duponchelle 2014-05-01 11:00:33 UTC 
Hi Mathias !

I'm not sure I agree with you there: if signals were meant to be connected for the whole lifetime of the builder, then why doesn't it take the object as a construct_only parameter ?

As the API offers a way to connect to signals at any time, I would find it convenient to offer a way to disconnect from them at any time too.

Reclassifying as enhancement though :)
Comment 3 Matthias Clasen 2018-02-10 05:24:06 UTC 
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
Comment 4 Matthias Clasen 2018-04-15 00:31:40 UTC 
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla.

If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab:

https://gitlab.gnome.org/GNOME/gtk/issues/new