Background Jobs

[jacky]

Yeah, let's talk semantics!

So, with my work flow I'll admit that background file operations isn't something I normally use, but every once in a while it actually comes in handy, as it did this weekend, so I was happy to use it (queued background jobs), and as a result I have a few remarks :

- It seems that we don't always get a statusbar feedback, and I believe we should. I honestly couldn't tell you when I missed one, so there you go for being helpful, but I have a feeling that we don't get one if the queue is empty (or more accurately, there's no currently running operation). I guess it's because you feel it will be started right away, but there can be a little delay, and for consistency sake I believe it should be added still.

- About that feedback, "copy operation #7 queued" Right, that's nice. Hey, at least we know whether it's a copy or a move... Before going further into this, allow me to talk about the Background Jobs window as well, which is slightly better with "Copy 1 item to D:\Folder"
Okay, so that's better, but when you have half a dozen jobs in the list, all copy operation, all 1 item, and all to the same destination, go figure out which is which!

Seriously, if it's one item you should put its name. And if there's more than one, we should have a way to list them all. I'm thinking the context-menu of those items could have a new item "Details..." which would give us the full listing. It would really be helpful.

- Also, I know you have things like pause/resume/re-order the queue on your list for v2, but I think there's one thing you should already add today, and that is the ability to remove a pending job. Because it's rather easy to do (I would assume -- Granted, I can be totally wrong... although I'm usually not ) and because it can be quite useful.
Imagine you add a few jobs, and then hit Paste on the wrong folder. Oh yay, now you have to keep an eye on that Background Jobs window, to make sure to catch it when that wrong job is started so you can hit "Cancel" !

- I also noticed that if the job fails completely, XY just report it as "Canceled" (btw it seems that there's only one 'L' in the American spelling, and that's all that should be said about that, ever).

By "completely failed" I mean, I had this issue of a job down the queue I wanted to remove, (but couldn't ) so I just renamed the source file. And that was reported as "Canceled" which isn't really true, although I guess it might be better than "Completed". Had me wondering, though, if maybe XY should check for existence of the source item(s) before starting it, one could even consider the file list (under Details) to have a little icon (added upon starting) indicating whether or not the source existed then (and the item(s) was/were indeed included in the started operation?
If this indicator is well-marked as being from the source/before the operation is started, it shouldn't be confused as an indication as to whether or not the operation itself was successful for that item.

- I wouldn't be against a little something upon full (queue) completion. I'm sure this will be a CEA event, where one can have a script triggered and chose whether to have a sound, a popup, anything... but until then, a little beep or something might be good. I see there's a new "Background Bar", maybe it could "flash" or something.
EDIT: I also see you're suggesting a sound for this event, so yeah.

- I'd like a "Clear" button, to remove all done (completed+canceled) jobs. Maybe it could also have a context-menu to remove only all completed ones, or only all canceled ones.

- I think that's it; Your turn.

[nas8e9]

- It seems that we don't always get a statusbar feedback, and I believe we should. I honestly couldn't tell you when I missed one, so there you go for being helpful, but I have a feeling that we don't get one if the queue is empty (or more accurately, there's no currently running operation). I guess it's because you feel it will be started right away, but there can be a little delay, and for consistency sake I believe it should be added still.

Is this still the case with the Background Bar enabled in 9.00.0204?

- About that feedback, "copy operation #7 queued" Right, that's nice. Hey, at least we know whether it's a copy or a move... Before going further into this, allow me to talk about the Background Jobs window as well, which is slightly better with "Copy 1 item to D:\Folder"
Okay, so that's better, but when you have half a dozen jobs in the list, all copy operation, all 1 item, and all to the same destination, go figure out which is which!

Seriously, if it's one item you should put its name. And if there's more than one, we should have a way to list them all. I'm thinking the context-menu of those items could have a new item "Details..." which would give us the full listing. It would really be helpful.

+1. I'm not sure how easy/fast listing the files/folders to be acted on, would be if you had selected a top folder with (deeply) nested folders and/or lots of files.

- I wouldn't be against a little something upon full (queue) completion. I'm sure this will be a CEA event, where one can have a script triggered and chose whether to have a sound, a popup, anything... but until then, a little beep or something might be good. I see there's a new "Background Bar", maybe it could "flash" or something.
EDIT: I also see you're suggesting a sound for this event, so yeah.

Please see this thread.

- Also, I know you have things like pause/resume/re-order the queue on your list for v2, but I think there's one thing you should already add today, and that is the ability to remove a pending job. Because it's rather easy to do (I would assume -- Granted, I can be totally wrong... although I'm usually not ) and because it can be quite useful.
Imagine you add a few jobs, and then hit Paste on the wrong folder. Oh yay, now you have to keep an eye on that Background Jobs window, to make sure to catch it when that wrong job is started so you can hit "Cancel" !

- I also noticed that if the job fails completely, XY just report it as "Canceled" (btw it seems that there's only one 'L' in the American spelling, and that's all that should be said about that, ever).

By "completely failed" I mean, I had this issue of a job down the queue I wanted to remove, (but couldn't ) so I just renamed the source file. And that was reported as "Canceled" which isn't really true, although I guess it might be better than "Completed". Had me wondering, though, if maybe XY should check for existence of the source item(s) before starting it, one could even consider the file list (under Details) to have a little icon (added upon starting) indicating whether or not the source existed then (and the item(s) was/were indeed included in the started operation?
If this indicator is well-marked as being from the source/before the operation is started, it shouldn't be confused as an indication as to whether or not the operation itself was successful for that item.

- I'd like a "Clear" button, to remove all done (completed+canceled) jobs. Maybe it could also have a context-menu to remove only all completed ones, or only all canceled ones.

+1

[admin]

Inline comments >>>

Yeah, let's talk semantics!

So, with my work flow I'll admit that background file operations isn't something I normally use, but every once in a while it actually comes in handy, as it did this weekend, so I was happy to use it (queued background jobs), and as a result I have a few remarks :

- It seems that we don't always get a statusbar feedback, and I believe we should. I honestly couldn't tell you when I missed one, so there you go for being helpful, but I have a feeling that we don't get one if the queue is empty (or more accurately, there's no currently running operation). I guess it's because you feel it will be started right away, but there can be a little delay, and for consistency sake I believe it should be added still.
>>> Cannot repro. This is history, or?

- About that feedback, "copy operation #7 queued" Right, that's nice. Hey, at least we know whether it's a copy or a move... Before going further into this, allow me to talk about the Background Jobs window as well, which is slightly better with "Copy 1 item to D:\Folder"
>>> The stress of this status message is on "queued". It kind of explains to you why the file you just moved is still not going away: because the actual move will happen later.

Okay, so that's better, but when you have half a dozen jobs in the list, all copy operation, all 1 item, and all to the same destination, go figure out which is which!
>>> agreed

Seriously, if it's one item you should put its name. And if there's more than one, we should have a way to list them all. I'm thinking the context-menu of those items could have a new item "Details..." which would give us the full listing. It would really be helpful.
>>> I check. I did not bother partly for memory reasons (I remove the lists once a job is spawned to XYcopy, so there are currently available only for pending jobs). But ok, selecting 5000 files to copy them somewhere (as opposed to selecting their parent folder) is rather rare and usually the memory costs are little. So, yes, that "Details..." item is a good idea.

- Also, I know you have things like pause/resume/re-order the queue on your list for v2, but I think there's one thing you should already add today, and that is the ability to remove a pending job. Because it's rather easy to do (I would assume -- Granted, I can be totally wrong... although I'm usually not ) and because it can be quite useful.
Imagine you add a few jobs, and then hit Paste on the wrong folder. Oh yay, now you have to keep an eye on that Background Jobs window, to make sure to catch it when that wrong job is started so you can hit "Cancel" !
>>> agreed, and indeed it should be not that difficult. the hardest part is the interface, because I would prefer to have a checkbox or so on each pending item where you can "disable" it (and maybe later re-enable it). I'm still thinking about the best way to design this innterface...

- I also noticed that if the job fails completely, XY just report it as "Canceled" (btw it seems that there's only one 'L' in the American spelling, and that's all that should be said about that, ever).
>>> I went for "Cancelled" everywhere AFAIK. I researched that once and decided that way. Maybe I should use also "Colour Filter" in future. I like BE...

By "completely failed" I mean, I had this issue of a job down the queue I wanted to remove, (but couldn't ) so I just renamed the source file. And that was reported as "Canceled" which isn't really true, although I guess it might be better than "Completed".
>>> the shell file op API is very bad in returning why something did not happen. I'm down to guessing. "Canceled" is the best I can do here.

Had me wondering, though, if maybe XY should check for existence of the source item(s) before starting it, one could even consider the file list (under Details) to have a little icon (added upon starting) indicating whether or not the source existed then (and the item(s) was/were indeed included in the started operation?
If this indicator is well-marked as being from the source/before the operation is started, it shouldn't be confused as an indication as to whether or not the operation itself was successful for that item.
>>>?? with "file list" you mean the BJ list? XY could check for existence. but what if only part of the sources exist? continue with that part or cancel the whole job... decisions...

- I wouldn't be against a little something upon full (queue) completion. I'm sure this will be a CEA event, where one can have a script triggered and chose whether to have a sound, a popup, anything... but until then, a little beep or something might be good. I see there's a new "Background Bar", maybe it could "flash" or something.
EDIT: I also see you're suggesting a sound for this event, so yeah.

- I'd like a "Clear" button, to remove all done (completed+canceled) jobs. Maybe it could also have a context-menu to remove only all completed ones, or only all canceled ones.
>>>Done (ain't it?).

- I think that's it; Your turn.

[admin]

- About that feedback, "copy operation #7 queued" Right, that's nice. Hey, at least we know whether it's a copy or a move... Before going further into this, allow me to talk about the Background Jobs window as well, which is slightly better with "Copy 1 item to D:\Folder"
Okay, so that's better, but when you have half a dozen jobs in the list, all copy operation, all 1 item, and all to the same destination, go figure out which is which!

Seriously, if it's one item you should put its name. And if there's more than one, we should have a way to list them all. I'm thinking the context-menu of those items could have a new item "Details..." which would give us the full listing. It would really be helpful.

+1. I'm not sure how easy/fast listing the files/folders to be acted on, would be if you had selected a top folder with (deeply) nested folders and/or lots of files.

I will only list the selected items (not any contents of selected folders) so there is no big work usually.

[jacky]

I see you've already made some changes, very nice, melike

- It seems that we don't always get a statusbar feedback, and I believe we should. I honestly couldn't tell you when I missed one, so there you go for being helpful, but I have a feeling that we don't get one if the queue is empty (or more accurately, there's no currently running operation). I guess it's because you feel it will be started right away, but there can be a little delay, and for consistency sake I believe it should be added still.
>>> Cannot repro. This is history, or?

I don't think so. One way to easily see it is, again, when adding a new op while the queue is empty (no running/pending jobs). E.g. do a copy/paste or just hit Ctrl+D and there's no feedback on the statusbar.
Actually, it looks like if we pause processing, then we can still the queue up and there's never any feedback...

- About that feedback, "copy operation #7 queued" Right, that's nice. Hey, at least we know whether it's a copy or a move... Before going further into this, allow me to talk about the Background Jobs window as well, which is slightly better with "Copy 1 item to D:\Folder"
>>> The stress of this status message is on "queued". It kind of explains to you why the file you just moved is still not going away: because the actual move will happen later.

I know, I got that. I just thought that "Copying of 2 items queued as job #7" or something might be a little more informative. But it's not a big deal, it was on the BJ window itself, and that's fixed.

>>> I check. I did not bother partly for memory reasons (I remove the lists once a job is spawned to XYcopy, so there are currently available only for pending jobs). But ok, selecting 5000 files to copy them somewhere (as opposed to selecting their parent folder) is rather rare and usually the memory costs are little. So, yes, that "Details..." item is a good idea.

I like it! Thanks. Couple of things though:
- I'd like for XY to remember the size of that window, like it usually does with other windows (or the BJ one it seems).
- Why is there both Ok & Cancel ? What are we ok'ing/canceling here? Nothing, right? So just one button Ok (or better, Close) would be enough/better IMO
- Also, sometimes the operation does include a rename (e.g. Ctrl+D and such, Copy/Move (Here) As, etc) and I'd like to see said "new name" on that Details window as well.

>>>?? with "file list" you mean the BJ list? XY could check for existence. but what if only part of the sources exist? continue with that part or cancel the whole job... decisions...

Yes, I meant the list from Details, list of items for that job. And if there's only part of the source, I don't know, maybe a popup asking for confirmation could not be a terrible idea? I'm not really sure...

- I'd like a "Clear" button, to remove all done (completed+canceled) jobs. Maybe it could also have a context-menu to remove only all completed ones, or only all canceled ones.
>>>Done (ain't it?).

Yep, although I'd like it that if I check that thing (Hide Completed), it stays checked the next time I open the BJ window again. (I know that it means the IDs/numbers on the list don't match anymore the statusbar feedback, but that's true whenever that's checked so if that's the reason for not remembering it, I don't think it makes that much sense/is strong enough.)

Lastly, why do the background bar and the TB button not have/share the same context menu? I could see pausing a nice fit for TB ctxt menu as well, or configure for the background bar. And certainly, for consistency sake, it wouldn't hurt that all items are ordered the same in both menus, too.

[admin]

Yes, right.

All ok and good, apart from this (make a note for xycopy 2.0):
- Also, sometimes the operation does include a rename (e.g. Ctrl+D and such, Copy/Move (Here) As, etc) and I'd like to see said "new name" on that Details window as well.

[admin]

Hijacking the thread for a little question:

Currently when "Pause processing" is ON then also parallel (non-queued) jobs are not immediately processed but kept pending, and on unpausing they are effectively treated identically to queued jobs. I wonder if this is good... so:

Should parallel jobs better be always (also on Pause) immediately processed? IOW, should "Pause processing" be renamed to "Pause processing queue"?

[nas8e9]

Hijacking the thread for a little question:

Currently when "Pause processing" is ON then also parallel (non-queued) jobs are not immediately processed but kept pending, and on unpausing they are effectively treated identically to queued jobs. I wonder if this is good... so:

Should parallel jobs better be always (also on Pause) immediately processed? IOW, should "Pause processing" be renamed to "Pause processing queue"?

I can personally see one use for Pause processing, and that is to stop *all* current file operations (to free the HD's bandwidth for something else). I'd keep it as it is.

Also, I see a Cancel menu item in the context menu for jobs in the Background Jobs window. It doesn't seem to cancel a running job and is enabled for both running as well as completed jobs?

[admin]

Hijacking the thread for a little question:

Currently when "Pause processing" is ON then also parallel (non-queued) jobs are not immediately processed but kept pending, and on unpausing they are effectively treated identically to queued jobs. I wonder if this is good... so:

Should parallel jobs better be always (also on Pause) immediately processed? IOW, should "Pause processing" be renamed to "Pause processing queue"?

I can personally see one use for Pause processing, and that is to stop *all* current file operations (to free the HD's bandwidth for something else). I'd keep it as it is.

Also, I see a Cancel menu item in the context menu for jobs in the Background Jobs window. It doesn't seem to cancel a running job and is enabled for both running as well as completed jobs?

1.
Note that there is only one point in time where the "Queue file operations" setting is evaluated: when the job is initiated by the user:
"Queue file operations" OFF: start the job immediately in the background.
"Queue file operations" ON: start the job only after any previously started background job is completed.

Pause does not affect any jobs in progress.

This means -- as it is coded currently -- if Pause is ON, the whole point of having "Queue file operations" OFF is obsolete: all new file operations are queued. Changing Pause to affect only queued operations would keep the difference between "Queue file operations" OFF/ON meaningful.

2.
The Cancel just closes the menu. Is this really ambiguous? Most menus have a Cancel has last item...

[nas8e9]

1.
Note that there is only one point in time where the "Queue file operations" setting is evaluated: when the job is initiated by the user:
"Queue file operations" OFF: start the job immediately in the background.
"Queue file operations" ON: start the job only after any previously started background job is completed.

Pause does not affect any jobs in progress.

This means -- as it is coded currently -- if Pause is ON, the whole point of having "Queue file operations" OFF is obsolete: all new file operations are queued. Changing Pause to affect only queued operations would keep the difference between "Queue file operations" OFF/ON meaningful.

I didn't read 9.00.0206's change log closely enough . I'm still struggling slightly with why a user would want to pause all pending jobs of the queue while already running queued jobs continue. Having said that, it would seem more consistent to only pause the queued items with the corresponding change in name to Pause processing queue.

2.
The Cancel just closes the menu. Is this really ambiguous? Most menus have a Cancel has last item...

I take it you mean in context menus? Looking at a few applications (Firefox, EmEditor, Word) none have a Cancel menu item in their context menu nor does XYplorer's context menu in the file list, itself. It doesn't seem necessary as mouse users can simply click outside the menu to dismiss it whereas keyboard users can just press Esc.

Regardless of the above, seeing Cancel in *this* context menu does seem ambiguous to me: the ability to cancel a background job (either running or pending) seems a reasonable expectation (even though the functionality isn't there yet). In short, I must be missing something.

[zer0]

On the GUI side, it would be much better (if possible) to have a command button whose caption would change between "Pause" and "Continue". When it comes to progress dialogues -- if pausing is allowed -- such a button is de facto standard.

[admin]

On the GUI side, it would be much better (if possible) to have a command button whose caption would change between "Pause" and "Continue". When it comes to progress dialogues -- if pausing is allowed -- such a button is de facto standard.

Agreed.

[admin]

1.
Note that there is only one point in time where the "Queue file operations" setting is evaluated: when the job is initiated by the user:
"Queue file operations" OFF: start the job immediately in the background.
"Queue file operations" ON: start the job only after any previously started background job is completed.

Pause does not affect any jobs in progress.

This means -- as it is coded currently -- if Pause is ON, the whole point of having "Queue file operations" OFF is obsolete: all new file operations are queued. Changing Pause to affect only queued operations would keep the difference between "Queue file operations" OFF/ON meaningful.

I didn't read 9.00.0206's change log closely enough . I'm still struggling slightly with why a user would want to pause all pending jobs of the queue while already running queued jobs continue. Having said that, it would seem more consistent to only pause the queued items with the corresponding change in name to Pause processing queue.

2.
The Cancel just closes the menu. Is this really ambiguous? Most menus have a Cancel has last item...

I take it you mean in context menus? Looking at a few applications (Firefox, EmEditor, Word) none have a Cancel menu item in their context menu nor does XYplorer's context menu in the file list, itself. It doesn't seem necessary as mouse users can simply click outside the menu to dismiss it whereas keyboard users can just press Esc.

Regardless of the above, seeing Cancel in *this* context menu does seem ambiguous to me: the ability to cancel a background job (either running or pending) seems a reasonable expectation (even though the functionality isn't there yet). In short, I must be missing something.

1.
I see various reasons why a user would pause a queue. One of them mentioned by jacky lately: if you made a mistake, or you are unsure whether you made a mistake, you halt things a have all the time look, and if necessary skip jobs.
Another usage is to set pause right from the beginning and then add jobs to the paused queue. When your queue is to your liking, you unpause and go for a cup of coffee while the machine is working.
If parallel jobs are excluded from the pause (which I will code in the next 5 minutes) you can still start a quick background job (with "queue file ops" OFF) while your paused queue is not affected. Nice.

BTW, pausing jobs in progress will only be possible in XYcopy 2.0.

2.
Agreed about Cancel. I'll remove it.

[admin]

On the GUI side, it would be much better (if possible) to have a command button whose caption would change between "Pause" and "Continue". When it comes to progress dialogues -- if pausing is allowed -- such a button is de facto standard.

Agreed.

Another question is the caption. A button (or checkbox) "Pause" is slightly misleading because the user might imply it also pauses any jobs in progress. But something like "Pause pending" is strange because how can you pause something that has not even started. In short, I need a new word for "Pause". What about "Freeze"??? (Or, to be maximally clear, "Freeze Pending Jobs"/"Continue Pending Jobs").

[Stefan]

"Delay Pending Jobs"/"Continue delayed Jobs"

?