[Feature Request] Do we really need AppDir and runtime.c as it is commonly believed?
Opened this issue · 7 comments
Unfortunately, I couldn't find another option for ask you about architecture of shappimage
If I understand correctly, this project uses AppDir, which consists of AppRun (not relevant for this project) and DirIcon (not relevant, since there is an icon provided by the developer at the cherry level)
It seems to me that if you reinvent AppImage, you can reinvent AppRun as well, following FHS
bin/ for binary file
share/icons/ for icons
share/metainfo for AppData files (metainfo.xml)
share/signature for asc, gpg files
I also think to stipulate a special role for metainfo, which probably allows you to open the application in the software center via the appstream:// protocol.
Yup, it uses AppDir so that existing AppImages can be converted easily as my main goal when starting this was to make a "fat AppImage" although I'm not at all opposed to beneficial extensions as long as the build processes and usage remains pretty similar.
I've thought about some ways to negate the need for an AppRun (like integrating it into the runtime) but didn't go through with it because I thought it might be too confusing. If there is an advantage to doing so then it might be worth adding. Can you elaborate further on using FHS? I believe most AppImages already use a hierarchy like this
I'd also like to hear more about what you're saying about the metainfo, are you talking about actually opening the shImg in a software manager (eg: Gnome Software)? I've messed with AppStream metainfo a little but don't know much about it. What would be the point of opening in a software center?
And wow, I can't believe I've never heard of Conty before. It looks really cool and seems to have a lot of similar goals. ArchImage also looks pretty interesting
Glad to see you!
Can you elaborate further on using FHS
I jumped to conclusions here. The idea was to combine the integration level of the application and the main application (cherry level and meat level). Now I understand why it is better not to do this at all (inside squashfs the data cannot be read)
I've messed with AppStream metainfo a little but don't know much about it. What would be the point of opening in a software center?
I believe this would solve the AppImage problem, the new iteration could not only be downloaded from different places but also opened in the app center via the protocol, however I find the API a bit more confusing. Read more here https://www.freedesktop.org/software/appstream/docs/chap-AppStream-API.html and https://www.freedesktop.org/software/appstream/docs/api/index.html
Now I think it would be cool if shImg was a self-extract archive that did 2 things when turned on at the same time: mount squashfs and integrate the top layer into your system. I think the makeself program here will help us a lot https://github.com/megastep/makeself
But I don't know exactly how to implement it yet, maybe I should leave the upper levels as a script and add self-extracting archive only on cherry level
Ah I see what you mean. It should actually be pretty trivial to integrate the desktop integration info into a host system. The main issue is doing so in a way that's a good experience for the user.
As for the metadata placed inside the SquashFS image, that's how AppImages already do it but I added the zip to make it easier to access (if you use unzip on a shImg, it will extract all desktop integration data into a folder). It also comes with the advantage of not needing a SquashFS image at all for certain single-executable applications. This would allow desktop integration and multi-arch applications with less overhead and no need for FUSE. Might be good for some console applications
I believe that older versions of AppImage used to have a dialog asking if you want to integrate it, but this was removed for some reason. I think such a solution wouldn't be too bad and could be implemented using zenity, yad, kdialog (whatever is detected on the system). If nothing is found or if a special file telling all shImgs not to integrate their data then it would simply act as it does currently.
I think we can move away from the concept of AppImage, to the mandatory integration of AppImage into the system. The difficulty is how to remove additional files like metainfo, icons, signature, etc, when deleting the shImg.
I'm not really sure if I'm on board with mandatory integration, some people might view it as a nuisance. I think a simple popup along the lines of "Would you like to add this program to your application menu?" And an option to apply the answer for future applications might be a good compromise
There's not a ton you can do about cleaning up (without a daemon) if the user were to simply delete the file (although there is the desktop entry TryExec key which should remove the program from menus if the file isn't found)
I believe you can also add custom context menus in desktop entries (although I forget how), but I imagine they could be added to clean up all integration info when clicking "uninstall".
Something I have been considering adding is an updater directly in the runtime itself, which could be added automatically if update information is provided, although I'm not yet sure what the space overhead would be.