XYplorer Beta Club

jacky wrote:- 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.

jacky wrote:- 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.

jacky wrote:- 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.

jacky wrote:- 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" !

jacky wrote:- 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.

jacky wrote:- 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.

jacky wrote: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.

nas8e9 wrote:

jacky wrote:- 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.

admin wrote:- 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?

admin wrote:- 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.

admin wrote:>>> 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.

admin wrote:>>>?? 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...

admin wrote:- 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?).

admin wrote: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 wrote:

admin wrote: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 wrote: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.

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

zer0 wrote: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.

nas8e9 wrote:

admin wrote: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.

admin wrote: 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.

admin wrote:

zer0 wrote: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.