Filer_Action enhancement!

I agree. The stuff like “Paused” or “Finished” could just go in braces after the title, e.g. “Counting files (paused)”.

Simpler and cleaner to just use a hyphen eg ‘Counting files – Paused’ or ‘Counting files – Finished’

I’m not ignoring people saying put the status into the title bar – but I did wonder whether you still feel that way now the window has been reduced in size vertically. Do we want the window to be smaller still? When I have time I’ll do some mock ups and post screenshots.

Re: slabbing in – I don’t feel that’s something I should unilaterally change in Filer Action. Like it or not the RISC OS style is for display fields to be slabbed in and buttons to be slabbed out. Although I concede that FA is inconsistent, seeing as the lower two display fields are not slabbed! Hmm …

Talking of elipses … (see what I did there) my initial reaction is that this would be quite slow, involving repeated calculation of the string width, but I’ll see if I can give it a go.

I agree that this is a great improvement!

don’t feel that’s something I should unilaterally change in Filer Action

"The Style Guide is in need of an overhaul […]"

calculation of the string width

Are there any other aspects of the OS where such code could be re-used, if developed/optimised for use here? If too slow then (although it’d be a hassle) perhaps the results of the forthcoming few file calcs could be cached. But what happens when the cache becomes empty? Pause/calc or omit the ellipsis and have a flickering effect as it appears/disappears? Perhaps your initial reaction will be right and that’ll be that!

Screenshot of the latest iteration.

Note that if the status field is moved into the title bar, you need room for things such as “Deleting files – 27 locked item(s) not deleted”.

Yep. That’s more like it.

I haven’t commented up until now, as I preferred the early version with the distinct, “slabbed in” progress bar but I seemed to be in a minority. I’m a bit of a Style Guide traditionalist. Apart from anything else, if applications adhere reasonably strictly to the Style Guide, it becomes easier to predict how possible future Wimp changes to the way things are drawn might interact with existing applications. So, this latest iteration is welcome as it keeps within the spirit of the Style Guide nicely and still looks good.

That said – as soon as the display field for the current filename became one line high in this latest iteration, suddenly the separate slabbed in progress bar looks a bit over the top maybe. It must be a bit of a pain to keep redesigning things, but I wonder how it would now look if the progress bar was put within the ‘well’ of the display field, with a reasonable amount of vertical spacing between the text and bar? Of course you may well have tried this and discarded it already. Personally I’d consider adding a bit of vertical space between the “‘n’ files copied” text and the buttons below too. If I were to get really picky I think I’d also make sure that the left/right gap between window’s edge and 3D border was the same as the top edge gap too :-D

It’s certainly good as it stands and all this concentration on near-trivia detracts from more important issues. For example, have you given any thought to how multiple operations might be presented? Mac OS X’s finder makes new operations appear as an extension of whatever operation window is already present, so you get a stack of operations all in one window. That makes it easy to manage and see all concurrent file operations. With current RISC OS designs, you instead get separate windows for each. If there was a desire to come up with a single-window approach, it might influence the button position though – e.g. stack them vertically on the right hand edge, or at least, move them there if more than one operation is in progress (so it doesn’t look too wide and odd for just a single operation).

Note that if the status field is moved into the title bar, you need room for things such as “Deleting files – 27 locked item(s) not deleted”.

Could the notification area at the bottom be used to display the number of items not deleted? The title bar would then simply read “Deleting files – Finished”

I like this version.

Mac OS X’s finder makes new operations appear as an extension of whatever operation window is already present, so you get a stack of operations all in one window. That makes it easy to manage and see all concurrent file operations. With current RISC OS designs, you instead get separate windows for each.

I think separate windows feels more in keeping with RISC OS (and should be the default)

I wonder how it would now look if the progress bar was put within the ‘well’ of the display field, with a reasonable amount of vertical spacing between the text and bar?

have you given any thought to how multiple operations might be presented?

In short, no :) I’d planned a cosmetic overhaul of Filer Action with a few bug fixes thrown in. If there’s a desire for some “über file operation manager” type application, I’d suggest it be done as a separate project.

I think separate windows feels more in keeping with RISC OS (and should be the default)

I agree. I haven’t used MacOS so I can’t comment on it specifically but it is the RISC OS way to have separate windows for each “document” – we don’t have all text documents open in the same editor window or all web pages in the same browser window. And I think that’s a strength of the RISC OS desktop.

Could the notification area at the bottom be used to display the number of items not deleted?

Yes, at the moment I’ve just moved all messages that used to be in the top display field into the title bar. Sending some of them to a different field will just require going through the possible outputs and reassigning their destinations – not hard but it’ll take some time.

Regarding slabbing in as being traditionalist isn’t there an inconsistency between the filename/progress bar being slabbed in and the files counted/bytes total not being slabbed in?

You could put everything in 1 display field then multiple operations – if that’s the way things went – would be bounded by the display field.

I wonder how it would now look if the progress bar was put within the ‘well’ of the display field, with a reasonable amount of vertical spacing between the text and bar?

I think the previous version looks better (however if the gap were reduced it might not)

some “über file operation manager” type application, I’d suggest it be done as a separate project.

I think separate windows feels more in keeping with RISC OS (and should be the default)

I agree. I haven’t used MacOS so I can’t comment on it specifically but it is the RISC OS way to have separate windows for each “document”

I can see it may sometimes be convenient for operations to be stacked, e.g. completed counts, grouping copies by device (if wanting to pause operations on a particular shared device because there is a high demand elsewhere). But it does sound like an über project. And the stacked counts example could be implemented by a separate application – indeed, one probably already exists.

Regarding slabbing in as being traditionalist isn’t there an inconsistency between the filename/progress bar being slabbed in and the files counted/bytes total not being slabbed in?

Yes, as was remarked on up there somewhere :) How does this look?

If you go for the styleguide look the progress bar should be in its own well and the number fields should be deeper. Otherwise fine. I think it illustrates that you either remove all the ‘slab ins’ or follow the style guide. Definitely like the status in the title bar. I also like the single line path name.

[slabbed text] Yes, as was remarked on up there somewhere :) How does this look?

Hmm, this thread is developing a few similarities with trying to achieve consensus on Wikipedia. I guess that’s one problem with opening up the sources. If the Style Guide nailed down things like presentation of data fields/results, justification etc. then it might simplify things. Perhaps it does do that, but I don’t remember reading it.

• Status in the title bar is good
• Progress bar in the filename well is good (I don’t see the point in wasting pixels to give it its own well – RISC OS has always been good at not wasting pixels)
• Two lines of filename are good
• Right justified leafname is good

Other possibilities:

• Shorter labels of “files” and “bytes” might allow the numbers to go on a single line
• The progress bar could be implemented as a full height background to the filename well, in a pale colour

Yes, consensus seems tricky! I like the most recent revision which Steve wasn’t so keen on; the previous version is good too. I’d be happy with either, they’re both a big improvement on the current design.

My happiest moment (if one can have such a thing) in the FilerAction development was when the numbers got a comma to divide up the thousands – you know, so you can actually read them… I find that last layout just a bit too cluttered with all that slabbing going on. That’s why the penultimate version gets my vote.

I reckon the last one is closer to how I’d like it, but a few things could do with changing:

• Why all the blank space on the left? Couldn’t you use that to extend the number fields?
• “Counting files – Paused counting” is a complete waste of space (no wonder the window had to be made so wide!). Just “Counting files (Paused)” or “Counting files (Finished)” will do nicely, with plain old “Counting files” when in progress.
• Could the leafname and pathname be separated into their own lines again, both right-aligned? It’d make long leafnames easier.
• “Locked files not deleted” belongs in the error area, not the title bar.

Now, compare the response on this thread with that on the “Kernel tweaks” thread. There’s a case of bike shed syndrome if ever I saw one!

the numbers got a comma to divide up the thousands

My school maths teacher in the ’80s was completely on the ball when he advised use of a space¹. I’ve adopted this for more than 20 years, but have observed that no one else seems to give a toss!²

¹ "the space is recommended in the SI/ISO 31-0 standard"

² Rik, that’s not meant as a personal criticism – you just chose a complicated feature to enhance!

My school maths teacher in the ’80s was completely on the ball when he advised use of a space. I’ve adopted this for more than 20 years, but have observed that no one else seems to give a toss!

Trevor, I’m with you. I adopted the space as separator when I write numbers… oh, many years ago, too many to remember.

A few thoughts:

• This is a really great improvement. Thanks go to Rik. FWIW, I like the penultimate iteration, too. (This one)
• Shouldn’t the Territory module be used to decide what separator is used for large numbers?
• It’s beyond the scope of this thread, probably, but I’d like to see much more intelligent file copying implemented that can, for example, temporarily ignore all errors (I hate being nobbled by a ‘This file is already open’ when trying to copy things) and then just list up the files that didn’t copy at the end of the operation. It’s a nightmare trying to figure out where a failed copy of a large directory structure got to if it failed half-way through for some unforeseen reason.

Keep up the good work!

I like both the last two. So whichever is truer to the style guide.

(And if that turns out not to be best, then shouldn’t the style guide be fixed?)

Steve: in many countries the use of a . instead of a , is used for denoting thousands.
So 10.000.000,00 is how we write 10 million in most European countries instead of 10,000,000.00
Being a programmer i got used to trading the , for a . as a decimal point.
Is there a place to configure how this is formatted?

I too prefer the penultimate one (although with the bar in blue, of course!!).

I assume that the Territory module is used to format the numbers, so they come out with the correct seperator for your configured territory.

Thanks for your work on this Rik, it’s not easy trying to keep everyone happy with the various redesigns!