Show which file is currently backuped in the GUI

Don’t worry about it - take your time and learn what you can while doing it.

I actually am a programmer (granted, not in Angular.js or using GitHub) and it took me over 2 months to get my first UI based fix into a pull request. Yep - 2 months to add a single period to a sentence. :blush:

1 Like

So reflecting the points mentioned by Kenneth, the modification is fairly easy and smal:
I just added the following lines to the JavaScript file “…\Duplicati 2\webroot\ngax\scripts\controllers\StateController.js”:

var filename = $scope.state.lastPgEvent.CurrentFilename;
if (filename.length >= 23) {
  var filename2display = ' (...' + filename.substr(filename.length - 23) + ')';
} else {
  var filename2display = ' (' + filename + ')';
}                    
text = gettextCatalog.getString('{{files}} files ({{size}}) to go', { files: filesleft, size: AppUtils.formatSizeString(sizeleft) }) + filename2display;

The file which is currently backuped is already known within the state variable. Just need to extract the CurrentFilename and add it to the StateText. The current filename contains the complete path, so I take the last 23 chars starting right because this was the number of chars which “fitted into” the progress bar…
Any better idea?

This did the job for me :slight_smile:

Here the complete function:

function updateStateDisplay() {
    var text = gettextCatalog.getString('Running ...');
    var pg = -1;
    if ($scope.state.lastPgEvent != null && $scope.state.activeTask != null)
    {
        text = ServerStatus.progress_state_text[$scope.state.lastPgEvent.Phase || ''] || $scope.state.lastPgEvent.Phase;

        if ($scope.state.lastPgEvent.Phase == 'Backup_ProcessingFiles') {
            if ($scope.state.lastPgEvent.StillCounting) {
                text = gettextCatalog.getString('Counting ({{files}} files found, {{size}})', { files: $scope.state.lastPgEvent.TotalFileCount, size: AppUtils.formatSizeString($scope.state.lastPgEvent.TotalFileSize) });
                pg = 0;
            } else {
                var filesleft = $scope.state.lastPgEvent.TotalFileCount - $scope.state.lastPgEvent.ProcessedFileCount;
                var sizeleft = $scope.state.lastPgEvent.TotalFileSize - $scope.state.lastPgEvent.ProcessedFileSize - $scope.state.lastPgEvent.CurrentFileoffset;
                
                pg = ($scope.state.lastPgEvent.ProcessedFileSize + $scope.state.lastPgEvent.CurrentFileoffset) / $scope.state.lastPgEvent.TotalFileSize;

                if ($scope.state.lastPgEvent.ProcessedFileCount == 0)
                    pg = 0;
                else if (pg >= 0.90)
                    pg = 0.90;

                var filename = $scope.state.lastPgEvent.CurrentFilename;
                if (filename.length >= 23) {
                    var filename2display = ' (...' + filename.substr(filename.length - 23) + ')';
                } else {
                    var filename2display = ' (' + filename + ')';
                }                    

                text = gettextCatalog.getString('{{files}} files ({{size}}) to go', { files: filesleft, size: AppUtils.formatSizeString(sizeleft) }) + filename2display;
            }
        }
        else if ($scope.state.lastPgEvent.Phase == 'Backup_Finalize' || $scope.state.lastPgEvent.Phase == 'Backup_WaitForUpload')
        {
            pg = 0.90;
        } 
        else if ($scope.state.lastPgEvent.Phase == 'Backup_Delete' || $scope.state.lastPgEvent.Phase == 'Backup_Compact')
        {
            pg = 0.95;
        } 
        else if ($scope.state.lastPgEvent.Phase == 'Backup_VerificationUpload' || $scope.state.lastPgEvent.Phase == 'Backup_PostBackupVerify')
        {
            pg = 0.98;
        } 
        else if ($scope.state.lastPgEvent.Phase == 'Backup_Complete' || $scope.state.lastPgEvent.Phase == 'Backup_WaitForUpload')
        {
            pg = 1;
        } 
        else if ($scope.state.lastPgEvent.OverallProgress > 0) {
            pg = $scope.state.lastPgEvent.OverallProgress;
        }
    }

    $scope.StateText = text;
    $scope.Progress = pg;
};

Hope this helps!

1 Like

It’s great that you were able to do that! I knew the data was there, I just didn’t know nginx enough to get it where we want it. :slight_smile:

A few questions / suggestions I have are:

  • Are you using this for yourself or planning to submit it at GitHub?
  • Is there any system load / performance issues related to this change? (I’m guessing not really as my assumption is it updates only as frequently as the progress bar already does, so it’s not like it’s showing every single file)
  • How well does the 23 character length (26 including space & parenthesis and 29 including “…”) fit with screen resizes (think mobile display size)?
  • Did you consider including a piece of the beginning of the path, then “…” (if necessary) then the end of the path? Using indexes of early and last Path.PathSeparator might aid in that soft of formatting (keeping in mind Linux, MacOS and UNC paths might start with one or two path separators.)
  • Would you mind including a screen shot of the results of your code for those of us that are too lazy to make your change? :slight_smile:

One thing to keep in mind is that the current progress bar information is already a bit confusing to some people who think “files to go” means files left to be backed up, rather than the actual “files left to be scanned for changes”. So having actual file NAMES visible might strengthen that “hey, I didn’t change file X why is it being backed up again!”

That being said, personally I’d rather have the path patch you’ve created than not and deal with de-confusing the rest of it another time. :slight_smile:

Initially it was planed only for “internal” use as I thought no one would be interested in it, but on request I can try to submit it to the project (need to figure out how :thinking:…).

I have already thought about the different resolutions and the different devices and I know that my “23-char-solution” does not fit in except with my configuration :grinning:.

Another problem is that, if you have a long name for the backup job you would neither see the “files to go” message nor my extension (will post some screenshots)

I have several ideas on how to do it alternatively and maybe overcome these issues:

  • extend the progress bar from single line to double line (already tried it but did not work with the knowledge I have on CSS! Need assistance…)
  • add another section within the backup job overview which will only show up if an active task is running… (or something like that)

Your suggestion to include a piece of the beginning of the path and the end is surely a better way how to to it!

I think performance is not an issue (from my knowledge), because the Angular scope-variables StateText and lastPgEvent are already there. No extras! Only some extra rendering time within the page to show the variables value, which should be OK.

Will post some screenshots!

It can look like this, if the backup job name is short enough (old version with only the ending of the current file name):

BUT: if the name is too long, you will see something like this:

Hmm, that may be yet another reason to do something like discussed in Make status bar a link to backup

Also, this will get worse with newer releases where speed is also displayed.
21

Hmm, maybe use smaller fond and some text wrapping to two line of text?
Text wrapping is used for example in error popups

image

Or increase width of green box?:slight_smile:
This if size of box when I have duplicati webapge on fullscreen

And this is when browser window is only on half of LCD (full hd)

How about that one: separate line within the backup job summery

With long path and filenames one could limit this like JonMikelV said…

Thanks for the screenshots - now we have a better idea how your code looks!

This is YOUR code, so feel free to take / ignore any of the suggestions we all have. :slight_smile:

That being said, while I agree with @Pectojin that an expandable bar could provide much more space / detail, I also think implementing something like that could take a while and I’d really like to see this info in there ASAP, even if it’s not in an “optimal” state.

Personally I pictured the satus bar being 2 lines tall (maybe the 2nd line with a smaller font) something like this…
image


In case you haven’t done it yet, to submit the code you COULD ask somebody else to do it for you, but if you have the time I strongly suggest you do it yourself. That way you can claim to have contributed code to an Open Source project! :smiley:

If you don’t have one already, you’ll want a (free) account at GitHub.

Once you’ve got that you can submit the proposed change a number of different ways, but the easiest is probably to just use the GitHub web interface to go straight to the file you want to change and click the Edit icon (to the right of the “Raw”, “Blame”, and “History” buttons).

The link directly to the StateController.js file is:

1 Like

Would like to contribute something to the project… :grinning:
Thanks to point me to the file on GitHub and how to do it, will check that.

I think I somehow figured out how to modify the CSS that two lines show up in the UI:

But for example if someone uses an iPhone6 it looks like this :disappointed:

The extension of the job is maybe the better way to go

To be fair, on my iPhone 7 the task bar currently says “Next schduled task: Server tomor”. And my sever isn’t named “Tomor” :wink:

So while it is useable the web UI isn’t perfect by any means on mobile currently :slight_smile:

Awesome work!

I agree with @Pectojin whom I think is saying that “as long as you work within the current UI limitations, it should be fine”. :slight_smile:

That being said, there’s no reason you couldn’t put it in BOTH places… Let the toolbar be visible for what it is and let the job details (if expanded) allow line wrapping for full details. :smiley:

1 Like

You read me like a poem :wink:

This would be cool :slight_smile: Especially because the path may be too long for the top bar, then if it is and you need more than the last 20-40 characters of the path then you can see it by expanding the job details.

We should be carefull for how most people will interprete this…
==> Hey, why is my file xxx being processed? It didn’t change since 3 months!

1 Like

Yes, this could be confusing for users who don’t know exactly how the mechanism works. Some other thoughts:

  • As long as nothing is added to an upload volume, a text like “Scanning files” or “Analyzing files” could be displayed. If a file is changed since the last backup, this text could be replaced with “Processing X:\Folder\Filename.ext” while adding changed blocks to the upload volume. Backdraw is that 99.99% of the time the “Scanning files” text is displayed and a fraction of a second a changed file appears. This would hardly be an improvement, because you don’t have the time to read which file is processed and have no clue which files and folders have been processed and which not.
  • As far as I know, there is no particular order files and folders are being processed. The first folder that is listed by the OS is the first folder that is processed by Duplicati. There is no indication how far the backup is completed.
  • The status bar should be kept as clean as possible. Originally, only the number of files and MB’s were displayed in the status bar. Adding upload speed sounds useful, so that info is added. Adding the current file that is processed is also interesting, but what if others would like to see the total amount of uploaded data, the time that the backup is running etc.? The status bar will become more and more stuffed with info, it’s not what it’s intended for. I think it’s better to wait for a detailed status window. As far as I know it’s a planned feature.

It’s the wild west, I think almost any feature is technically a planned feature. It’s just about getting there :slight_smile:

I’m wondering what we’d have to do to get some UI/UX folk hooked and contributing their skills. I don’t dislike the current UI, but I have this vague feeling that we could improve it a lot with some smaller changes to it.

Edit: I should add. I do think we should be careful about not bloating the UI with too much information in the wrong places, but it’s always that balance :slight_smile:

1 Like

It sounds from @kees-z like there is an overall design esthetic to be attempted, which is great!

And while I do like some of the designs presented in the “detailed status window” linked topic from above, I again say I’d rather see the feature in a “Current file” line of the job menu sooner than as part of a full-fledged status window later…

It kind of sounded like the “Current file” wrapable line was being favored, so assuming we haven’t scared @dbddhkpde off yet I’d say go for that! :slight_smile:

It should be that much easier to move the info to the more full featured status window when comes along down the line. :smiley:

(Side benefit - as its own line it might be possible to include more detail like whether the file is being “scanned for changes” vs. flat out being “backed up”.)

1 Like

Thanks for all the comments. I agree, that the progress bar should be kept clean!
I will than go for the backup job summary adding the current activity: backing up, processing file, uploading… all the states that the last page event comes up with.

How about this one (screenshot):

If the file processing is done the current action info will hide again. Only the progress bar will indicate what’s going on until it finishes…

Bad thing about this: :flushed: I did the “small” progress bar with inline html/css. Need to figure out how to integrate this into the correct places. AND some translation tags need to be created too…

1 Like

Cool! :grinning:
Any chance that this could be combined with changing the icons for running and queued backups?

Ahhh, the joys of scope creep. :smiley:

1 Like