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 751754 - GtkSwitch: calling gtk_switch_set_active in the handler for notify::active gets stuck in a loop
GtkSwitch: calling gtk_switch_set_active in the handler for notify::active ge...
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
3.16.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2015-06-30 21:44 UTC by David Shea
Modified: 2015-07-02 01:05 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
gtk switch example (572 bytes, text/plain)
2015-06-30 21:44 UTC, David Shea 		Details

Description David Shea 2015-06-30 21:44:21 UTC 
Created attachment 306443 [details]
gtk switch example

Small reproducer attached. In gtk-3.14 or newer, the program gets stuck in a loop and eventually crashes. This worked prior to gtk-3.14, so I assume it has something to do with the addition of the state property.

I get the same behavior even if I surround the set_active call in calls to handler_block_by_func/handler_unblock_by_func.
Comment 1 Matthias Clasen 2015-07-01 14:51:41 UTC 
I think you've filed this bug before, and yes, I see that behavior change too. 

What are you trying to do here ? If the switch is currently blocked, I would suggest to make it insensitive. If the change does not take immediate effect, that is exactly what the state property was introduced for.
Comment 2 David Shea 2015-07-01 14:58:59 UTC 
(In reply to Matthias Clasen from comment #1)
> What are you trying to do here ? If the switch is currently blocked, I would
> suggest to make it insensitive. 

The switch starts a network service, and if starting the service fails then the handler resets the status of the switch. So the condition blocking the switch isn't known until the switch is used.

> If the change does not take immediate
> effect, that is exactly what the state property was introduced for.

The state property would probably work for this, it's just frustrating that the addition of the state property effectively breaks the use of the active property.