XYcopy - AutoQueue

[Mesh]

I thought I would like the AutoQueue feature, but it turns out that it causes more problems for me then not. What would happen is that I would start a long copy job, and then while it was working, I would go and do further file management - only to discover that when I performed an operation, it looked like nothing happened. I realized that my simple operations were being queued after the current long operation, and that was no good.

What I would really like is the ability to selectively add operations to the Queue, but otherwise have autoqueueing off.

The question is, what would be the best way to do this?


If we were only talking about copy/move ops, we could make it a right-drag option. But that doesn't help for delete ops. So, the only thing I can come up with off the top of my head is to either exclude delete ops from autoqueueing altogether, and then make copy/move ops a right-drag option in order to add it to an existing queue, or to add a toolbar button which will act as a state toggle. When turned on, subsequent jobs will be added to an existing queue. When turned off, subsequent jobs are handled immediately.

What do you guys think?

[admin]

I had exactly the same worries and the same ideas:
1) exclude delete from auto-queue.
2) TB button to toggle queuing.

Somebody has something better?

[Mesh]

Well, how often is a delete job long enough to merit queuing in the first place? I'm sure there are some, but realistically, how often do people run across them?

For me, it's usually a non-issue. And if that's the case for everyone else as well, than it's a matter of which method do people prefer insofar as selectively adding ops to the queue. Right drag or toolbar state button?

[nas8e9]

I'd personally like to have AutoQueue always on, with two (generally quick-to-complete) exceptions:
1. deletes;
2. moves within the same partition (MFT-updating instead of file reading-then-writing).

In terms of UI, I'd prefer a toolbar button as on-off switch, with an option or tweak to allow right mouse-button dragging to override the current state.

[Mesh]

I'd personally like to have AutoQueue always on, with two (generally quick-to-complete) exceptions:
1. deletes;
2. moves within the same partition (MFT-updating instead of file reading-then-writing).

In terms of UI, I'd prefer a toolbar button as on-off switch, with an option or tweak to allow right mouse-button dragging to override the current state.

Well, not an on-off switch, but a state toggle for future ops. You wouldn't want toggling the button to affect what is already in progress.

[nas8e9]

Well, not an on-off switch, but a state toggle for future ops. You wouldn't want toggling the button to affect what is already in progress.

You're right, of course. On (needed ) reflection, to have the right-drag override the current state as indicated by the TB button seems (to me) to be a sensible default, i.e. probably more option (or even default) than tweak.

[admin]

The dragdrop context menu is already quite large. I don't really see me adding a queue-variant for each "copy" and "move" command there. Or what is the idea?

I agree with excluding deletes (damn, took me one day to include it! ) and inner-partition moves from queueing.

[Mesh]

The dragdrop context menu is already quite large. I don't really see me adding a queue-variant for each "copy" and "move" command there. Or what is the idea?

I don't think you'd need a variant for different options. The right-drag action itself will either be in the style of a move or copy (indicated by the use/non-use of modifier keys, as well as whether the drag is to the same/different drive). All you'd need is a single item on the right-drag menu, which would be the opposite of whatever the current configuration is set to.

[admin]

The dragdrop context menu is already quite large. I don't really see me adding a queue-variant for each "copy" and "move" command there. Or what is the idea?

I don't think you'd need a variant for different options. The right-drag action itself will either be in the style of a move or copy (indicated by the use/non-use of modifier keys, as well as whether the drag is to the same/different drive). All you'd need is a single item on the right-drag menu, which would be the opposite of whatever the current configuration is set to.

I attach screenshot of the menu. All yellow items are sent to background/queue if background/queue are enabled. ("Backup Here" will follow in XYcopy 2.0) How would you modify this menu?

[Mesh]

I attach screenshot of the menu. All yellow items are sent to background/queue if background/queue are enabled. ("Backup Here" will follow in XYcopy 2.0) How would you modify this menu?

I don't think I realized how much you had here.

That being the case, the toolbar state button would probably be best.


However, if you wanted to put in the ability to do it by right-dragging, I would suggest a checkbox in that menu that would bypass the current state. If you did it this way, the menu would have to stay put, if the box were checked.


But in reality, I think the toolbar state button by itself would be just fine.

[admin]

I attach screenshot of the menu. All yellow items are sent to background/queue if background/queue are enabled. ("Backup Here" will follow in XYcopy 2.0) How would you modify this menu?

I don't think I realized how much you had here.

That being the case, the toolbar state button would probably be best.


However, if you wanted to put in the ability to do it by right-dragging, I would suggest a checkbox in that menu that would bypass the current state. If you did it this way, the menu would have to stay put, if the box were checked.


But in reality, I think the toolbar state button by itself would be just fine.

OK. So this TB button should be a clone of the setting
- Auto-queue pending file operations
right?

[Mesh]

OK. So this TB button should be a clone of the setting
- Auto-queue pending file operations
right?

Not exactly. Well, it depends on how XY processes it currently. It needs to be a live setting.


In other words, a user needs to be able to do this:


1. XY has AutoQueue enabled.

2. Start a large copy job. This gets queued.

3. Click the toolbar button to turn off AutoQueuing.

4. Do multiple copy/move/delete jobs, and have them run immediately (i.e. NOT queued) while the large job is still running in the background.

5. Click the toolbar button to turn on AutoQueing. (The first large job is still running)

6. Add another large file op to the queue. The first large job is still running, and this one is added to run after it.

7. Click the toolbar button to turn off AutoQueing, and do further file management while the two large jobs complete in the background.


I don't know if XY will process the current setting live, without interrupting existing processses, but in a nutshell, the example above is how it needs to be able to work.

[admin]

OK. So this TB button should be a clone of the setting
- Auto-queue pending file operations
right?

Not exactly. Well, it depends on how XY processes it currently. It needs to be a live setting.


In other words, a user needs to be able to do this:


1. XY has AutoQueue enabled.

2. Start a large copy job. This gets queued.

3. Click the toolbar button to turn off AutoQueuing.

4. Do multiple copy/move/delete jobs, and have them run immediately (i.e. NOT queued) while the large job is still running in the background.

5. Click the toolbar button to turn on AutoQueing. (The first large job is still running)

6. Add another large file op to the queue. The first large job is still running, and this one is added to run after it.

7. Click the toolbar button to turn off AutoQueing, and do further file management while the two large jobs complete in the background.


I don't know if XY will process the current setting live, without interrupting existing processses, but in a nutshell, the example above is how it needs to be able to work.

Yep, but this is exactly how the setting works anyway. It controls whether the currently triggered operation (if another one is being processed) is pushed on the queue or executed immediately.

[Mesh]

Yep, but this is exactly how the setting works anyway. It controls whether the currently triggered operation (if another one is being processed) is pushed on the queue or executed immediately.

Ah. Well, in that case, it should be a piece of cake to implement.

[admin]

Yep, but this is exactly how the setting works anyway. It controls whether the currently triggered operation (if another one is being processed) is pushed on the queue or executed immediately.

Ah. Well, in that case, it should be a piece of cake to implement.

Yep, just need a cool idea for the icon...