Open Explorer.exe in selected directory

[schinagl]

Is it of general use to open Explorer.exe in the selected directory from Winfile?

I use Winfile all day and it is my 'base' for most operations. Thus I created the hotkey Ctrl-E to open an explorer .exe in the selected directory, much like the way as CTRL-K opens a command prompt.

Having an explorer opened via CTRL-E enables me to use a few right click shell extension very fast. So it is an improvement to me.

Should I push my current private PR? What do you think? Is it of general interest?

[Malcolm Smith]

Just my personal opinion (which isn't more valid than anyone else's)...

1. I think it'd be interesting to collect the situations where it's useful to switch from winfile to explorer, because those seem to be opportunities to improve winfile.
2. The current approach of hardcoding programs to open in a directory isn't going to work for everyone.

There's discussion in #44 about this, because as soon as it's possible to launch Bash, the next question is "which bash?" Powershell attempts to address this by enumerating the registry and choosing the one with the largest index, assuming the user would always want the newest that they have installed. Cmd seems completely overloaded with its ConEmu logic. Part of my frustration with this is I have my own command shell (Yori), and it seems inappropriate to try to add support for that into Winfile in code for everyone, but launching it would be more useful to me than any of the current three.

If we wanted this to be extensible, I think any custom entry becomes:

• An open string. I'd personally try to use the same model as Explorer for this, where there's some arbitrary command with a "%1" to expand with the requested directory.
  • The open string should be able to contain environment variables, so it can default to entries including %SystemRoot%, allowing Cmd and Powershell to be located without assuming the user's install location.
  • The "%1" can be optional since ExecProgram will try to launch anything with a specific current directory, which is frequently sufficient.
• An optional elevated open string, since Cmd requires something different for this.
• A shortcut key. Maintaining compatibility with current behavior implies this can be almost anything, which is unfortunate but still achievable.

Part of me also would like to proactively parse these strings, check if the executable can be found, and hide entries for executables that aren't found. Bash and Powershell are both optional, don't exist on older versions, etc.

I'll also go on the record and assert that anyone who's knowledgeable enough to install ConEmu and use it with winfile is knowledgeable enough to configure winfile to use it, and its presence here is purely because there's no way to customize current behavior. That said, the hiding logic above would make it possible to have a default entry for ConEmu that most users would never see.

This is something I've been wanting to do for a while, but obviously this is just one person's thoughts on how this could work, so I'd appreciate any feedback.

[Craig Wittenberg]

FYI: I accomplish this by using File.Run with "." as the parameter.

[schinagl]

The reason for switching to Explorer are ShellExtension: Archivers, renamers, ...

I would not add ways configuring the menu for arbitrary ‘shells/…’. This adds complexity, which no one will understand without reading a docu.

There are a few standard programs which should work out of the box, like command prompt, PowerShell, Bash… and 😉 Explorer.

Craig’s approach is genius, but nobody will find this out without reading this thread.

If we spend a hard coded menu entry and a few lines of code, everyone can fire Explorer without the burden of configuration nor reading this thread for File.Run “.” 😇
Little effort, much gain

[Malcolm Smith]

This adds complexity, which no one will understand without reading a docu.

I think we should agree to disagree about that part. Both winfile and explorer support customizing file type associations. In explorer's world view, a folder is just a specific type of file. Customizing it seems much simpler than the current associations dialog (because it's only one type, not an arbitrary type.)

Thinking more about this, I think there's three separate things:

1. Personally I think the file menu/context menu is far too long already and represents bad UX, so I'd like these things grouped into a submenu.
2. Hiding items that aren't installed allows less frequently used hardcoded items to be added since there's no visual cost for the majority of users.
3. Customization allows less frequently used items to be added on a per-user basis.

Each of these is independent from the others.

For the first point, note that the number of top-level menus has actually shrunk since NT 3.1 (due to removing security), but the number of functions has increased, which results in a small number of long menus, and the bulk of new capabilities have all landed in "File." One option would be to create a new "Directory" top level menu and move the "Create Directory" - "Goto Directory" items there. This isn't perfect since many file tasks apply to directories too.

As I think you both know, I don't mind doing boil-the-ocean changes, but there's no point attempting them if there's no appetite for merging them later. The single biggest thing limiting my involvement in this project is seeing a large list of things that need doing and not being clear that any of them would be welcomed. So with respect to these points, I'd like to know if there's consensus to be found in at least one aspect of the problem(s).

[schinagl]

ad 1) I agree that the menu is far too large. Bad UX. Sub menu: Could be an option: Little effort, little gain, little usability complexity added. Well if one really chooses the option via menu it is more uncomfortable. ( I am personally not affected because I use hotkeys all the time)
ad 2) On my system only bash is affected. IMHO: medium effort, little gain, little usability complexity added.
ad 3) I agree to disagree ;-) IMHO: high effort, little gain, high usability complexity

So my comfort zone is;

• little - medium (sometimes high, see UNC) effort,
• high gain,
• little usability complexity added

We can also agree on just documenting File.Run "." for opening an explorer, which would be, little effort, high gain, little usability complexity added. The risk with this is, that the average 202x users doesn't read documentation: They download it, fire it, and it shall work.