GSConnect / gnome-shell-extension-gsconnect

KDE Connect implementation for GNOME
GNU General Public License v2.0
3.12k stars 255 forks source link

[Feature Request] File Share Progress Bar #1511

Open busterbeam opened 1 year ago

busterbeam commented 1 year ago

https://github.com/GSConnect/gnome-shell-extension-gsconnect/blob/6a7bef6b61d419bad90665e27487484df8511d4f/src/service/daemon.js#L533-L552

I'm not accustomed to DBus is this where it calls the service to send file (providing it has the send file arguments/parameters)? Scanning through the DBusProxy documentation I'm finding it hard to understand where you can pass file data in chunks so you can measure the rate of progress.

Even using bluetooth file transfer do I get a progress bar in GNOME so why not for the same faster WiFi connection

andyholmes commented 1 year ago

If you want to add a progress bar over D-Bus, you'll have to modify the Core.Transfer class and then modify the GSConnectSharePlugin.shareFile() method to take advantage of it. Currently GSConnect doesn't export any information about the progress of transfers.

ferdnyc commented 1 year ago

You might even need to go down into Core.Channel which defines some of the methods for wrangling Core.Packets.

The this.channel.upload() called in Core.Transfer is implemented in Lan.Channel, but it's not immediately clear to me where best to monitor transfer progress.

(Unrelated to this request) there's a Gio definition for FileProgressCallback that will be updated by potentially-time-consuming operations like Gio.File.copy() and Gio.File.move(), that's how the file managers show progress on file operations.

Unfortunately the IOStream classes don't seem to have built-in support for the same sort of reporting (probably because a stream has no fixed length). That makes the Gio.OutputStream.splice_async() and Gio.InputStream.read_all_async() methods we use to transfer data over the stream a bit trickier to monitor. Their GAsyncReadyCallbacks only fire on completion of the operation.

It may be possible to break stream transfers up so they're done in multiple chunks in a loop, then progress could be updated each time through. But I don't think Gio will generate any progress data itself, at least not any that calling code can get at.

andyholmes commented 1 year ago

Yeah, it's been awhile since I looked into that part of GSConnect. I'd expect this to take more or less three steps:

  1. Core.Transfer: implement progress tracking

    Instead of using Gio.OutputStream.splice_async(), you'd use e.g. Gio.InputStream.read_bytes_async() and keep looping while tracking bytes read vs bytes expected. Either using a property or a signal to notify of changes.

  2. Core.Transfer: implement D-Bus interface

    Each transfer would probably have to export itself as a simple D-Bus interface, otherwise you could write a simple transfer manager that tracked each transfer and export that as a single interface.

  3. Elsewhere: implement D-Bus proxy/client

    Once transfers are being exported on D-Bus, you'll need to write a small Gio.DBusProxy subclass or similar to consume the information so it can be used to display the progress of transfers somewhere.

This isn't all terribly complicated, but it will take a bit of commitment to get it over the finish line :)

busterbeam commented 1 year ago

@andyholmes thank you for your input it was very helpful. I will attempt to implement this