grand total of volume/file number to process ahead

[nbehrnd]

The tab sources lists the volume of the folders to process and their corresponding file number. While these represent the maximum of work ahead e.g., for the initial backup without consideration of compression and deduplication of the backup written by vorta, I would like if there were an additional line summing up all directories and files scheduled for the backup. Especially in a modular backup profile selecting multiple files and directories where «Source Folders and Files to Back Up» can not be seen at once but requires to scroll through the entries, this grand total would help to set the continuously updated progress report (in the lower section of the same tab) into context.

[m3nu]

This will be pretty heavy to implement and needs a similar amount of processing as the actual backup.

Vorta also outsources those parts to Borg, so it doesn't have those kinds of details really. What you describe is more similar to a continuous sync solution, like Nextcould with a watcher.

[nbehrnd]

There might be a misunderstanding; an illustration might assist to clarify the line of thought:

Since vorta already crawls through the folders and files to be considered, the idea was to add the individual counts of the original data before vorta relays them to borg, and to report the total of the user's selection. This would require a one-time computation (perhaps an os.walk, so I speculated); the screen photo illustrates the result with the blue line added.

To contrast: The idea is not about a static prediction how much platter space the backup eventually requires when applying compression and deduplication like in a dry-run (in luckybackup, a simulation). Nor was my idea about a dynamic report/updated progress bar (as e.g., for a download with wget) to let vortra/borg estimate how much work/time is necessary to complete the backup in progress. I agree with you, this indeed were a repeated, unnecessary and expensive computation. In the case of performing a remote backup, such an estimate were of limited value because vorta/borg has no control e.g., on the available bandwith.

[m3nu]

borg create already has a dry-run option. This would be most accurate, if we can get the result back.

Otherwise you are suggesting to just display the sum of files and bytes in the Sources tab?

[nbehrnd]

You hit the nail. Yes indeed, the suggest is to add a line about the sum of files and bytes in the Sources tab.

[real-yfprojects]

Calculating the sums is very easy. But integrating it into the GUI in a pleasing way is more difficult.

[nbehrnd]

@real-yfprojects Filing the suggest as an idea in this forum already indicates a lesser severity than filing for a bug/an issue because something does not work. Based on this perspective, I think we share the same page here, i.e. to prevent vorta's clear GUI to suffer from information overload/visual clutter (inspiration from Edward Tufte's works on typography) by rushing into a redesigned layout.

[real-yfprojects]

Maybe the sources table view could have a summary line and the bottom like the table header but as a footer. I searched on the internet whether anybody has coded something like that before but unfortunately I couldn't find anything.

[nbehrnd]

Vorta's tab «repository» summarizes the volume of all snapshots of a backup profile on the platter if 1) it were a mere copy of the original data, 2) after deduplication, 3) the capacity actually used by all snapshots after deduplication .and. compression:

Lacking knowledge of PyQt, I wasn't able to identify which of the files collects and eventually reports this information on the GUI. To me, it looks like the effort is spread over multiple files. Yet it is a speculation one could reuse this kind of display on tab «sources» to summarize the number of files considered by the current backup profile.

To illustrate, see the edited screen photo below. Here, I imagine the frames excluding certain files and folders to be a bit less tall than they are now (e.g., as indicated by the blue rectangles). To adjust their dimension would not hurt much, because 1) only a little space is trimmed off, and 2) one already may scroll up/down if these display many entries. The space not used by them however may be used by the summarizing line inserted. Then, the position of the buttons «start backup» and «cancel» would stay both the same as at present, and as seen on the other tabs «repository», «schedule», «archive», and «misc», too.

[real-yfprojects]

I imagined a table footer not a footer line at the bottom of the window. I also found some implementation details:
Official Code Editor Example
QHeaderView Class
It will also make sense to migrate the source table to Model/View Programming.

[nbehrnd]

The pattern I displayed merely serves a suggestion. If you identify a different pattern which is easier to work with (as in maintaining the underlying code, eventual access from the GUI as a subtle indicator, etc.), of course use the one more suitable. With pointing to specific pages of qt's documentation, you set an incentive to get familiar with the underlying concepts new for me. Thank you equally for this one.

[jetchirag]

I've designed a mockup for implementing summary row. This implements a custom QWidget to handle two tables (for our main source list and a summary table which only utilises the headers without rows of its own) aligned without any margin.

I imagined a table footer not a footer line at the bottom of the window

@real-yfprojects I believe this GUI is similar to what you were referring to

[real-yfprojects]

This is exactly what I had in mind! 👍
Regarding the implementation, did you try subclassing QTableView and adding an additional QHeaderView to its bottom?

[jetchirag]

@real-yfprojects Final implementation is a part of my GSoC proposal so I haven't looked too deep into other methods yet. I'll check.