Delete (or Recycle) dialog not modeless

[admin]

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..

Why? Simply turn off Background Processing (it's turned off by factory default anyway).

[admin]

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?

I personally would not have a big problem with excluding Delete by default and adding a checkbox to Configuration named "Background delete operations as well". Or even make it a tweak. I think only a few users would actually use it. There is very little point in backgrounding delete operations.

[nas8e9]

I personally would not have a big problem with excluding Delete by default and adding a checkbox to Configuration named "Background delete operations as well". Or even make it a tweak. I think only a few users would actually use it. There is very little point in backgrounding delete operations.

You indicated earlier that you were considering a tweak allowing fine-grained control of which operations will be backgrounded. I personally think backgrounding all would be a sensible default, with the tweak allowing excluding specific types. Combined with the Settings command being able to include/exclude on the fly from a script and the address bar, I'd call it fully configurable. Apart from UI bloat, the frequency with which users will change these settings indeed seems too low to include it in Configuration.

[TheQwerty]

Why? Simply turn off Background Processing (it's turned off by factory default anyway).

That's what I've done.

The issue isn't just delete tasks... All scripts which relied on the blocking nature of any file op in previous versions are broken with background processing enabled.

Don't worry about it, I've disabled background processing and now have to find the time to update my scripts. Sorry for over-reacting! Not the type of thing you want to stumble over on a Monday morning before fully caffeinated.

But I think we still need a Setting(BackgroundFileOps, 0) command.

[admin]

I personally would not have a big problem with excluding Delete by default and adding a checkbox to Configuration named "Background delete operations as well". Or even make it a tweak. I think only a few users would actually use it. There is very little point in backgrounding delete operations.

You indicated earlier that you were considering a tweak allowing fine-grained control of which operations will be backgrounded. I personally think backgrounding all would be a sensible default, with the tweak allowing excluding specific types. Combined with the Settings command being able to include/exclude on the fly from a script and the address bar, I'd call it fully configurable. Apart from UI bloat, the frequency with which users will change these settings indeed seems too low to include it in Configuration.

Yes, such a tweak will do nicely.

I'm just not sure about the best factory default. I don't really think many people would expect (or want) Delete to be backgrounded.

[nas8e9]

I'm just not sure about the best factory default. I don't really think many people would expect (or want) Delete to be backgrounded.

In terms of backgrounding and queuing giving consistency problems (also known as users *trying* to do too many things at once ), out-of-order deletes have the highest likelihood to cause problems. Safety-wise, perhaps excluding deletes by default (with the possibility via a tweak to enable it) may be the best way forward.

[admin]

I'm just not sure about the best factory default. I don't really think many people would expect (or want) Delete to be backgrounded.

In terms of backgrounding and queuing giving consistency problems (also known as users *trying* to do too many things at once ), out-of-order deletes have the highest likelihood to cause problems. Safety-wise, perhaps excluding deletes by default (with the possibility via a tweak to enable it) may be the best way forward.

So this will be a binary flag tweak, an OR-ing of the following values:
1 [x] Backup (has yet to be coded, of course)
2 [x] Copy
4 [x] Cross-volume move
8 [x] Intra-volume move (always parallel!)
16 [ ] Delete (always parallel!)

The default will be (1+2+4+8):

Code: Select all

BackgroundOps=15

[nas8e9]

So this will be a binary flag tweak, an OR-ing of the following values:
1 [x] Backup (has yet to be coded, of course)
2 [x] Copy
4 [x] Cross-volume move
8 [x] Intra-volume move (always parallel!)
16 [ ] Delete (always parallel!)

The default will be (1+2+4+8):

Code: Select all

BackgroundOps=15

Sounds good!

In terms of backgrounding and queuing giving consistency problems (also known as users *trying* to do too many things at once ), out-of-order deletes have the highest likelihood to cause problems. Safety-wise, perhaps excluding deletes by default (with the possibility via a tweak to enable it) may be the best way forward.

Not my best thinking: this is about backgrounding. Regardless of that, deletes will always be handled immediately, out-of-order.