Skip to content
This repository was archived by the owner on Jun 8, 2021. It is now read-only.

Is there any way to disconnect event handlers? #363

Closed
eeeeeta opened this issue Jul 4, 2016 · 5 comments
Closed

Is there any way to disconnect event handlers? #363

eeeeeta opened this issue Jul 4, 2016 · 5 comments

Comments

@eeeeeta
Copy link

eeeeeta commented Jul 4, 2016

From what I can see, the only things the API exposes to do with event handlers currently are the connect_ methods on gtk::WidgetExt - is there a way to disconnect event handlers?

The reason I ask is the following: when calling destroy() on a widget, GTK fires the focus-out event for the widget - which interrupts my program's flow and ends up borrowing a Rc<RefCell<T>> that is currently in use, because it's part of the code calling destroy(). Is there any remedy for this situation, for example blocking signal handlers for a brief period?

@GuillaumeGomez
Copy link
Member

@Susurrus is adding it it seems. Take a look here.

@eeeeeta
Copy link
Author

eeeeeta commented Jul 4, 2016

@GuillaumeGomez Ah, I see. Great! I've subscribed to that issue, so I'll close this one.

@eeeeeta eeeeeta closed this as completed Jul 4, 2016
@gkoz
Copy link
Member

gkoz commented Jul 4, 2016

There is an unsafe way (g_signal_handler_disconnect) but we haven't made it available as a safe one.

Ideally RefCell::try_borrow would make this unnecessary but it doesn't exist yet. Also note that if you can use Cell instead it doesn't have such a limitation.

Consider also WidgetExt::in_destruction.

@eeeeeta
Copy link
Author

eeeeeta commented Jul 4, 2016

@gkoz I implemented a workaround with RefCell::borrow_state (subscribed to that issue for updates on stability) - sadly in_destruction doesn't seem to work for me :( How would one go about getting the IDs to pass to g_signal_handler_disconnect?

@gkoz
Copy link
Member

gkoz commented Jul 4, 2016

The connect_ methods return the handler ids.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants