GNOME Bugzilla – Bug 616044
[annotation] Scope type for progress callbacks of async gio method
Last modified: 2018-02-08 11:52:11 UTC
g_file_copy_async takes a GFileProgressCallback which is called it zero or more times after g_file_copy_async has returned. (It's not called at all if some error occurred.) I don't think any of the existing scope types describes this behavior. (In fact, I don't see how a binding can wrap this correctly at all. How do you know when the GFileProgressCallback will not be called anymore? Maybe when g_file_copy_finish returns.)
(In reply to comment #0) > (In fact, I don't see how a binding can wrap this correctly at all. How do you > know when the GFileProgressCallback will not be called anymore? Maybe when > g_file_copy_finish returns.) yes perhaps this could be something like: * @progress_callback: (scope async=done_callback): function to callback * with progress information * @progress_callback_data: user data to pass to @progress_callback * @done_callback: a #GAsyncReadyCallback to call when the request is * satisfied * @user_data: user data to pass to @done_callback where the annotation would mean "@progress_callback can be called until @done_callback has been called" This is a pretty uncommon case though, and it might be better to just add a new version with a progress_callback_destroy_notify arg, and Rename it over the existing version. (That might also be a bit of a torture test for bindings too though... having a destroy-notified callback and an async callback in the same call.)
Note at least gjs won't handle two callbacks for one function now. It could be made to do so but...
*** Bug 708297 has been marked as a duplicate of this bug. ***
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gobject-introspection/issues/25.