132.sync progress indicators #142
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Because the magic-folder status queue will only display the last 20 operations, keep a record of all previously known/observed operations. This will allow progress calculations to take into account operations that may have otherwise been dropped from the queue.
A (temporary?) workaround for Tahoe-LAFS ticket #2954 whereby 'percent_done' will sometimes exceed 100%
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR reinstates a rudimentary, text-based progress-indicator for magic-folder upload/download operations, displaying to the user the total percentage of bytes transferred for a given folder's current syncing operation. Previously, this functionality was disabled due to a series of strange behaviors observed with the magic-folder status API, among them:
percent_donewell in excess of "100%" (see Tahoe-LAFS Trac ticket 2954)All of these behaviors drastically skewed the calculation of overall progress on the Gridsync-side, resulting in a progress indicator that appeared inaccurate at best or completely nonsensical at worst. Accordingly, this PR resolves these three issues by 1) keeping an internal record of known operations rather than trusting the magic-folder queue blindly (thereby allowing items that recently fell off the queue to be retained for the purposes of progress-calculation), 2) artificially capping the
percent_donefor individual transfers at 100% when calculating overall bytes transferred (thereby preventing the display of overall progress in excess of 100%), and 3) ignoringtransfer_progress_updatedevents that would push the overall transfer progress down to "0%" for a very brief period of time (thereby eliminating the display of short-lived and drastic drops during full scans).While these workarounds are hackish and not ideal, allowing the user to at least get a overall sense of how far along a given syncing operation is (displayed, in this case, as an overall percentage of bytes transferred) is arguably better than having nothing at all...
Note that, although Gridsync does calculate the approximate time remaining for a given syncing operation, this information is not yet displayed anywhere in the UI (since, with magic-folder, 100 1kb files takes an order of magnitude longer to upload than 1 100kb file, making said time-calculations inaccurate when the sizes of pending files differ drastically -- which is usually the case).