On Thu, 2015-09-17 at 13:26 +0200, Christophe Fergeau wrote: > Hey, > > On Wed, Sep 16, 2015 at 11:23:46AM -0500, Jonathon Jongsma wrote: > > ========== > > > > We could deprecate this API, but I don't want to remove or break public > > API. So we still need to support transfers created with the current > > function. I'd like to propose a complementary API: > > > > Add a new public object SpiceFileTransferTask with the following > > characteristics: > > - it represents the transfer of a single file > > - it has a "progress" property, which represents the percentage of the > > file that has been transferred. The application can connect to the > > "notify::progress" signal to be notified when the progress of a transfer > > changes. > > - it has a "finished" signal so that the application can tell when the > > transfer of that file has completed > > - it has a "filename" property so that the application can display the > > filename next to the progress of the transfer if desired > > - it has a "cancel()" method, so that an application can cancel an > > individual file transfer[0] > > > > In addition to this new object, add a "new-file-transfer" signal to > > SpiceMainChannel. This signal will be emitted whenever a new file > > transfer task has been initiated (presumably by the drag-and-drop > > handler of the SpiceDisplay widget). > > This all sounds good to me, just one question, are you going to change > 'progress_callback' to report total progress, or is it going to stay as > it is now? (in other words, if an application only wants to display that > current file transfer operation is N% complete regardless of the files > being transferred, is there a way to do that?). Yeah, this is basically unrelated to the additional API that I proposed, so we can either choose to change this progress_callback or not, separately from the decision about whether to add the new API. I would support changing progress_callback to report total progress, but there's a slight hitch: internally all transfers are dumped into the same bin. So let's say that you issue two calls to spice_main_file_copy_async() sequentially: spice_main_file_copy_async(..., [files A and B], ..., prog_cb1, ...); - prog_cb1(bytes_readAB, [total size of A + B], ...); - prog_cb1(bytes_readAB, [total size of A + B], ...); (while those files are still being transferred) spice_main_file_copy_async(..., [files C and D], ..., prog_cb2, ...); - prog_cb1(bytes_readABCD, [total size of A + B + C + D], ...); - prog_cb1(bytes_readABCD, [total size of A + B + C + D], ...); - prog_cb2(bytes_readABCD, [total size of A + B + C + D], ...); - prog_cb2(bytes_readABCD, [total size of A + B + C + D], ...); You might expect that prog_cb1 would always report only the progress of files A+B, and prog_cb2 to only report the progress of files C+D. But unless we do some internal redesign, it would report all current transfers. I'm not sure that this is a problem, and unless somebody really wanted to change things, I'd probably keep the behavior above. But I thought I'd mention it since there is a decision to make. Jonathon _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel