Context menu scan

I'm afraid it is not so simple. Windows Explorer uses a documented mechanism of defining, implementing and loading approved contextual shell extensions (actually, there are quite a number of such extensions of other types, but I digress). Implementing such extension is non-trivial, and requires the host application to mimic the explorer behavior - that is, other file managers, which may or may not fully implement support for shell extensions, to at least use the same registry keys and server-side implementation as explorer (server side meaning, in this case, the host application, as opposed to client side which will be the extension itself).

I know for a fact, for example, that Total Commander, which we were ask to support some many years ago, exhibited a small but very unpleasant internal behaviors, which sometimes leads us unable to determine the current directory, or the selected items - a critical thing for a right-click inside a directory; how can one guarantee, for example, scanning a directory, when the host application does not even pass you correctly the very directory you performed the action, or what items are selected to perform the action on. Such "other" applications load shell context extension as they will, but under their own restrictions and conventions (or interest, for that matter). For example, one can do a right click and the context menu extension can choose to operate only on real, disk items, i.e. if I select on desktop, say, two regular files and Control Panel item, the latter is a virtual item and obviously scan does make any sense, at least not as a file or directory item. Other applications loading such context menu extensions can define websites, purchases, credit cards, movies, bookmarks etc. - think of iTunes, for example, which brings under the same umbrella completely unrelated items.

In short: it is quite hard to maintain a single, correct set on shell context menu extension, operating in a correct, cohesive manner in file managers - with many versions on many different Windows versions - we do not know how they behave, or if it will not be some old (or future) bug that can hamper our implementation without even knowing it, or be able to do something about - after all, an extension is just a dynamic library loaded in a foreign application and assumes a cooperation defined by its programming documentation, which, in the case of Windows Explorer, dates back to 1995 - and even they have bugs every now and then - but in the case of others, basically is non-existent.

Now back to the Opus File Explorer (and for that matter, say, Total Commander, which is another file manager often used). I will propose, as an advanced/experimental feature, to support file managers other than Windows Explorer, but this will probably come with a warning for the user, most likely stating the usage in a non-default, experimental version. For now let's see where this goes and what feedback and priority we can get for this. I cannot guarantee when - or if - such an implementation will be done, because this is basically an N-dimensional matrix - multiply A file managers x B versions x C operating systems x D actions x E various actions etc.

I am one of the developers, this is why I wanted to lay out the details regarding this.

The feature request has already been created by me; although I am not (anymore) involved in the contextual menu area, I wrote a number of them so I know what to do. Most likely I will produce a proof of concept so the team can judge and possibly approve this, and I'll see how it goes from there. If or when it will be approved, I cannot say at this time. But I'll push for it, that I can say at this time.

Ah, my bad, did not get it :)

Will do, thanks for pointing this out.

The reason for allowing it only in certain executables comes from - you guessed it - bugs/crashes. We did test it in a number of other hosts, and we encountered various malfunctions, albeit not straight on 100%. The decision was not an easy one, but it was a conservative one: one cannot run in a host known to not play nice with our extensions, and if something bad happens, we will be blamed for the bug (or maybe even worse if that leads to major malfunctions).

What you said I think is the correct way: user should be warned about allowing contextual extensions run under 3rd party hosts, but if this is acceptable, at least to have it possible to use (and, in case it does not for some corner case bugs, be able to disable this and report to us "look, we have ACME file manager version A, and with your product version B this bug/problem arises". I think this use case is the best compromise between the uneasiness of running in unknown and undocumented file managers while letting the user access and use this feature.

I don't know about a beta, since this involves a lot of tedious internal things (testing, release a beta, announcements and all the assortment costs). If this will make thru a release, it will be most likely released as a regular update with the default on off.