Delete (or Recycle) dialog not modeless

[lukescammell]

Another possibility would be to make it optional:

Background the following operations:
[ ] Copy
[ ] Cross-volume move
[ ] Intra-volume move
[ ] Delete
[ ] Backup

Thanks Don, that'd be great! I'm happy with that That gives me the flexibility and means you can keep your (sensible) defaults.

[zer0]

Another possibility would be to make it optional:

Background the following operations:
[ ] Copy
[ ] Cross-volume move
[ ] Intra-volume move
[ ] Delete
[ ] Backup

Nope, I don't think that is good from a UI perspective -- doesn't XYplorer already have enough tickboxes? As Status Log becomes more powerful, on-the-fly changes to various operations should be possible through its interface. Status Log itself needs to be modeless though!

[nas8e9]

Nope, I don't think that is good from a UI perspective -- doesn't XYplorer already have enough tickboxes?

Do you mean that you don't see the point of allowing backgrounding to be configurable or do you reject it purely on the grounds of UI simplification?

As Status Log becomes more powerful, on-the-fly changes to various operations should be possible through its interface. Status Log itself needs to be modeless though!

In case you haven't already seen it, could you check this thread.

[zer0]

Do you mean that you don't see the point of allowing backgrounding to be configurable or do you reject it purely on the grounds of UI simplification?

Neither. I see benefit in it being configurable, but I think of such configuration being of the "set and forget" type. Thus, said setting is better suited for a CSV tweak than GUI tickboxing.

In case you haven't already seen it, could you check this thread.

I have seen it and I am optimistic about Status Log being live

[admin]

Another possibility would be to make it optional:

Background the following operations:
[ ] Copy
[ ] Cross-volume move
[ ] Intra-volume move
[ ] Delete
[ ] Backup

Nope, I don't think that is good from a UI perspective -- doesn't XYplorer already have enough tickboxes? As Status Log becomes more powerful, on-the-fly changes to various operations should be possible through its interface. Status Log itself needs to be modeless though!

I agree that the UI is crowded enough. I would also think that most users would have it like this (here below), or at least would not mind, so I would make this the factory default...
[x] Copy
[x] Cross-volume move
[x] Intra-volume move (why not!?)
[x] Delete
[x] Backup (has yet to be coded, of course)
... and make this changeable via tweak.

Or are there objections?

[admin]

In case you haven't already seen it, could you check this thread.

I have seen it and I am optimistic about Status Log being live

If it's live then it also will be modeless.

[nas8e9]

I agree that the UI is crowded enough. I would also think that most users would have it like this (here below), or at least would not mind, so I would make this the factory default...
[x] Copy
[x] Cross-volume move
[x] Intra-volume move (why not!?)
[x] Delete
[x] Backup (has yet to be coded, of course)
... and make this changeable via tweak.

Or are there objections?

If I understand it correctly, *all* file operations will be processed in the background which can be overridden via a tweak. Great!

[admin]

I agree that the UI is crowded enough. I would also think that most users would have it like this (here below), or at least would not mind, so I would make this the factory default...
[x] Copy
[x] Cross-volume move
[x] Intra-volume move (why not!?)
[x] Delete
[x] Backup (has yet to be coded, of course)
... and make this changeable via tweak.

Or are there objections?

If I understand it correctly, *all* file operations will be processed in the background which can be overridden via a tweak. Great!

Yes, that's the idea. I should add that 2 of them should rather ignore queueing and always run in parallel:
[x] Copy
[x] Cross-volume move
[x] Intra-volume move (always parallel!)
[x] Delete (always parallel!)
[x] Backup (has yet to be coded, of course)

[nas8e9]

Yes, that's the idea. I should add that 2 of them should rather ignore queueing and always run in parallel:
[x] Copy
[x] Cross-volume move
[x] Intra-volume move (always parallel!)
[x] Delete (always parallel!)
[x] Backup (has yet to be coded, of course)

Perhaps not to zer0's taste, but how about two rows of checkboxes, one to set backgrounding and one to set queueing? (Just kidding! )

[TheQwerty]

Erm.. this has scripting all screwed up, this example (and many of the scripts I have) relies on the sequential order and blocking nature that Delete had.

Code: Select all

::Delete(0,1,"<focitem>");Echo("Stuff after delete...");

It's great if you want to offer the ability to throw these into the background, but this just broke a number of my scripts and the only way for me to fix it is to add another annoying dialog or go through config/toolbar button to disable and re-enable background processing before/after running scripts.

[nas8e9]

Erm.. this has scripting all screwed up, this example (and many of the scripts I have) relies on the sequential order and blocking nature that Delete had.

Code: Select all

::Delete(0,1,"<focitem>");Echo("Stuff after delete...");

It's great if you want to offer the ability to throw these into the background, but this just broke a number of my scripts and the only way for me to fix it is to add another annoying dialog or go through config/toolbar button to disable and re-enable background processing before/after running scripts.

Would Don's planned tweak (globally excluding operation types from background processing) be enough (with the disadvantage that interactive file operations are also excluded) or would an additional parameter for the Delete scripting command to select the old (sequential, blocking, not backgrounded) behaviour be more useful?

[TheQwerty]

Would Don's planned tweak (globally excluding operation types from background processing) be enough (with the disadvantage that interactive file operations are also excluded)

No, certainly not as proposed. This would mean having to restart XY to change the setting just to run a script.

or would an additional parameter for the Delete scripting command to select the old (sequential, blocking, not backgrounded) behaviour be more useful?

Well it's tough. This decision just broke any script that relied on the blocking nature of these commands and provides no decent means aside from those I previously mentioned to get the scripts working correctly again.

I'd handle it by..
1) Add a separate tweak or additional value for the proposed tweak that will make all file ops from scripts get handled in the foreground.
2) Add a new setting for Setting() that can Enable/Disable background processing.

This means everyone with existing scripts that rely on blocking will be able to continue working by setting the tweak for scripts to foreground, and update the scripts as they have the time and then when they are ready change the tweak so it follows the user setting.

[admin]

Would Don's planned tweak (globally excluding operation types from background processing) be enough (with the disadvantage that interactive file operations are also excluded)

No, certainly not as proposed. This would mean having to restart XY to change the setting just to run a script.

or would an additional parameter for the Delete scripting command to select the old (sequential, blocking, not backgrounded) behaviour be more useful?

Well it's tough. This decision just broke any script that relied on the blocking nature of these commands and provides no decent means aside from those I previously mentioned to get the scripts working correctly again.

I'd handle it by..
1) Add a separate tweak or additional value for the proposed tweak that will make all file ops from scripts get handled in the foreground.
2) Add a new setting for Setting() that can Enable/Disable background processing.

This means everyone with existing scripts that rely on blocking will be able to continue working by setting the tweak for scripts to foreground, and update the scripts as they have the time and then when they are ready change the tweak so it follows the user setting.

1) not easy or even impossible
2) yep, will do

[TheQwerty]

1) not easy or even impossible
2) yep, will do

Without 1 this is still a huge pain in the butt that forces everyone to go back in and update all of their scripts ASAP..

[nas8e9]

1) not easy or even impossible
2) yep, will do

Without 1 this is still a huge pain in the butt that forces everyone to go back in and update all of their scripts ASAP..

Pragmatically (and depending on how big/time consuming your *interactive* deletes are), could you manage for now by setting the tweak to exclude delete operations globally?