Allow commands like `flatpak run net.odamex.Odamex` instead of just file paths for executables

[electricbrass]

As it is, users will have to create wrapper scripts to launch any engines packaged with Flatpak. Trying to use /usr/bin/flatpak as the executable and setting run net.odamex.Odamex as additional arguments doesn't seem to work, and if it did, is still less intuitive for most users.

[MTrop]

Unfortunately, I'm not too familiar with Flatpak (or a flavor of Linux that uses it, exclusively).

The execution style might need to be in the vein of how Doomy runs DOSBox applications, if it requires Flatpak as the main executable. I may need help with what a full command for running a Flatpak-enclosed program would look like.

[electricbrass]

So to run the Flatpak for Odamex, which is the only version we distribute for Linux currently, you run the command flatpak run net.odamex.Odamex client to start the client. Starting a Flatpak from the command line is always flatpak run <appid> (and then Odamex has a required argument to select which executable).

After that, arguments are passed on to the package app. So for Odamex, you might do flatpak run net.odamex.Odamex client -iwad doom2.wad -file nerve.wad

Some other programs (don't know if any Doom ports do this) might also have you select between multiple executables using the --command option. This can be used as an alternative for Odamex instead of the default exe selector and a command using that would look like flatpak run --command=odamex net.odamex.Odamex -iwad doom2.wad -file nerve.wad.

[electricbrass]

In general, I expect that fields that take a path to an executable on Windows to instead behave similarly to the Exec key of .desktop files on Linux.
https://specifications.freedesktop.org/desktop-entry/latest/exec-variables.html

[electricbrass]

This also makes the assumption of setup/server executables being in the same folder not make any sense. For example with odamex, starting the server would be done by either flatpak run net.odamex.Odamex server or flatpak run --command=odasrv net.odamex.Odamex

[electricbrass]

I see the DOSBox options you mentioned now, and yes something similar could be done for Flatpak, but it would definitely be less flexible and would only work for Flatpaks rather than being able to work for any other similar packaging formats that may exist now or in the future.

This is always my biggest annoyance with basically every single launcher program I've used on Linux that wasn't designed for Linux first, and it always leads to having to do annoying workarounds that launchers that are specifically for Linux generally avoid by following the same design as the previously mentioned Exec.

[MTrop]

So, in order to accommodate other solutions like Flatpak and AppImage and Snap or what-have-you, how would I go about making a packager-agnostic solution for running a portable image? It looks like every solution has their own method of either executing an image, or mounting an image before execution, which makes a one-size-fits-all type of setup impossible.

Either that, or I'd have to add the concept of "Application Drivers" that are essentially applications that run applications. DOSBox would be one, as would Flatpak or AppImage and the like.

[electricbrass]

AppImage doesn't require anything special, for the purposes of something like Doomy, they're just totally normal executable files.

The simplest solution imo would be:

• Use execvp (or whatever the Java equivalent is) instead of execve so that users don't have to go search for where system packages are installed. The average user shouldn't have to worry about /usr/bin or wherever the distro packages for ports or Flatpak end up.
• Don't assume the server/setup executables are in the same location as the main/client executable
• Move the additional args up from the bottom of the window to directly underneath the paths, and allow separate additional args for all 3.
• Make sure additional args are passed first, with everything else coming after.

This would be the simplest and most universal solution, though still slightly clunky for Flatpaks, which something like the DOSBox solution would probably work. There could be a checkbox or something to indicate that it is a Flatpak, and then when it is checked, the executable path field would be replaced with an App ID field instead.

So with my first suggestion, launching Odamex would have

Engine Paths
EXE Path: flatpak
Additional args: run net.odamex.Odamex client
Server Executable: flatpak
Additional args: run net.odamex.Odamex server

The second suggestion would allow it to be a little nicer:
Engine Paths
Flatpak? [x]
App ID: net.odamex.Odamex
Additional args: client
Server App ID: net.odamex.Odamex
Additional args: server

[electricbrass]

As for Snaps, I don't use them myself, but I think that usually the way to launch them is that they'll get added to the PATH, so the execvp change would be enough. And failing that then it's similar to Flatpak and it's snap run <appname>