Filer_Action enhancement!

I’m having a look at the Filer_Action module, specifically with regard to adding a progress bar to its operations.

Does anyone have any comments on such a feature? Or any other ideas about fixes / enhancements to Filer_Action?

To clarify, in case some are not aware – Filer_Action provides the interactive action windows that pop up when you do something in the Filer. For example, if you drag an object from one Filer window to another, it’s Filer_Action that actually copies the files and reports errors, etc.

It occurs to me, having read the “Filer enhancements” thread, that people may be considering things that are actually implemented in Filer_Action, hence this thread.

Oh well, in the absence of any instant ideas, here’s an experimental Filer_Action with a progress bar: http://www.btinternet.com/~rik.griffin/Test_FilerAct.zip

It’s not perfect, but I’d be interested to know if people think this is an idea worth pursuing. Feedback to me via email or preferably right here, please! :)

Works well on my BBxM. This is worth pursuing. Very useful for when I’m backing up larger files or directories. Thanks for putting in the effort.

Yes, very nice idea. The only thing for me is the layout, the bar takes a lot of room in the window.
By the way, how do you know the position of the bar? It give an indication of progress but not the time left.

I put almost no thought into the layout of the window, so if anyone wants to come up with something nicer, please do. You’ll need to edit the template in FilerAct.Resources.UK, the window in question is called “FCount2”.

The icons I added are numbers 16,17 and 18:

16 is the well for the progress bar.
17 is the background for the bar, and the size of this icon defines where the bar will be displayed.
18 is the bar itself, but as long as it exists, it will be moved to the correct size / location.

Note that I’ve used Wimp_ResizeIcon so this won’t work on RISC OS 3.1 (I think).

At the moment my test version always uses the window with the progress bar, obviously in a production version there would be some sort of option – a system variable perhaps. Or, perhaps better, add a bit to the flags word in FilerAction_SendStartOperation, and add another switch to the *Filer_Options command.

That’d require support in the Filer too.

In reply to Peter’s question about how it works … making an accurate progress bar for a recursive operation on a directory tree is not as easy as it might sound. Unless you perform a enumeration of the whole structure before you start, you don’t know how much of the total operation is left at any particular point. And I rejected that method as it would be far too slow.

So, here’s what I came up with. Imagine you’re doing a “copy” operation on a simple directory structure:

dir
 |- dir_1
 |     |- 10 files
 |
 |- dir_2
 |     |- 5 files
 |
 |- 2 files

Filer_Action starts at the top of the selection, in this case a single directory “dir”. So we assign a progress value of 100% to “dir”.

We then inspect the contents of “dir” and see it contains 4 objects. So we assign each of those objects a progress of 25% (the value of “dir” divided by 4).

Basically each object has its own progress value, which is calculated by dividing the progress of its parent directory by the number of objects in that directory. Once an object has been processed by Filer_Action (copied, counted, whatever) its progress value is added to the total.

So in the example above, “dir_1” has a progress of 25%. Each of the files in that directory would be worth 2.5%. Each file in “dir_2” would be worth 5%. And the two files in “dir” would each be worth 25%.

The drawback of this method is that it’s basically counting objects, not bytes. So in our example, the progress bar might move quite slowly over 25% of its total while we are working on “dir_1”, especially if we are doing a copy operation and the files are large.

And then when we get to “dir_2”, those files might be tiny, and take not much time at all to copy, so the progress bar will move quickly over the next quarter of its length.

And finally when we get to the two files in “dir”, the progress bar will move in steps of 25%, even if those files are huge and take a long time to copy.

Actually, during a copy operation, I add half the file’s progress value when it has been read in to the buffer, and the other half when it has been written to the destination.

So, worst case, copying a single huge file, the progress bar is virtually useless. The best case is doing some operation on a large, but uniform, directory structure, the progress bar will be pretty accurate.

This is very nice. Works fine here on RPCEmu/RO 5.17. I don’t really understand the criticism that the progress bar is too big – looks fine to me. There is one very minor visual glitch – the top-edge border of the icon at the top of the window (the one that displays the filename) has been obscured. It looks like the dimensions may have changed slightly, creating an overlap with an icon inside it.

There is one oddity which affects both versions of Filer_Action – I’d be interested to know if it’s a general issue.

1. As the Filer to confirm everything.
2. Copy multiple files (File1, File2, File3) from one directory to another.
3. When the Filer_Action dialogue emerges, click ‘Yes’ to confirm copying of the first file. File1 will appear in the target window, but as an ‘incomplete’ file. The Filer_Action window will tell you that 0 files have been copied. It will then ask for confirmation you wish to copy the second file.
4. If you click ‘Abort’ at this stage, the first file remains incomplete, despite the fact that you’ve confirmed you wish to copy it. If you click ‘Yes’ to copy the second file, then File1 will turn into a ‘complete’ file in the target window, and File2 will pop up as an ‘incomplete’ file. Filer_Action will tell you that 1 file has been copied (not 2).

What seems to be happening, at least here (using HostFS) is that clicking ‘Yes’ doesn’t actually perform a full copy (as you’d expect it to). Instead, it’s starting the copy process, which is only completed when you ask to copy another file. Looks like a bug to me, unless I’ve missed something?

I’ll have a look in to that, but my initial reaction is that maybe “File1” is too big to be copied in one go.

Filer_Action grabs memory up to the Next Wimpslot size, then fills that buffer with as much as it can, before writing that data to the destination.

So if you have, say, a 1M buffer, but File1 is 1.5M in size, the first 1M of File1 will be copied, then the last part of it will be read in.

At this point, you’re asked to confirm the copy of File2, and if you click Yes, as much of File2 as will fit in the buffer will be read.

Then, ignoring File3 for a moment (or assuming File2 exactly fills the buffer), the last part of File1 would be written, and all of File2.

Does the observed behaviour change if you alter the size of the Next wimpslot?

I fixed the obscured icon border and uploaded a new archive.

Ah. Yes, I was copying some fairly big PDFs, partly to see how the progress bar works. Increasing the WImpSlot to accommodate the big files results in no ‘incomplete’ files littering the FIler window.

I still think the current behaviour is odd. I’d assumed that aborting a multi-file copy operation only cancelled those files coming after the Abort command had been issued, but it isn’t quite that simple. If the files all fit into the Next slot, then aborting an operation results in no files being copied, even if the user had earlier confirmed that, say, File1 and File2 could be copied by clicking ‘Yes’. However, if the files are too big for the WimpSlot, then aborting an operation can result in some files being copied, including partial copies that result in incomplete files.

In order to make things consistent, I guess it would be better if the Abort option could clean up after itself in cases where the files didn’t fit into the Next buffer. So, if the user aborts a copy operation at any stage, then the Filer should delete any files already copied, including both partial and complete ones. Or, if that’s not a good idea, just delete the last file copied if it’s not complete, to avoid half-finished copies ending up in directories.

“Abort” really does exactly what it says, stops the operation right away whatever it’s doing. And remember you can click Abort at any time, not just while the “Yes/No” buttons are displayed, and “Confirm” may not even be turned on.

I guess one answer would be to add a “No to all” button, like Windows has. We already have the equivalent of Windows’ “Yes to all”, except it’s called “Quiet”.

Fair enough. Maybe best to leave as is – sounds like I’m mixing up ‘No to all’ and ‘Abort’ functions.

I love the ‘Quiet’ button. So much more amusing than ‘Yes to all’ – just the right response for when the confirmations get annoying.

That’s a nice addition, thanks. The only thing I’ve just found is that on my HD here at work (RPC, RO3.7, 1.6GB HD) doing a count of the whole drive, the progress bar had reached the end before the count got out of !Boot (3344 files, 51MB) whereas it still had 30,000+ files (680MB+) left to go.

Also, I wondered if the progress bar might work better in blue (or a colour) rather than grey?

Oh, I’ve just spotted, does it occasionally lose wimp polls? Sometimes it’s not responding to a mouse click, or just typing whilst a count is in progress will cause occasional letters to be missed.

I like it, I hope it gets included in the ROM (once it’s proven).

For the options that have been requested, would it be possible to use the adjust button? (with corresponding help message added.)

Definitely not ready for submission to the ROM yet! I’ve reproduced the fault when counting large directory structures, I need to investigate that. And some way as swithcing the progress bar off (as discussed above) would probably be good.

Jess – do you mean that, for example, when Filer_Action asks for confirmation, that a Select click on No means “No to this object” and an Adjust click would mean “No to all”?

It’s an idea, but I’m not sure it’s in keeping with how the adjust button should be used …

Another possibility would be to change the “Abort” button to say “No to all”, when Filer_Action is waiting for a confirmation.

Although I’m not sure I like that either – buttons that change their meaning on a whim can be annoying. How many times have you gone to click “Faster” on a count operation, just as the count finishes and so you click “OK” instead and close the window? :)

Although having thought about it for five minutes I think that actually might not be so bad…

I was thinking of adjust-abort would be undo and adjust-skip would be skip all.

Adjust-faster could be skip all

(Alternatively, if the action were paused when the menu was up, these extra options could be on the menu, skip all should be on it anyway.)

Some thoughts:

Would it be possible to to have a bytes copied readout?

Could the “bytes to go” be made obvious that it refers to the current file? (perhaps by moving it to the pane above.)

Could the status at the top of that pane be moved to the title bar?
(That would allow my requests in the same size window).

Could the background of that window change between read,write, pause and waiting for input?

I’ve fixed the bug that Andrew Conroy pointed out, whereby the progress bar filled too quickly when processing very large directory structures. There’s a new version on my web site.

There are some good suggestions so far, thanks, I’ll see what I can come up with over the next few days!

That looks like it’s working more as expected now, thanks!

This is certianly a good addition to the OS, and hopfully can be committed to ROM once it’s finalised.

Argh, I thought it was working as expected, but it’s now counted the whole of the drive and the progress bar has only reached 1/3 way across!

OK thanks, I’ll investigate that!

I’m afraid I can’t make it go wrong here. Can you make sure you’ve not downloaded a cached archive, the file size of the zip should be 52059 bytes.

In the latest version on the web site, I’ve moved the progress bar to not take up any extra window space. I personally think it looks good, I’d be interested in opinions.

Thanks.

Just redownloaded the archive, and it’s the correct size but still finished when it’s 1/3 of the way along. I am testing this on RO3.7, if that’s anything to go by. I’ll try and test it on my BB tonight, but that has a significantly smaller disc image.

Also, the desktop seems very unresponsive whilst a count operation is taking place, not sure if this is to do with your changes or not.

Hmm, ok thanks, I’ll continue to try to replicate the problem. I’ve just counted a directory structure containing 2 million files and it worked OK, so it must be something other than sheer number. I’ll try it on a RiscPC too.

As for unresponsiveness, I can see where efficiencies could be made. At the moment, the bar is updated on every wimp poll, which will be 10 per second in “slower” mode or 1 per second in “faster” mode.

Another update to try out! The file size is 52,200 bytes.

Notable changes in this version:

• Improved speed in “slower” mode by about 50% (if processing many small files, it’ll be less on large files).
• Fixed bug whereby a count summary was incorrect if the operation finished in “faster” mode.
• Progress bar now increments based on bytes copied, so works inside large files.
• Various progress bar fixes.

I’m, as ever, grateful for any feedback!

PS – If you want to install this so it’s the default Filer_Action used, copy the “FilerAction” directory from the archive into your !Boot.Choices.Boot.PreDesk folder, and rename the file “TryApp” to “!Run”.

Right, that got to 100% when it had finished, thanks! Much more responsive too.