Not being an IT person, I always find usability problems when an application is offered as an Appimage. I use Kubuntu 17.10.
Downloading and making executable is not a problem. But is there a way to make using an appimage as easy as a .deb, PPA or from a Software center?
Because:
Extra operations of moving the file from Downloads to somewhere. Unnecessary effort.
If fact there is no indication in Kubuntu where the file should be moved to? Baffled?
Uninstall. Many appimages create a Launcher Icon and data folder. Deleting the appimage does not delete the icon. My system is therefore messed up.
What appimages do I have installed? Is there a way to see them like normal applications?
People say an appimages are not installed. But they do create a data folder and icons.
A .deb, PPA or an app from Software center do not have these 4 problems. Is there a way to avoid them all when using appimages?
I shall try and give you some answers until somebody with more knowledge can give more accurate answers.
Yes, unnecessary effort as you could leave the the file in ~/Downloads if you like. However, I would suggest moving your AppImages to ~/bin to keep them in one place and help you with your issue 4. appimaged also checks the ~/bin directory which will help.
AppImages can be stored wherever you like, but a directory that appimaged monitors is preferable if you want to use appimaged to keep things simple.
Version 1 AppImages did have the problem that they had a popup dialogue that offered to install a desktop icon file but there way no way to uninstall. However, this approach has been deprecated and version 2 AppImages do not offer to install themselves. If you are using appimaged, then deleting the AppImage file will uninstall it from your system.
I do not know of any way to list all the āinstalledā AppImages. The best way that I can think of doing this is to use appimaged and move all of your AppImages to ~/bin.
Basically, have a look at appimaged and see if you think it helps:
Chris, thanks for your thorough answer. Iāll look into appimaged. But itās not that obvious, or mentioned on the Appimage intro. Iād not seen it anwhere Iāve searched. This seems like a big omission.
Edit: Appimaged appears to only make the files executable. Which was not one of the problems anyway. Permissions is in the user space, and not a show stopper. Also, look at the usage instructions for appimaged. It appears not to be a finished program? Or not designed for users.? I double clicked itās appimage, and nothing seemed to happen.
Iām not sure what ~/bin is. A bin sounds like where the rubbish goes. New users will still never know about it, unless the appimage tells them at install.
Are all these things planned to be fixed? As I dread seeing an appimage for download instead of a .deb, which just works. It seems like a step backwards. Should I post a request on Github or somewhere?
I should point out that I am not involved in the development of AppImage, I am just an application developer that uses the AppImage format to release their application for Linux desktops.
AppImages are not comparable to .deb files at all. Firstly the .deb format is specific to Debian Linux and its derivatives. They do not work with Red Hat based distros or Arch based distros. Plus depending on the libraries that the application requires, a different .deb file will be required for different versions of the distro. For example the application developer may need to make a .deb for Ubuntu 14.04, another one for Ubuntu 16.04 and another for Ubuntu 17.10. From a developerās point of view producing .deb files to share an application is a nightmare, I know as this was the first approach that I tried to take with my application.
If you want to compare AppImages to something it would be better to compare Snap or Flatpack packages which use a similar concept of bundling their dependencies and work on most Linux distributions.
~/bin is just a folder called ābinā in your home directory. Linux traditionally keeps its application binaries in a directory called ābinā, usually /usr/bin or /usr/local/bin, so this does make some kind of sense.
appimaged not only makes the AppImage executable but it installs/removes the AppImage desktop files for you. appimaged is a work in progress as I understand it.
Yes but thanks anyway. Letās hope appimaged turns into something useful for normal people.
Snaps or Flatpaks might be OK. But I donāt get to choose what is put on a website for download. I referred to debs, as they are an example of acceptable usability for normal users. You donāt need to post in forums to find out what to do with them.
It seems from this, that appimage is only for IT people. Making Linux harder to use for normal users than other OSs, should obviously be avoided where possible.
Which is why Iām keen to post detailed requests if required. But Iād love to hear from someone that the problems are understood and the fixes are in plan. Or should the distros be offering something?
That looks very nice, in fact I think I prefer AppImageLauncherās approach over appimagedās approach. I shall have to have a play with it as the GitHub readme does not describe how the uninstall procedure works for AppImages.
What we really need is for this, or something like it, to be included in the repositories of the various Linux distributions. That way the instructions for using AppImages do not have to involve finding, downloading and installing the AppImageLanucher program in order to use AppImages.
[quote=āprobono, post:8, topic:340, full:trueā]
this should not be too hard for anyone:[/quote]
I agree.
Which is why I wrote in my first two posts, that setting the permissions is not a problem.
Itās the problems I listed that need fixing in order to help people.
And by IT people I mean those with knowledge, experience and maybe even training in IT tools, as opposed to experience in the user realm. Where you should be able to follow the cues without knowing some specific syntax to the letter.
Is there no way to make the major desktops (like KDE) include AppImageLauncher into their products (I didnāt test the tool yet but it sounds promising)?
I would hope we could convince them. Show them the benefits. However, there might be a way to prompt a download when starting an appimage for the first time?
Hi @ianp5a, @cgarry, I agree the README is still a bit rough, but as the developer, I donāt have the āend userā perspective for the thing. PRs welcome.
The āuninstallā thing works with so-called desktop actions, i.e., in your DEās āapp launcherā thingy, you will get context menu entries like āRemove AppImage from systemā and āUpdate AppImageā (theyāre probably going to be translated in the future). So, thereās no external āapp managerā thingy involved, itās all pretty lightweight and standalone. The only major drawback is that on XFCE desktop actions arenāt supported. But even that has been solved in the latest xubuntu 18.04, the version included there supports desktop actions just fine.
I am sending out proposals to talk about the problem of AppImage adoption on the desktop on some conferences at the moment. I think itās a great way to get in touch with developers from desktop environments and distros. However, I think we should rather talk to the distros instead of the DEs.
Some distros even ship AppImageLauncher already, e.g., Netrunner (Rolling). I hope we can add more distros to this list soon!
indeed, despite having installed the correct version of appimagelauncher on Ubuntu 18.04.3 Budgie, no update option appears in the contextual menu. And the update, even if proposed within the application (Station), is not carried out.
Updating is only available when AppImageLauncher was built with support for that. Most distro-shipped versions lack this support. You can install the .debs from our release page, they support updating (but only if the AppImage supports updates, of course; otherwise the entry will be hidden).
indeed, despite having installed the correct version of appimagelauncher on Ubuntu 18.04.3 Budgie, no update option appears in the contextual menu. And the update, even if proposed within the application (Station), is not carried out.
You may want to try out my experimental Go-based appimaged daemon. It can do updates (if the AppImage has the needed update information inside it).