usability improvement: change selection on right click

[Dromantor]

It would be beneficial from my point of view if right click on a non-selected line in the result list also changes the selection to the right-clicked result before popping up the context menu. Currently you have to left click every item before issuing a right click, which gets annoying when I want to edit multiple files in a row.

Bonus improvement: Modifier key for opening a result file on double click, not just expanding it. Ctrl + double click or middle click alone would be nice. Currently you have to expand, then double click on a line, or right click -> open (which only works when first left clicking a line; see original request).

[doug24]

@Dromantor - I'm looking at this now. I agree with your suggestion 'right click on a non-selected line in the result list also changes the selection to the right-clicked result before popping up the context menu'.

But what about the modifier keys? Should shift-right click or ctrl-right click also extend the selection? In Visual Studio, for example, they do not. When the modifier key is down, the selection(s) remain as-is and the context menu opens. Trying to think of other applications to try - any suggestions?

I haven't looked at the ctrl+double click yet, but I will see if I can do something.

[Dromantor]

But what about the modifier keys?

Tried a few things:

• vscode, regedit, text editors (the text field itself)*, Excel* : ignores them, drops original selection
• windows explorer, Everything (the program, not really everything): ignores shift, retains original selection on ctrl
  • somewhat understandable as shift is a modifier for the context menu to show otherwiese hidden things
• freecad: retains on shift and ctrl
• bonus test - ALT modifier: anything that uses the native windows context menu (and dngrep too) bugs out (opens for a few ms and closes again)

* apples and pears, I know, just for completeness

I can't really think of many other programs using a list view of things.

Just a thought of mine: If I would implement it in my program (and I don't need any of the keys as a modifier like the windows explorer does) I would make it consistent with left click, just to reduce the possibility of confusion. Means: Ctrl adds before popping up menu, shift adds range from last selection and pops up menu, and I would probably add Alt for retaining selection since it doesn't have another use. That way I also could reuse the logic from LK and don't have to implement something different.

[doug24]

@Dromantor - thanks for the input. Yes, I think it will be easier if right click does the same selection changes as left click.

[doug24]

ctrl+double click isn't going to work because the first click with the ctrl key down changes the selection.

I have alt+double click working, so thinking of going with that.

[Dromantor]

I think that's fine*.

* Would prefer scroll wheel button though, as it would mimic the logic of middle clicking a link on a webite to open it in another tab - or in an external program in this case. But I've seen some people avoid/hate or just don't think of middle click. Maybe both? Would be nice. If not I may just rebind it with autohotkey.

Didn't say it yet, so thanks for actively looking into my suggestions (the second time actually).

[doug24]

Handling the middle button click to open the file was easy but figuring out how to first change the selection on middle button click took a while. I think we can keep both.

I think both middle click and alt+double click are both equally obscure, and I don't know a good in-app hint. I'll put them in the help pages, but I doubt they see much traffic.

[doug24]

Both of these would be opening with the custom editor, if one is set in the options. I wonder if one should open with the default application for the file association? Same as "Open" and "Open with custom editor" on the context menu.

[Dromantor]

Didn't even think of this yet (and haven't seen "Open with custom editor" at all until now *) as I don't have one configured.
One could add Alt+MCLK for that ;-) But then there is no modifer combination for doing the same with DBLCLK ...
Or just use the Alt+DBCLK for that, logic: it already has a modifier key in there, so this does something different than default, which is custom editor.
I start getting a headache the more I think about it ..... modifer key madness.

* I noticed that a program restart is required for it to show the "Open with custom editor" in the context menu, or to remove it again when removing the custom editor (which causes the default app to open when clicked after removing it). Wouldn't just greying it out (with tooltip: "Not configured.") be preferable? Improves discoverability.

For the discoverability of MK: MK is the first thing I tried after Ctrl+DBCLK and Shift+DBCLK didn't work. Since it has some comparable effects in other software (browser: open in new tab, windows taskbar: open new program instance, so something new opens in both cases), it may actually get some use without reading the help page.

[doug24]

Thanks for the suggestions on custom editor context menu. I fixed the problem needing restart, made it visible always, disabled when no custom editor is configured, and added the "Not configured" tooltip.

Here's where I am with the actions:
Double click on a file node expands the node (existing functionality)
Double click on a child line opens in the custom editor if configured, otherwise the associated application (existing functionality).

Alt+double click on either a file node or child line opens in the associated application (new).

Middle mouse button click on either a file node or a child line opens in the custom editor if configured and the associated application otherwise (new).

I think this is the most uniform behavior given the existing double click action - the alt+double click does something different from plain double click.

[Dromantor]

Yeah, this sounds pretty good.

[doug24]

Added in v4.0.69.0