Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for "closure user_data" and "closure scope call" #618

Closed
sdroege opened this issue Jul 2, 2018 · 3 comments
Closed

Add support for "closure user_data" and "closure scope call" #618

sdroege opened this issue Jul 2, 2018 · 3 comments

Comments

@sdroege
Copy link
Member

@sdroege sdroege commented Jul 2, 2018

We should be able to autogenerate trampolines and safe bindings for all functions taking "closure scope call" (e.g. gtk_list_box_selected_foreach() https://github.com/sdroege/gtk-rs/blob/24c4c8305c235592c49bf2018d0f6e0afdeeb4d7/src/list_box.rs#L76-L102) and generally closures that have a user_data and destroy_notify (e.g. gtk_list_box_bind_model(), https://github.com/sdroege/gtk-rs/blob/24c4c8305c235592c49bf2018d0f6e0afdeeb4d7/src/list_box.rs#L38-L73).

The trampolines are basically the same as for signals, "scope call" closures can be FnMut and directly passed via the stack, other closures need to be stored (just like for signals) in a Box and need to be `'static'.

The Send / Sync bounds can be inferred from the corresponding bounds on the object (but like for signals an override would make sense).

@sdroege
Copy link
Member Author

@sdroege sdroege commented Jul 2, 2018

@GuillaumeGomez @EPashkin Do you see any problems here?

@GuillaumeGomez
Copy link
Member

@GuillaumeGomez GuillaumeGomez commented Jul 2, 2018

If the result is the same as the one in the linked PR, then it seems all good to me.

@EPashkin
Copy link
Member

@EPashkin EPashkin commented Jul 2, 2018

IMHO good idea

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants