Click rename behavior when giving focus back to XYplorer window

[elqasar2]

XYplorer handles the focus/rename action differently than File Explorer and I wonder if they could be made the same.

File Explorer:
Select a file in the list. Click on some other window to take focus away from File Explorer. Click on the file again in File Explorer to give focus back to File Explorer. Result: the file is still selected.

XYplorer:
Select a file in the list. Click on some other window to take focus away from XYplorer. Click on the file again in XYplorer to give focus back to XYplorer. Result: the file is now in renaming mode.

Similar problem when you have a file selected in XYplorer, then click on some other window, and then click in the whitespace of the List in XYplorer to give focus back to XYplorer. The selection gets lost. XYplorer is acting on that mouse click as if the focus had never left XYplorer. I think it would be better if XYplorer ate the first mouse click when focus comes back to the XYplorer window. The desired behavior already happens when clicking between panes (i.e. selection doesn't get lost when clicking back in the whitespace of the other pane).

[admin]

I already tried to fix this on 20210709 but failed to find a perfect solution. Now I think an almost-perfect solution is better than nothing. Almost-perfect: Directly after a task bar activation of the app you will need a triple-click to trigger inline rename.

[elqasar2]

Much better

There are 2 other small side effects though.

1) With a file selected, if you activate XYplorer directly from the taskbar, then hit F2 to rename the file, when you click away from it (instead of pressing Enter), it will stay selected. But I can live with that. Actually, that side effect might even be better than what normally happens when clicking away after an inline rename.

2) If XYplorer has focus, then you give focus to a different application, then close that application's window so that focus comes back to XYplorer automatically, the same effects occur as if XYplorer had been activated from the taskbar, i.e. an extra click is required to deselect or rename or whatever.

[admin]

Found a better way. Next beta should have no more side effects.

[elqasar2]

Good job. Clicking now works exactly as expected in 23.60.0001

[Evolve]

When item context menu is open and you Left-Click on white it doesn't deselect the item which is not how it works in File Explorer.
When the windows is out of focus and you click on white it doesn't deselect the item which is again not how it works in File Explorer.

Is this prevention of "renaming on double click" worth it? Refocusing the window back by clicking on some specific pre-selected item is kind of weird.

[admin]

1) Cannot confirm.

2) This is independent of giving focus back to XYplorer window; and to me it's a clear improvement over FE.

[Evolve]

I tend to agree on the second one but the first one (having to click twice on white to deselect the item) is definitely a bug.

[admin]

... which I cannot reproduce.

[Evolve]

23.60.0005.gif (77.69 KiB) Viewed 829 times

23.50.0306.gif (78.38 KiB) Viewed 829 times

[admin]

Sorry, I tested the wrong version. Of course this has to be fixed.

[elqasar2]

The problem now with 23.60.0006 is that if you change your mind about popping the context menu, and click on the filename, it starts an inline rename. I know that's what happens in File Explorer too, but it's not ideal.

So, with 23.60.0006, after popping the context menu, you can either: (a) click in whitespace to remove the selection, or (b) click again on the filename to start an inline rename.

I think that (b) should rather be that you've changed your mind about the context menu, and just want to go back to having the file selected.

An even better illustration of this problem is if you have multiple files selected, pop the context menu for them, change your mind, and then click on any of the files. Desired behavior would be to go back to having the files still selected. What happens in 23.60.0006 is that just the file you clicked on becomes selected.

[Evolve]

You still have at least 3 ways to close the menu but keep everything selected:

1) press Esc - works in many other situations when you change you mind
2) hold Ctrl (or Shift) and clik on white space
3) click on Window Title Bar / Breadcrumb Bar / Tab Bar / Status Bar / ...

[elqasar2]

You still have at least 3 ways to close the menu but keep everything selected:

1) press Esc - works in many other situations when you change you mind
2) hold Ctrl (or Shift) and clik on white space
3) click on Window Title Bar / Breadcrumb Bar / Tab Bar / Status Bar / ...

None of those are more intuitive than what I've suggested, so my point still stands. I don't understand what you're aiming for here. You wanted to be able to deselect a file by clicking in whitespace after right-clicking the file when it wasn't previously selected. You've now got what you want in 23.60.0006. I'm wanting to preserve the selection after right-clicking on one or more files AFTER they were already selected and then trying to click back on the file(s) that were already selected. It's not clear what you're trying to achieve by disputing the points I've raised.

[Evolve]

An even better illustration of this problem is if you have multiple files selected, pop the context menu for them, change your mind, and then click on any of the files. Desired behavior would be to go back to having the files still selected.

You wanted to be able to deselect a file by clicking in whitespace after right-clicking the file when it wasn't previously selected. You've now got what you want in 23.60.0006. I'm wanting to preserve the selection after right-clicking on one or more files AFTER they were already selected and then trying to click back on the file(s) that were already selected.

So clicking on white space should deselect all the selected files but clicking on one of the selected files should NOT deselect all the other files except the one you're clicking on (current behavior)? This is neither intuitive nor consistent...