File/folder coloring for Background Jobs

[Mesh]

I don't know if anyone has suggested this already for queued jobs... When queueing files/folders for transfer, color them differently until the job is completed. That way, it's easy to see what's in the process of being dealt with, and it also serves as visual feedback that XY really did acknowledge your action, without requiring that you take your eyes off what you're working on to look at the Status Bar.

Obviously, this should be incorporated into XY's Configuration, so people can customize the foreground/background colors. But I think this would be a very nice addition to XY.


What does everyone else think?

[nas8e9]

I don't know if anyone has suggested this already for queued jobs... When queueing files/folders for transfer, color them differently until the job is completed. That way, it's easy to see what's in the process of being dealt with, and it also serves as visual feedback that XY really did acknowledge your action, without requiring that you take your eyes off what you're working on to look at the Status Bar.

Obviously, this should be incorporated into XY's Configuration, so people can customize the foreground/background colors. But I think this would be a very nice addition to XY.


What does everyone else think?

+1, with the caveat that when selecting one or more top folders with a lot of folders and/or files underneath, things could get a bit hairy performance-wise?

[jacky]

+1, with the caveat that when selecting one or more top folders with a lot of folders and/or files underneath, things could get a bit hairy performance-wise?

I don't think it would be a good idea, for reasons like that, or the fact that one same item could be in more than one job which could lead to complications, or the fact that one (queued) job could be later marked as Skipped, and then what happens to the color, etc

Besides, in standard/non-background case you can have files that are e.g. going to be copied, and you don't get any visual feedback on List, it's not really usual/expected behavior. And as you mention, we have visual feedback right there on Statusbar, later on with CEA I'm sure one will be able to add a sound, maybe after that a discrete self-destructing message...

[Mesh]

I don't think it would be a good idea, for reasons like that, or the fact that one same item could be in more than one job which could lead to complications, or the fact that one (queued) job could be later marked as Skipped, and then what happens to the color, etc

That's not a reason to reject it, it's a reason to think it through and plan for those contingencies. Personally, I don't think it has to be a performance issue - I think it can be coded very efficiently.

Besides, in standard/non-background case you can have files that are e.g. going to be copied, and you don't get any visual feedback on List, it's not really usual/expected behavior. And as you mention, we have visual feedback right there on Statusbar, later on with CEA I'm sure one will be able to add a sound, maybe after that a discrete self-destructing message...

When you drag for a file op normally, you absolutely have visual feedback. If you're moving, the source object dissappears. If you're copying, you get a system window for the copy procedure. In both cases, you receive immediate visual feedback that the operation has occurred.

On the other hand, when you're adding an operation to the queue, there is no such visual feedback. Yes, something shows up on the status bar, but that's out of the way insofar as the field of view.

I think this would be an unobtrusive way to add that visual feedback in a painless manner.

[Demset]

I really like this idea. I'm always doubting whether or not something really did get added to the queue. Even the status bar notification just says that something was added, but it doesn't give details. Coloring the files/folders in the queue would keep me from wondering if I clicked/dragged the wrong item(s).

Count me in for this one!

[PeterH]

Thinking of problems with coloring I just had other ideas...

First was to add a small field with a kind of "background status indicator".
And when thinking about it's placement, maybe next to the icon, there was the idea of an "icon overlay".

Both would not interfere with other coloring, first would not interfere with anything else, I think.

And yes: I also think it would be useful to have some indicator showing if some work is queued for any element. To see that some work is "accepted", as well as to be warned accessing an element with queued work.
(And possibly XY could automatically warn me when acting on an element with queued work?)

[Mesh]

Thinking of problems with coloring I just had other ideas...

First was to add a small field with a kind of "background status indicator".
And when thinking about it's placement, maybe next to the icon, there was the idea of an "icon overlay".

Both would not interfere with other coloring, first would not interfere with anything else, I think.

I'm not sure I'm fond of an icon overlay, or field. I think coloring the text would be sufficient, and wouldn't take up any room the way an extra field would, nor would it obscure the file icon the way an overlay would.

And yes: I also think it would be useful to have some indicator showing if some work is queued for any element. To see that some work is "accepted", as well as to be warned accessing an element with queued work.
(And possibly XY could automatically warn me when acting on an element with queued work?)

Now, the warning idea, I like! Although, it should be limited to destructive acts. Setting up a copy operation when it's already queued for an existing copy operation doesn't need a warning, for example.

But a rename, delete, or same volume move would, since they would ordinarily take precedence over a background job.

[admin]

Makes sense, but... later.

[Mesh]

Makes sense, but... later.

Okay. Thanks, Don!