Review of attachment 342292 [details] [review]:

::: gio/gfile.c
@@ +3408,3 @@
  *     information, or %NULL if progress information is not needed
+ * @progress_callback_data: (closure progress_callback) (nullable): user data to pass to @progress_callback
+ * @callback (scope async): a #GAsyncReadyCallback to call when the request is satisfied

Missing ':' between argument and annotation.

@@ +3409,3 @@
+ * @progress_callback_data: (closure progress_callback) (nullable): user data to pass to @progress_callback
+ * @callback (scope async): a #GAsyncReadyCallback to call when the request is satisfied
+ * @user_data (closure callback): the data to pass to callback function

Missing ':' between argument and annotation.

AFAIR, the reason why we didn't bind this is because the GDestroyNotify would be called twice — once for the progress callback and once for the callback — and the bindings didn't cope with that.

Created attachment 350629 [details] [review]
Fix g_file_copy_async() annotation

Add missing :

(In reply to Emmanuele Bassi (:ebassi) from comment #2)
> AFAIR, the reason why we didn't bind this is because the GDestroyNotify
> would be called twice — once for the progress callback and once for the
> callback — and the bindings didn't cope with that.

For what its worth I use it successfully from pygobject: https://github.com/TingPing/transmission-remote-gnome/blob/d3c509a9793e457054994eb791520f95b31c801c/trg/preferences_dialog.py#L206

(In reply to Patrick Griffis (tingping) from comment #4)
> (In reply to Emmanuele Bassi (:ebassi) from comment #2)
> > AFAIR, the reason why we didn't bind this is because the GDestroyNotify
> > would be called twice — once for the progress callback and once for the
> > callback — and the bindings didn't cope with that.
> 
> For what its worth I use it successfully from pygobject:
> https://github.com/TingPing/transmission-remote-gnome/blob/
> d3c509a9793e457054994eb791520f95b31c801c/trg/preferences_dialog.py#L206

You're not using the callbacks, which is what I'm worried about.

That's basically the equivalent of using GTask<g_file_copy>.

I did a test with the progress callback at the time and while the api was a bit odd (it required a tuple for the userdata?) it seemed to function. Eitherway I don't think the annotations are wrong and if implementations cannot handle it that is on them.

> That's basically the equivalent of using GTask<g_file_copy>.

Well its not like GTask is easy to use from python so this function is much nicer =)

Just as an update I tested this in GJS and it works perfectly:


    let file = Gio.File.new_for_path('test.txt');
    let dest = Gio.File.new_for_path('test2.txt');
    file.copy_async(dest, Gio.FileCopyFlags.NONE, GLib.PRIORITY_DEFAULT, null,
        (current, total) => {
            print(`${current}/${total}`);
        }, (obj, res) => {
            print(obj.copy_finish(res));
    });

I really see no harm in merging this.

Review of attachment 350629 [details] [review]:

If this works with GJS then sounds good to me.

Attachment 350629 [details] pushed as 7c5cd29 - Fix g_file_copy_async() annotation