All that really needs to happen is someone writes a patch for nautilus (GNOME Files) to give a more helpful message when someone double-clicks on an AppImage (or on any ELF binary) that doesn’t have execute permission. The message could be something like:
Execute this file as a program?
For security reasons, this program currently does not have permission to run on your computer. If you know where it came from and trust the source, click here to grant permission.
A message like this should pop up even if the user is running appimaged, in my opinion. This is equivalent to the warning given on a Mac when the user tries to run an untrusted .app file.
I approached the Nautilus developers. They were friendly and welcoming, but they said that all platforms (Windows, Mac, Linux) are moving away from allowing untrusted executables to run outside of a sandboxed environment. It is highly likely that quite soon, Nautilus will no longer have the the ability to launch programs by double-clicking on them, even if they DO have execute permission. This means the question of prompting for execute permission is moot, because the program won’t run anyway.
They suggested this course of action:
Add the AppImage MIME-type to the open-with list for a sandbox program.
Double-clicking an AppImage runs it inside a sandbox.
Add the AppImage MIME-type to the open-with list for GNOME Software.
Double-clicking an AppImage opens GNOME Software and asks if the user wants to install the AppImage.
It may also be possible to modify the spec slightly to make AppImages valid flatpak and/or snap packages, but fully self-contained so that they can still be run independently of those packaging tools.
The bottom line from the lead developer for Nautilus was:
csoriano: [with] respect to the file manager: sandbox with perms framework? ok to run, otherwise, no
Sorry to barge in, but how about making small application that can be registered as handler for AppImage mime type? One that would just display window with big “Run It” button and some sandboxing options.
I’m asking because I’ve drafted something like that and come to check if there is any interest for it, finding this thread as first thing
Registering a handler for the AppImage mime type would technically be an option, but since it would have to be installed on the system, why not let the optional appimaged daemon handle everything automatically. We could integrate a GUI similar to what you are showing there; but even better we would make it “just work” like on the Mac without asking the user questions.
In any case, please avoid the word “install” in conjunction with AppImages, since they don’t need to be installed.
Benefit of using mime type handler would be, that appimaged would no longer need to watch directories. It doesn‘t matter which directory the appimage is saved to.
I think a mime type association with a handler is the better approach, since it relies on basic mechanisms offered by any DE. After all, double clicking a txt or png file is one of the most basic tasks, thus mime handlers can be considered pretty mature.
Register a mime could help if appimaged (or another software) is present but it has nothing to do with running the appimage itself.
If there’s a daemon present then register the mime is “free as beer”. If there’s no daemon then it’s a no go way.
I think chmod+x or righ-click->permissions->execute it’s not that hard.
When a user works with linux he needs to know a bit about linux. if I want to drive a truck then doesn’t matter if I’m an ace driving karts… the only thing that really matters is if I know a little about truck driving.
Other thing is that we, as developers, want to give the things the easier possible for the users but hey, if the user don’t know how to make a file executable and don’t want to “learn”… then perhaps he will do better sticking with his os and not blaming linux for be “not as windows/macos”.
Well appimaged (or whatever handler is registered) could then do its magic to chmod-then-launch the file in question. It could even display dialogs such as designed above.
If appimaged is capable of handling the mime type, it would enable distros to behave in a way that the appimage devs want to.
I.e. we don‘t rely on distros to implement appimage specific launcher routines, we „just“ need appimaged to be included in the distribution.
Perhaps I didn’t express myself well, I was talking about the cases when the daemon isn’t available (appimaged package not on distro or not available for some reason…).
I completely agree, and I think this is a necessary improvement over having to use low-level file permissions to mark the .appimage as executable. This is the closest thing currently possible to zipped app bundles on the mac, which I’m amazed that none of the linux environments have copied yet.
The executable bit is a low-level function, meant to separate executables from data files in shell scripts and terminal prompts. It’s not user-friendly enough to pass through to users in a GUI environment.
If the user downloads something with an executable file extension and makes a specific intention to run it by double-clicking, then they are expressing their intent. Ideally the GUI would present a warning and/or authentication prompt the first time an executable is double-clicked before running it. Forcing them to chmod or get deep into a unix-level permissions dialog is a bit cruel.
As it stands, it sounds like a tar.gz file with a shell script launcher is more user friendly than an AppImage, because all the user needs to do is extract the file, then double-click to launch. I think the extraction could even be a bonus, because it gives the user a chance to unpack the app in a location of their choice. The only thing to worry about is the user’s unarchiver stripping the executable bits, but presumably that can be covered by a README file which is referenced only if necessary.
I agree - though you can have an AppImage inside .tar.gz just as well, which is what we do. We don’t make use of the AppImage daemon so there’s no downsides to that approach.
I rather have a solution which doesn’t require system wide installation or any privileges.
It should be somehting really simple.
Better even having it as AppImage by itself (In its portable manner with .home and .configure).
What should it do:
Scan user defined directory for AppImage’s.
If there are new AppImages:
If the AppImage is marked for execution, integrate it with system menu (.desktop).
If the AppImage isn’t marked for execution integrate them with system menu with a .dekstop file which runs it using Sand Box (If available).
If there are missing AppImages, remove their integration.
The above isn’t done using background process. It is a program which does the scan (Once in 5 minutes for that matter) as long as it runs (Let’s say it is a system tray icon). It doesn’t require any privileges or something like that. It is the user responsibility to run it (Or even make it Startup program) at each change of AppImage.
This is a truly AppImage portable inspired integration with the system.
appimaged does not need root rights, does not need to be installed using root rights (it comes as an AppImage itself), and does not need system-wide installation. It does use a background process and inotify which does what you describe, but instantly and without an additional GUI.
I’m new to Linux.
But isn’t a Daemon requires special privileges to run?
Also, how much resources this takes?
Can I configure it to scan single location to reduce its scan time?
Will it automatically run the next time I restart the computer (I don’t want that)?
How can I turn it off once I loaded it?
No. Not if it is running as a per-user daemon. A daemon is really just a program running in the background for a long time with no GUI.
Just having the program idle around in the background will take almost no resources. It is what the program is doing (e.g., extracting the icons, desktop files and such from the AppImage) that takes the resources.
Currently appimaged scans a hard-coded list of locations that is not configurable, in order to reduce (support) complexity. That is not a limitation of the concept of a “daemon” though. We could change this if you show us the need (e.g., that it really makes things faster for you).
Only if you install it. If you just run the appimaged main binary manually, it won’t. Just like with every other application.
If you have installed it, using systemd: systemctl --user stop appimaged. If you just run the appimaged main binary manually, use killall systemd or press Ctrl-D in the window in which you launched it.
This is a bad user experience.
Simple user would like system tray Icon.
I would even say that in the System Tray icon on top of the ability to close it I would like ability to have integration when I start it and it removes all integration when I close it.
Regarding the path to scan, why not have it as an configuration file in .home?
Scanning that much of locations is a mess.So leave it as default yet on first launch it will create a configuration file in .home with the default list of scan locations. This will allow the advanced user to change it.
It seems AppImage is lacking the right User Experience for average users in Linux, really.
