open files - #272

Thanks @tbo47 — this is the follow-up to #265, and moving to a right-click menu is the right call. A process point first, then the things still open before it can go in.

The title and description need to describe everything the PR does. The title ("open files") is vague, and neither the title nor the description mentions that this PR also adds a Delete menu item that permanently removes files from disk. Please always spell out in the title and the PR text what the change does — reviewers, and the changelog/history later, rely on that. Right now the Delete addition is invisible unless you read the diff.

Please split the Delete feature into its own PR. It's unrelated to opening/playing a file, and as written it permanently deletes the file from disk (CPath::RemoveFile, no trash) with no confirmation prompt. A destructive, irreversible action needs at least a confirmation dialog, and it deserves its own PR where that can be reviewed on its own merits.

Then the points from #265 that are still open:

1. Don't duplicate the preview logic — factor it out. OnPlayFile again copies the command-building from CDownloadListCtrl::PreviewFile (%PARTFILE/%PARTNAME, quote-escaping, CTerminationProcess, wxExecute) — the comment even says it "mirrors" it. That's now a third copy. Please extract one shared helper (taking the resolved path + display name) and call it from both controls, so the escaping/security handling can't drift apart.

2. Non-media files should use the OS default opener, not the browser. They currently go through LaunchUrl() (the configured/default browser), which won't correctly open a .zip, a document, etc. Use the platform default opener (xdg-open / open / start) so each type opens in its proper app — that's the same fallback you already use for media when no player is set. Also, the item is labeled "Play" but handles non-media too; "Open" would fit better (or keep "Play" for media only).

3. Gate Play to the monolithic app. Delete is correctly wrapped in #ifndef CLIENT_GUI, but Play isn't — the EVT_MENU(MP_VIEW, …) and the menu item are added unconditionally. In amulegui the paths (GetFilePath() / GetTempDir()) are the daemon's, so Play there opens a nonexistent local path. Please give Play the same #ifndef CLIENT_GUI gate.

Thanks for iterating on this!

One more, on the macOS change in PrefsUnifiedDlg.cpp — I'd drop the VLC prefill.

The comment justifies it with "on macOS aMule can't guess a video player from file associations the way open does" — but it already does. CDownloadListCtrl::PreviewFile (and your own OnPlayFile) fall back to open when no player is configured, and open hands the file to whatever the user has associated with that type. So macOS users with no player set already get a working preview/play via file associations — the only thing the prefill changes is suppressing the one-time informational "set a preferred player" suggestion.

Given that, the hardcoded prefill isn't worth its downsides:

• It bakes a specific third-party app (VLC) and its path into aMule as a default.
• /opt/homebrew/bin/vlc is the Apple-Silicon Homebrew prefix only — Intel Homebrew is /usr/local, and most people install VLC as the /Applications/VLC.app bundle rather than a Homebrew CLI binary — so it misses the common case anyway.
• It's redundant with the open fallback that already covers the empty-player case.

Please drop the prefill and rely on the existing open fallback. This also folds cleanly into factoring out the shared play/preview helper from point 1 — a single empty-player → OS-opener fallback, used everywhere.

Thanks @got3nks , I will divide it in different PRs. I'm closing it for now.