Opus allows to add tags to arbitrary files (via Metadata pane -> Extended properties -> Tags). How about publishing a VFS plugin that shows a directory structure based on tags instead of the real directory structure? That is, if a file had tags A and B, and another file in the same (real) directory had tag C, in the VFS view the first file would be shown under (virtual) directories A and B, and the second file would shown under directory C. Also, the virtual A directory would contain a nested virtual B directory, which also contains the first file, as it as both tags. Similarly, there would be a nested A directory under B. In other words, navigating through directories works like filtering on tags: All files below a specific virtual directory have the tags named after the directory.
I've found the information about where the tag data is stored in the help:
"If the selected file formats support those properties natively (for example, JPEG files do) then the information will be stored in the file itself. If the selected file formats don't support these properties (like .txt files, for example) then Opus will attempt to store the information in an Alternate Data Stream attached to the file."
We could provide an API for VFS plugins to get the tags. (There's already an API for scripts to get them, but it's never been needed by plugins.)
Are you asking for help writing a VFS plugin or are you asking for a VFS plugin to be written?
Since there is no central database of tags, any such plugin would either have to maintain one or have to scan every individual file of interest each time it was started, which could be slow. Using the Windows Search index may make sense, in which case no new API is needed either, but only if the tags you're interested in are indexed by Windows Search.
Are you asking for help writing a VFS plugin or are you asking for a VFS plugin to be written?
Well, in the best case I'm asking you to write such a plugin, and ship it with Opus by default.
However, if you either reject the request or it's going to take you too long to implement (e.g. due to more important features to add), I'd consider writing such a plugin myself.
[...] scan every individual file of interest each time it was started, which could be slow.
Correct.
[...] only if the tags you're interested in are indexed by Windows Search.
I doubt that Windows Search would indexed the tags, as depending on the file type Opus might store them in a custom NTFS ADS called "OpusMetaInformation". (BTW: For some reason the stream name seems to be prefixed by an unprintable character.)
So in any case, a prerequisite would be that you add an API for VFS plugins to get the tags, and I'd be grateful if you could do that.
We won't have the resources to write such a plugin any time soon, so you'd need to write it yourself (or get someone else to).
We're happy to add to the VFS and plugin helper APIs as is needed to get things done, as well as to help with any questions about using the APIs.
I think it would make sense to get a basic plugin working first, using its own mock API that e.g. has a hardcoded table which says "if you ask about filepath X, return tags Y", to test that the idea is going to work and be feasible. That will also give you a concrete version of exactly what you need from Opus in terms of the extra API, which we can then fill in for you to replace the mock API.