zer0 wrote:TheQwerty wrote:4) XY lost focus - Nothing. It's not clear that the user chose to exit rename mode, so the name shouldn't be changed. I'm not sure whether a resort should occur if the user was performing a serial rename. I'm leaning towards yes as they've committed the previous names, but it means when they get to return focus to XY it won't be exactly as it was before focus was stolen. (Ideally it would be leave the user in rename mode, but blah blah unicode controls broke that
)
From there a tweak could be introduced for number 4 for any users who wish to throw caution to the wind and use WE's dangerous behavior.
This is an interesting one. First of all, I don't see WE's behaviour is dangerous. It maybe the case that those unfamiliar with it, such as those moving from XP to Vista, may find the behaviour unnatural but I can only foresee that happening if some glitch caused their rename to be committed. If they did in fact commit a rename then I see a resort to be a natural consequence. The way I envision this, if sorted by filename, is that you "take a file out" when you wish to rename, do the renaming and put it back into the list of files. Since the list is already "under the watch" of "sort by filename" then it takes that file and puts it in the right place according to its name. If you prefer, think of it as going to a library, taking a book to read from a shelf, changing the author's name and trying to put the book back in the same place where you took it from. If that was acceptable behaviour then every library would be a mess. Same when it comes to file management, once a rename has been committed it is released back into the file system and if that system is sorted by a certain criteria then this newly-renamed file should obey this criteria immediately.
I assume that it would not be too difficult to distinguish between loosing focus due to a mouse click and a glitch (if XY keeps a record of every mouse-click that is). Therefore, one should not be worried in terms of clarity whether a user chose to exit rename mode or the computer made that choice for him
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:
- Can't be sure of the new name, since they weren't done editing.
- Doesn't know where the item is now in the list.
Now your point is that if the user changes focus from XY to another program it should commit and resort, and if Don can reliably determine desired loss of focus via user interaction vs. it being stolen or accidental then I can support that.
Otherwise the options are:
- Leave the item in rename mode.
- Rename the item. This may lead to annoying dialogs (invalid/conflicting name) or apply an undesired name.
- 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.
- 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:
- It's the only one that returns the user to a known state.
- 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.
So I guess that makes me a fool that's partly for this? If I've successfully followed the conversation.
Mine at least never resorts after rename (XP SP3).
XYplorer Beta Club