Zeal: AppImage for Linux

[probonopd]

Would you be interested to provide an official AppImage for Linux?
That would allow Zeal users to download one single File, chmod +x it, and run. No installation, no root, fully portable, no Qt in the system needed.

I have made an experimental one from the binaries in the trusty ppa:
https://bintray.com/probono/AppImages/Zeal#files

The script that has generated the AppImage is rather simple and can be found here:
https://github.com/probonopd/AppImages/blob/master/recipes/zeal/Recipe

[trollixx]

Sounds interesting. I am not sure how many people would actually find this useful, but why not.

I've got a few observations and questions though.

1. The application doesn't pick up my GTK theme, but rather launches with the default one (Fusion). Perhaps this is fine, but I'd prefer to integrate with the environment as much as possible. Bundling QGtkStyle should fix this, but then there's KDE users too. What's the best approach?
2. If I decide not to create a .desktop file on launch, it keeps asking every time I start the app. Is there an option to respect user's choice?
3. I think using an Ubuntu package as a foundation, is not the best idea. Qt in Ubuntu is quite old, so if providing all the libraries ourselves, then it feels like they should be more fresh.
4. Is there an autoupdate feature, or that should be done manually?

[probonopd]

Hi @trollixx, good points.

1. I am not sure what you mean by this, but you could e.g. write a bash launcher script that checks whether the user is running GNOME, KDE Plasma, or some other desktop, and set some environment variables accordingly.
2. You can prevent these dialogs from appearing if you create an empty file in one of the following locations: $HOME/.local/share/appimagekit/no_desktopintegration or /usr/share/appimagekit/no_desktopintegration or /etc/appimagekit/no_desktopintegration. Are you suggesting that because the user said "no" once, he should never be asked again, for this and/or other AppImages?
3. In oder to maintain compatibility with a wide variety of distributions (more than just the very newest) binaries need to be built on an older base system (e.g., debian oldstable, CentOS 6). Libraries that end up in the AppImage bundle can of course be newer than what comes with those distributions originally. So it is perfectly possible, for example, to build on CentOS 6.x with Qt 5.7 from qt.io).
4. Check AppImageUpdate (Video of what I am working on).

[trollixx]

@probonopd, thanks for the answers!

1. What I want here is for the application to fit in the user's environment. Qt has different style plugins for different environments like Gnome or KDE. It might be possible to bundle different style libraries (they are tiny), and let the Qt to decide which to load, not 100% sure though.
2. It would be nice, if the dialog had a check box "Do not ask again". Should I file a feature request? :)
3. Good. I'd be more interested in bundling the most recent Qt version, tweaked to have only essential parts. That should still work on most relatively modern distributions.
4. Looks really cool! How about some sort of framework to integrate the updater in application itself?
5. Another question. Does AppImage provide any means of verifying the origin of the bundle? I'd like to make sure that my users are guaranteed to run binaries created by me.

[probonopd]

@trollixx

1. I understand what you want to do and I like it, but I am not sure what is the best way to do it - simply never found the time to look into this topic.
2. Go ahead :) better yet, send a Pull request...
3. It does. I am working on a linuxdeployqt tool that takes a Qt application and bundles only the necessary parts of Qt (e.g., from qt.io). Testing, reviews, and PRs welcome! :-)
4. I have thoght about this and it shouldn't be too hard - someone should write e.g., a Qt library that app authors could integrate into their apps. Something along the line of https://sparkle-project.org/ but using AppImageKit binary delta updates using zsync_curl. Do you have some time to help me on this?
5. The updater can check gpg signatures. For example, it could mark as executable only such AppImages that can be traced back to a "known good" source. How exactly this will work still needs to be figured out, though.

[trollixx]

Right now I am working on getting Zeal 0.3.0 out, and there's quite a long list of things in my backlog for the next versions. So, I am not sure on how much time I'll be able to give to this, but let's start with something simple. I'll try to provide an "official" AppImage bundle for 0.3.0, and everything else will follow out of users' requests.

[Trudko]

@trollixx out of curiosity, when do you think 0.3.0 will come out?

[trollixx]

@Trudko 0.3.0 is out, but it will take a few days for me to update all the packages and installers, write a changelog and a blog post, and then look into AppImage.

[BlogBlocks]

That pop-up request if you wish to install:
Would you like to integrate /home/user/Desktop/*.AppImage with your system? Is a pain. AppImage definitely needs an option no check mark NO and remember it. If I tell it yes, the Appimage cannot do it.

[probonopd]

The pop-up should only appear if the AppImage is not yet integrated into the system. So if you integrate it once, then it should no longer ask on the next application launch. Are you saying this is not working? Also, you could use the optional appimaged daemon which registers and unregisters AppImages automatically with the system, without asking.

Did you create a file $HOME/.local/share/appimagekit/no_desktopintegration? If you do this, then the dialog should also no longer appear.

And yes, we are working on your feature request :-)

[trollixx]

I completely forgot that this ticket even exists. Cross-linking with zealdocs/zeal-packaging#34.

[trollixx]

The progress on AppImage can be tracked in the zeal-packaging repo. The question asked in the beginning is answered.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.