Auto-refresh only works if you press enter key

[zer0]

I never responded to this, but I still view my four cases as ideal.

I see WE's behavior as dangerous because it can easily lead to the file being renamed when some other program steals focus, and following this with a resort means the user:

1. Can't be sure of the new name, since they weren't done editing.
2. Doesn't know where the item is now in the list.

That's a big potential external factor to take into account, if I'm being honest. Do you think that "Keep item in view after resorting" is an unsuitable option to mitigate that big IF? In an unlikely event that the selection is lost as well, we have "Restore Selection" available to use through white list context menu.

Otherwise the options are:

1. Leave the item in rename mode.
2. Rename the item. This may lead to annoying dialogs (invalid/conflicting name) or apply an undesired name.
3. Rename the item and then sort the list based on the new name. Same as above but also adds the possible inconvenience of making it difficult to find the item.
4. Cancel the Rename, requires the user to start over.

I feel 1 is the only good option, but unfortunately when Don added Unicode he apparently lost the ability to do this when XY is inactive.

Of the remaining three I find 4 to be the least evil because:

1. It's the only one that returns the user to a known state.
2. It is less likely that canceling the rename will trigger action by other programs. If the item is in a synced folder, the rename that comes from options 2 or 3 will be propagated to the other locations/cloud, and if the result is not desired this wastes even more time, resources, and possibly causes other problem.

I think that cancelling a rename due to loss of focus IS evil because you're assuming that loss of focus was accidental/stolen. In an event when focus is lost/stolen undesirably, I always use undo to roll back. I do believe that a combination of keeping focused item in view on resort, being able to restore the selection and undo an accidental rename provides enough of a safety net.

UPDATE:

Going forward the userbase will shift towards W7, so what calls for an exception on this occasion?

But for now, XP still has is the dominant OS in Windows...just saw an article on Net yesterday (can't recall where) that it still has 60% or so of installed base where W7 is only at 17% or so...so in some of these cases, we might need a generic XP/W7 type switch so that it could better match the stds of that OS style.

In the past, Don used a tweak to retain legacy functionality for those so inclined. I'm not opposed to doing the same on this occasion.

[TheQwerty]

Allow me to mix up the order of my responses just a bit, because I feel you missed a very important point:

I think that cancelling a rename due to loss of focus IS evil because you're assuming that loss of focus was accidental/stolen.

... if Don can reliably determine desired loss of focus via user interaction vs. it being stolen or accidental then I can support [renaming]

Otherwise the options are...

So again, if Don can determine that the user has focused a different application, then I view that as consent to rename and resort, and you have my support. However, if Don cannot make that determination, then I believe it must be assumed that XY's focus was stolen and thus the new name should not be committed.

Do you think that "Keep item in view after resorting" is an unsuitable option to mitigate that big IF? In an unlikely event that the selection is lost as well, we have "Restore Selection" available to use through white list context menu.

These are options that do help in making it less of an inconvenience but I still have a fundamental problem with XY assuming my consent when it cannot determine why focus was lost. Why should XY assume that it's capable of correctly divining my intentions in this case?

In an event when focus is lost/stolen undesirably, I always use undo to roll back. I do believe that a combination of keeping focused item in view on resort, being able to restore the selection and undo an accidental rename provides enough of a safety net.

A bit pedantic but, a safety net catches something before it becomes a problem. Undo and restore provide for a do-over, and aid in getting the user back to a known state, but they offer no protection to the user.

Would you not use a condom because abortion "provides enough of a safety net?"

[j_c_hallgren]

In the past, Don used a tweak to retain legacy functionality for those so inclined. I'm not opposed to doing the same on this occasion.

And that's why I was suggesting a more generic OS switch so that we don't get too many of them...being able to customize individual features is always better but if needed, I could see a more common OS style approach.

[zer0]

Allow me to mix up the order of my responses just a bit, because I feel you missed a very important point:

I think that cancelling a rename due to loss of focus IS evil because you're assuming that loss of focus was accidental/stolen.

... if Don can reliably determine desired loss of focus via user interaction vs. it being stolen or accidental then I can support [renaming]

Otherwise the options are...

So again, if Don can determine that the user has focused a different application, then I view that as consent to rename and resort, and you have my support. However, if Don cannot make that determination, then I believe it must be assumed that XY's focus was stolen and thus the new name should not be committed.

Do you think that "Keep item in view after resorting" is an unsuitable option to mitigate that big IF? In an unlikely event that the selection is lost as well, we have "Restore Selection" available to use through white list context menu.

These are options that do help in making it less of an inconvenience but I still have a fundamental problem with XY assuming my consent when it cannot determine why focus was lost. Why should XY assume that it's capable of correctly divining my intentions in this case?

IMO, it's equally bad to assume that focus was stolen. Without speaking of hypothetical users, I gather Don doesn't like that, my first-hand experience is that in virtually all situations when focus is lost it is because I explicitly caused it to do so. If something decides to swamp all over my computer while I'm midway through a renaming procedure, it is likely that I have a bigger problem than some badly-named file that a click can roll back.

In an event when focus is lost/stolen undesirably, I always use undo to roll back. I do believe that a combination of keeping focused item in view on resort, being able to restore the selection and undo an accidental rename provides enough of a safety net.

A bit pedantic but, a safety net catches something before it becomes a problem. Undo and restore provide for a do-over, and aid in getting the user back to a known state, but they offer no protection to the user.

One of your reasons for not going ahead with a rename is to have things at a known state, I've addressed that exact point. Some protection is provided if an accidental rename causes a clash, because it usually shows a dialogue with an ability to cancel a rename operation. Only so much safety is reasonable before it starts protecting users from themselves, which I find very patronizing.

Would you not use a condom because abortion "provides enough of a safety net?"

Let's just say that I wouldn't stop having sex without one, because I could only do so with complete trust of the other party. XYplorer should follow suit: trust me, the user, that I know what I am doing. There may be a degree of risk involved, but I'm happy to take that responsibility.

In the past, Don used a tweak to retain legacy functionality for those so inclined. I'm not opposed to doing the same on this occasion.

And that's why I was suggesting a more generic OS switch so that we don't get too many of them...being able to customize individual features is always better but if needed, I could see a more common OS style approach.

I recall Don being able to enable certain defaults on fresh installation based on local OS. Perhaps the same could be applied on this occasion as well.

[TheQwerty]

Well we're going to have to agree to disagree..

I absolutely don't want any program assuming and changing things without my explicit permission, that's the type of behavior that makes it difficult to trust a program. (What other assumptions is it making that changes my data? And how often does it happen without my notice?)

And I don't at all like the precedent this sets that it's okay for XY to use focus loss as user confirmation.
"Are you sure you want to delete? Oh focus lost! Well the user did press delete in the first place, so CONFIRMED!!!"

Acceptable as a tweak, dangerous as a default.

[zer0]

I absolutely don't want any program assuming and changing things without my explicit permission, that's the type of behavior that makes it difficult to trust a program. (What other assumptions is it making that changes my data? And how often does it happen without my notice?)

As long as you are aware of what assumptions are made and have agreed to them [by enabling a setting/tweak], doesn't that constitute explicit permission?

And I don't at all like the precedent this sets that it's okay for XY to use focus loss as user confirmation.
"Are you sure you want to delete? Oh focus lost! Well the user did press delete in the first place, so CONFIRMED!!!"

I am only in favour of it being accepted for inline rename. Thus, your example is an extreme one, even in principle. I'd never advocate pressing buttons on user's behalf, but that particular dialogue can be suppressed through a check box.

Acceptable as a tweak, dangerous as a default.

Not my intention for it to be default behaviour, especially considering that "Resort list immediately on rename" isn't on by default either.