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

btsync-gui: System notifications on a completed synchronization/changes #137

Open
v-ko opened this issue Jun 24, 2014 · 6 comments
Open

Comments

@v-ko
Copy link

v-ko commented Jun 24, 2014

It would be very useful to have Dropbox-like notifications on sync. Even if it's not perfect initially (to display specific info on what changed) - having a notification on sync would be great to have an idea if some new photo (or anything else for that matter) is synced without opening the GUI.

@v-ko v-ko changed the title System notifications on a completed synchronization/changes btsync-gui: System notifications on a completed synchronization/changes Jun 24, 2014
@tuxpoldo
Copy link
Owner

Two things to do:

  1. Discover the best standard notification system (libnotify?)
  2. Discover which information coming from the Sync API may trigger notifications....

@v-ko
Copy link
Author

v-ko commented Jun 26, 2014

On 2 : With get_folder_peers you get the last timestamp for each peer and store them as a variable (list). Update this list periodically and compare with the last saved list. If there are any changes - isolate them in a separate list, and then group by peer (e.g. "3 folders synced with device-X", next notification "folder Y synced with device-Z" (if it's a single folder that synced to that device) until all the entries in the list with changes are parsed).

I'm not familiar with the Sync API and btsync-gui codebase but if you give me some pointers I can try to write the code.

@tuxpoldo
Copy link
Owner

This is a very good approach. Perhaps it is possible also to get more detailed data by interrogating the folder contents, but there is one aspect that must be kept in consideration: API flooding.

When 1.3.x was released, I noticed that every API call took far more time to complete in comparison to 1.2.x. Because of this I implemented a dynamic adaption of update intervals based on the real API processing time. I will try to get out as much as possible without increasing dramatically the number of API calls...

@tuxpoldo
Copy link
Owner

tuxpoldo commented Jul 5, 2014

OK - currently the API calls for keeping the UI up to date are originated by timeout handlers both in the BtSyncStatus class and in the BtSyncApp class. The implementation of notifications would imply increasing the number of calls, causing the UI to become more and more unresponsive. I think that's now time thinking about the separation of the status update mechanism and the GUI itself (by moving the API stuff in a separate thread). Before starting a major redesign, I will wait a little for updates to the Sync API - perhaps there will be some news shortly...

@v-ko
Copy link
Author

v-ko commented Jul 7, 2014

Just throwing some thoughts out there : the web interface updates instantly on synchronizations. Can the sync-gui connect to the socket as a web client and watch for changes (it's not even needed to extract the data from there - just diff the page if it's updated), and make the API calls only if there's a change on the web interface. That's kind of a hack, but it may solve your frequent-API-call problem altogether (by making the calls only when there's actual changes). It means enabling the web interface though, which I'm not sure is desirable - I read you've disabled it for security reasons.

@tuxpoldo
Copy link
Owner

tuxpoldo commented Sep 2, 2014

I know - but I prefer not to use the web interface, since the BitTorrent Sync developers often change the undocumented interface making updates a real hazard. I'm quite sure, they will improve the API in one of the future releases (at least I heard some rumours about it).

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

No branches or pull requests

2 participants