Improve running binaries experience
Goals
- Make it possible to execute binary from the Files browsing UI, as legacy support.
- Keep the primary action (on double click and [Return]) safe.
- Ensure there is feedback that the program is running. in case it takes long to startup or doesn't have a visible window.
Desired behavior
-
Display a new context menu action: "Run as a Program…".
- This is never the first action in the menu, it does not replace "Open".
- There is no keyboard shortcut for this action. Opening the context menu and choosing that action is required.
- This action is displayed for any executable binary file, even if the execute bit is not set.
-
If this program doesn't have the executable bit set, or, even if it does, it has never been marked as trusted, the "Run as Program…" action will bring up a dialog like this:
- If the checkbox is ticked, the "Run" button on the top of the dialog becomes sensible.
- Clicking the "Run" button will both mark the file as trusted (and set the execute bit, if not set yet), and close the dialog and a Terminal window is opened, in which the binary is executing.
-
After you have run the program once, and as long as the file keeps the execute bit, the "Run as Program…" action will directly open a Terminal window in which the program is executing, bypassing the "Untrusted Program" dialog.
-
When a binary executable file is activated by double-click or the [Return] key, or when using the "Open" action from the context menu, the usual "Could not display “goodoldgame.bin”" dialog is displayed, but the dialog's text would explain that if you want to run it as a program, you should open the context menu and choose "Open as a Program…".
Benefits of the solution
- Gives off a legacy support vibe (by calling it "program" instead of "application", displaying a terminal window, etc.) while keeping it easy to use.
- The double click action is always safe because it doesn't allow to run the program, not even indirectly. But it doesn't leave the user helpless either, because it provides instructions to find the action they may be looking for.
- This also makes it possible to extend this feature to executable script files, whose double click action is to be used to open then in a text editor.
- As we don't know beforehand if a given binary will display its own window or not, always opening a Terminal will ensure that there is feedback that something happened/is happening in response to the user action.
- This prevents the situation where a person runs a program that expects input in a terminal emulator. Such program will keep running in the background, without any way to close it except looking for the process to kill it. Worse, you don't even know that something is running in the background, because there is no feedback, so you may try to run it again and it will not make it any better.
- Removes the need to know about and find the execute bit checkbox, instead asks the user to trust the file.
- The execute bit doesn't work as a security measure anyway, because it may already be set without the user's own consent (if extracted from archives, or if stored on a FAT filesystem).
- If the user "trusts" a file for execution, it is not necessary to ask to also check the execute bit. It is implicit in the user's intent.
- The execute bit can be unset at any time from the properties dialog anyway.
Possible drawbacks
- Will display a Terminal window even for programs with a GUI window. A person might think this window is not necessary, close it, and as a consequence also close the program.
- Gnome-terminal already provides a confirmation dialog when closing a Terminal with a running program, which may help mitigate this.
- Text is boring to read. People might not notice the instructions from the "Could not display “goodoldgame.bin”" dialog.
- I purposefully did not mockup this dialog because I'm not very good with text.
- The text for the "Untrusted Program" dialog needs to be improved as well.