Description: Have you wished for a way the zenity progress window could actually show "progress"? Here is one way to accomplish that..
This explanation is far longer than the actual program. If you're good with scripts, just download it read the brief comments there.
This is actually a fragment of my other submission, "avconvert" (you should go check that out). It's been made more generic to be useful as a stand-alone.
Not really a nautilus-script, just a shell script you can use elsewhere.
The situation is that zenity's progress can show one of two things - either a back-and-forth indicator as it receives any input, or a 0-100 percent-complete if it is given a number between 0 and 100. The challenge is handing it such a number from the output of an arbitrary program.
The idea here is to separate the zenity process from the program producing an output file, so that the file can be watched without regard for what's doing the writing or what it's standard output is.
The method is to start the watcher in the background, handing it parameters for the file to be watched and its anticipated size. The watcher then starts zenity. First, it waits up to 20 seconds for the specified target file to appear and have non-zero size. Then it displays a percent-complete window as the file size grows to approach the size estimate from the command line.
Further, a common complaint about zenity is that hitting cancel often does not kill the task piped to it. Here, with the watcher being a separate detached process, that would be even harder. However, by handing it the parent process id of whatever task it's watching, it will kill that process for you.
The download includes two files, "watcher" and "watcher-demo". The demo is a little test script that uses watcher to monitor the creation of a 10 meg file in /tmp.
In playing with the demo, you'll see how Cancel kills the current program without killing the parent. This allows your program to take whatever action is appropriate when the user cancels an operation.
HAVE FUN! (and check my other content, "Audio/Video/Image/Text/ISO Convert")Last changelog:
NOTE:
Some things you migh want to monitor with this script may produce output slowly, or after a long delay. For example, the output from "compress" could be inconsistent, and the output from a long pipeline may take a while to start.
There are two sleep statements in the script that you may need to adjust.
The first sleep statement in the script is there as an initial delay. Once watcher is started, it expects the target file to exist. The current "sleep 1" gives your program one second to create its output file. From that point on, watcher will wait for up to 20 seconds for the file to begin growing. However, it is possible that the initial delay may need to be longer.
The third sleep in the script, also 1 second by default, is the amount of time to wait between checks of the target file size. If the watcher tends to exit out before your file is completely written, this may be due to more than one second passing where the file has not grown. Making this sleep longer will fix that.
Interesting...
I am guessing you mean that a you are separately downloading multiple files which will later be combined to a single file?
If you know the expected final size of the result, and if you know the names of the multiple partial-files, you could monitor the aggregate size of the partial-files using something like:
du -a -c file1 file2 file3 | tail -1
or if the files are similarly names, then:
du -a -c partname* | tail -1
The other possibility might be to start multiple watcher scripts, one for each partial file. In that case, you'd have to guess for example that if there are 3 threads then the expected size for each is 1/3 of the expected total size.
Does this help?
-- Marc
Thanks...
What I have in mind is closer to the first scenario actually.
To provide more context if you're interested:
http://gnomefiles.org/content/show.php/Prozilla+Kaptain+Launcher?content=162866
Providing a progress bar could make a more complete GUI for this powerful download accelerator (apart from a non-functioning "--force" option of command-line proz).
I will assume your script controls the names of your download files. For example, $HOME/Downloads/abcxyz*
If you can be sure the names are unique and all start the same way as above, here is the change you need, and if it works for you I will post an update.
In my script, find the line containing
du -a -b "$1"
Change it to:
du -a -b -c "$1"*
Then, on the same line, add a new step before the awk. Change the part reading:
null | awk
to
null | tail -1 | awk
These two changes will cause the "du" to get the total for all files beginning with "$1", and to feed only the total to the awk.
Let me know how this works!
-- Marc
Unfortunately this seems too complicated for me at least at this stage.
I couldn't find out how and where ProZilla stores different segments of a file being downloaded. It creates a single file in the target location with the same size but I guess it's an entirely different thing.
All I've got is the information shown in the terminal window, and probably this is what I should rely on: "Total Bytes received XKb (Y.Z%)"
And also I just noticed that ProZilla terminal window may sometimes have different prompts which should also be addressed in addition to a progress bar, which seem to be beyond me at the moment.
So I should better hope that someone more skilled may take over and create a more complete GUI for ProZilla.
Sorry for taking your time, and thanks again...
I will assume your script controls the names of your download files. For example, $HOME/Downloads/abcxyz*
If you can be sure the names are unique and all start the same way as above, here is the change you need, and if it works for you I will post an update.
In my script, find the line containing
du -a -b "$1"
Change it to:
du -a -b -c "$1"*
Then, on the same line, add a new step before the awk. Change the part reading:
null | awk
to
null | tail -1 | awk
These two changes will cause the "du" to get the total for all files beginning with "$1", and to feed only the total to the awk.
Let me know how this works!
-- Marc
I will assume your script controls the names of your download files. For example, $HOME/Downloads/abcxyz*
If you can be sure the names are unique and all start the same way as above, here is the change you need, and if it works for you I will post an update.
In my script, find the line containing
du -a -b "$1"
Change it to:
du -a -b -c "$1"*
Then, on the same line, add a new step before the awk. Change the part reading:
null | awk
to
null | tail -1 | awk
These two changes will cause the "du" to get the total for all files beginning with "$1", and to feed only the total to the awk.
Let me know how this works!
-- Marc
I think it's very useful to have a working standalone progress dialog.
I'm working on a progress dialog module too but in python and pygtk (for my application "nautilus-pyextensions") and fighting against the same problems you described.
Cheers.
Ratings & Comments
8 Comments
I guess it's not possible to have several progress bars simultaneously in zenity (e.g. displaying a multi-threaded download), is it?
Interesting... I am guessing you mean that a you are separately downloading multiple files which will later be combined to a single file? If you know the expected final size of the result, and if you know the names of the multiple partial-files, you could monitor the aggregate size of the partial-files using something like: du -a -c file1 file2 file3 | tail -1 or if the files are similarly names, then: du -a -c partname* | tail -1 The other possibility might be to start multiple watcher scripts, one for each partial file. In that case, you'd have to guess for example that if there are 3 threads then the expected size for each is 1/3 of the expected total size. Does this help? -- Marc
Thanks... What I have in mind is closer to the first scenario actually. To provide more context if you're interested: http://gnomefiles.org/content/show.php/Prozilla+Kaptain+Launcher?content=162866 Providing a progress bar could make a more complete GUI for this powerful download accelerator (apart from a non-functioning "--force" option of command-line proz).
I will assume your script controls the names of your download files. For example, $HOME/Downloads/abcxyz* If you can be sure the names are unique and all start the same way as above, here is the change you need, and if it works for you I will post an update. In my script, find the line containing du -a -b "$1" Change it to: du -a -b -c "$1"* Then, on the same line, add a new step before the awk. Change the part reading: null | awk to null | tail -1 | awk These two changes will cause the "du" to get the total for all files beginning with "$1", and to feed only the total to the awk. Let me know how this works! -- Marc
Unfortunately this seems too complicated for me at least at this stage. I couldn't find out how and where ProZilla stores different segments of a file being downloaded. It creates a single file in the target location with the same size but I guess it's an entirely different thing. All I've got is the information shown in the terminal window, and probably this is what I should rely on: "Total Bytes received XKb (Y.Z%)" And also I just noticed that ProZilla terminal window may sometimes have different prompts which should also be addressed in addition to a progress bar, which seem to be beyond me at the moment. So I should better hope that someone more skilled may take over and create a more complete GUI for ProZilla. Sorry for taking your time, and thanks again...
I will assume your script controls the names of your download files. For example, $HOME/Downloads/abcxyz* If you can be sure the names are unique and all start the same way as above, here is the change you need, and if it works for you I will post an update. In my script, find the line containing du -a -b "$1" Change it to: du -a -b -c "$1"* Then, on the same line, add a new step before the awk. Change the part reading: null | awk to null | tail -1 | awk These two changes will cause the "du" to get the total for all files beginning with "$1", and to feed only the total to the awk. Let me know how this works! -- Marc
I will assume your script controls the names of your download files. For example, $HOME/Downloads/abcxyz* If you can be sure the names are unique and all start the same way as above, here is the change you need, and if it works for you I will post an update. In my script, find the line containing du -a -b "$1" Change it to: du -a -b -c "$1"* Then, on the same line, add a new step before the awk. Change the part reading: null | awk to null | tail -1 | awk These two changes will cause the "du" to get the total for all files beginning with "$1", and to feed only the total to the awk. Let me know how this works! -- Marc
I think it's very useful to have a working standalone progress dialog. I'm working on a progress dialog module too but in python and pygtk (for my application "nautilus-pyextensions") and fighting against the same problems you described. Cheers.