FileBrowser: "Open containing folder" automatically selects file in the OS's file manager

[AW1534]

Introduces a new helper class FileRevealer to manage file selection across different platforms (Windows, macOS, Linux, and other *nix operating systems with xdg). Includes methods to open and select files or directories using the default file manager on the respective platform.

User-Facing Changes:

• Replace "open containing folder" in the file context menu with "Show in [Explorer/Finder/file manager]" respectively for different Operating Systems. This not only opens the containing folder, but highlights the file if supported by the File Manager.
• Adds "Open in [Explorer/Finder/file manager]" option to Folder context menu.

Other Changes:

• Added FileRevealer.h and FileRevealer.cpp to define and implement the file selecting functionality.
• Modified FileBrowser.cpp to integrate FileManagerServices for opening containing folders and directories.
• FileRevealer::canSelect method to check if file selection is possible.
• FileRevealer::select method to select files or directories using platform-specific commands.
• Handling of different file managers on Linux by checking support for the --select option.

[sakertooth]

Sticking to saying "Open containing folder" regardless of OS and opening it using the native file manager (if any) is probably the way to go IMO. It's a lot simpler that way at the cost of little.

Also, I'm confused on what this has to do with highlighting files in the FileBrowser? It seems like if anything, the goal is to highlight files in the file manager on the OS once "Open containing folder" is pressed (which IMO isn't a requirement if it means not having to deal with all the OS-specific file managers)

Additionally, I think we should be using something like QDesktopServices::openUrl and not worrying about all the OS-specific file managers and whatnot.

[AW1534]

Sticking to saying "Open containing folder" regardless of OS and opening it using the native file manager (if any) is probably the way to go IMO. It's a lot simpler that way at the cost of little.

Unless you have other concerns, the only downside is maintainability but that should've been fixed in the latest commit.

Also, I'm confused on what this has to do with highlighting files in the FileBrowser? It seems like if anything, the goal is to highlight files in the file manager on the OS once "Open containing folder" is pressed (which IMO isn't a requirement if it means not having to deal with all the OS-specific file managers)

You're right, this PR is badly titled.

Additionally, I think we should be using something like QDesktopServices::openUrl and not worrying about all the OS-specific file managers and whatnot.

I really do dislike using openUrl. It was really slow for me (like ~5 second wait time) when I was on linux, But almost instant with my PR.

[tresf]

Sticking to saying "Open containing folder" regardless of OS and opening it using the native file manager (if any) is probably the way to go IMO. It's a lot simpler that way at the cost of little.

@sakertooth Many applications have shims that do as the OP is suggesting. I've noticed that this trend has become an unofficial standard over the years for polished software. For example, my IDEs tend to do this same thing and when reading the source code, the techniques are often identical to the OP's. The larger the folder contents, the more useful this feature can become as the file manager will navigate directly to the file that was requested. This is a very well received feature IMO.

[tresf]

Additionally, I think we should be using something like QDesktopServices::openUrl and not worrying about all the OS-specific file managers and whatnot.

I really do dislike using openUrl. It was really slow for me (like ~5 second wait time) when I was on linux, But almost instant with my PR.

I haven't benchmarked openUrl, but I wholeheartedly agree. A pragmatic solution would leverage the underlying C++ APIs, but Linux lacks a consistently shared framework to leverage something like this and Windows + macOS have the support build into the CLI of their file managers, so this really is the simplest approach for 99% of users. For those 1% of users (e.g. Haiku) we'll need to simply fallback to Qt's inferior handling.

[tresf]

@sakertooth @AW1534 how much sense would it be to subclass QDesktopServices into our own implementation and take this logic right out of FileBrowser? This would allow us to eventually leverage the same logic in other/future areas of the codebase and help keep FileBrowser clean of our own implementation.

The code also reads more portable anyway since it uses non-LMMS precompiler definitions and focuses on standard ones (e.g. _WIN32, __APPLE__) which smells a lot like a general good utility class that other projects can copy/pasta.

[sakertooth]

Unless you have other concerns, the only downside is maintainability but that should've been fixed in the latest commit.

Just took another peek at the code and it's a lot better. In particular, we aren't making so many references to platform-specific applications like Thunar, Nautilus, Dolphin, etc. The use of xdg-mime and xdg-open is a nice solution.

Code-wise, I think we can apply some formatting to the new changes, and I think some simplifications can be made. I can help out a bit if you will allow it.

[sakertooth]

@sakertooth @AW1534 how much sense would it be to subclass QDesktopServices into our own implementation and take this logic right out of FileBrowser? This would allow us to eventually leverage the same logic in other/future areas of the codebase and help keep FileBrowser clean of our own implementation.

The code also reads more portable anyway since it uses non-LMMS precompiler definitions and focuses on standard ones (e.g. _WIN32, APPLE) which smells a lot like a general good utility class that other projects can copy/pasta.

It seems like we merely fallback to using QDesktopServices, so there shouldn't be a need to extend from it. However, I do like the idea of putting all of the implementation specific code in one tidy place, which then FileBrowser can reference.

[AW1534]

@sakertooth @AW1534 how much sense would it be to subclass QDesktopServices into our own implementation and take this logic right out of FileBrowser? This would allow us to eventually leverage the same logic in other/future areas of the codebase and help keep FileBrowser clean of our own implementation.

The code also reads more portable anyway since it uses non-LMMS precompiler definitions and focuses on standard ones (e.g. _WIN32, __APPLE__) which smells a lot like a general good utility class that other projects can copy/pasta.

This is a great idea which i'm willing to do, but as @sakertooth said, it probably doesnt need to extend from QDesktopServices

[AW1534]

Code-wise, I think we can apply some formatting to the new changes, and I think some simplifications can be made. I can help out a bit if you will allow it.

absolutely, I'll apply any suggestions you give me

[tresf]

Aaaand.... this is why we can't have nice things. Well, we can certainly whitelist nemo. @AW1534 thoughts?

Ah, wonderful. Yeah, I'll just whitelist nemo. I'll need to do it in a way that other file managers with different syntax can be added easily in future

Agreed. We should probably stash the --select|-R parameter in a variable so we can short-circuit this process for nemo. My latest code recommendations don't do this, so feel free to reject. Ideally, we'd do something like create a string pair for each file manager and do a lookup...

#pseudocode
"open", "-R"
"explorer", "/select"
"nemo", ""
"other", "--select"

[tresf]

Tested new installers in Nautilus, Nemo and Finder, all pass.

[AW1534]

Same with Explorer. I'd now say this is ready for merge