-
-
Notifications
You must be signed in to change notification settings - Fork 207
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Any possibility of doing an Appimage? #85
Comments
I haven't looked into Appimages (or Flatpak and Snap packages) so far, but if it works well and doesn't require too much time it certainly might be a good idea - especially for the upcoming 0.1 release. Btw. I'm also trying to lower the GTK+ 3 requirements. I just got rid of the usage of the gtk_widget_get_action_group API which was only available in 3.16. It wasn't really needed at all. Edit: I just installed Debian 8 (which uses GTK+ 3.14 and glib 2.42) and got rid of further API usages which prevented FSearch from building. There are still some minor issues (e.g. some useful glib macros to save some boilerplate aren't available in glib 2.42) but this all can be figured out without losing any meaningful functionality. So GTK+3.14 or 3.12 and glib 2.42 will probably soon be supported. |
Yes, it's best practice to develop against the oldest still-supported LTS/Enterprise distributions. Can you add |
@probonopd, I recently added support for Debian 8, but currently I don't have that much time for coding and there are other things I find more important (e.g. an improved database format and query syntax I've been working on the last couple of months). But if anyone is willing to work on 16.04 support, it should be quite straight forward and I'll gladly accept contributions. |
+1 for flatpak image please. |
This issue is about AppImage. Flatpak does not give you "1 app = 1 file" that you can easily move around. |
second that. how about the chances for an appimage build in the future? |
I'd prefer snap or flatpak vs appimage: It's in a universal repo any distro can use (rather than search for an appimage on some website) and snap because it auto updates. I don't know if appimage or flatpak auto update but if the development is quite frequent it'd be nice to simply get the latest bug fixes. Snap is made more to be developer-centric if they frequently push updates. And it looks like development has picked up in the past few months which might be an ideal time to offer something like that. |
It's not an either-or. Why not have both. I prefer to update only the apps I want to update, when I decide that I need an update. And keep the old version in parallel in case I need it. |
Yes, Flatpak builds are going to happen either way. I already have them working locally and with the 0.1 release they'll be hopefully available on flathub.org. I briefly skimmed over the AppImage documentation and it seemed more complex than the Flatpak packaging, which took just a couple of minutes. So I'm not sure when and if AppImages are going to happen, but it sounds nice to integrate them with the Travis CI for up-to-date dev builds for all platforms. |
While I had no trouble installing the PPA, I now get the daily updates in the form of notifications from my update manager, which is somewhat annoying. Will flatpak "fix" this, or will it also be released daily? |
The PPA are development packages which are built every time there's a code change, the Flatpak packages will be release builds, so they only get updated when I publish a new release - likely every couple months. |
Excellent. Happy to test when it's available. Speaking from experience with other flatpak applications: Have you figured out the sandbox? By default (if the application requests it) they can only access the home directory. IIRC there's an entirely different way to access other directories, and it has to be enabled ("connected") manually I believe. This doesn't matter for many applications like a note-taking app (which conceptually just has its own internal storage and nobody cares where that is). But for something like FSearch, file system access is crucial. |
Yes, FSearch needs wide filesystem access to work properly. Flatpak allows you to set |
AppImages have no enforced sandbox, so that application has full access to the system. |
AFAIU, AppImages are just files without their own distribution system, whereas with Flathub I could get updates automatically. |
Check out AppImageUpdate :) |
For everyone interested, it's now available as a Flatpak: https://flathub.org/apps/details/io.github.cboxdoerfer.FSearch Now I'll have a look at AppImages and Snaps. |
Another vote for AppImage, which is by far the best solution. I hope flatpak and snap die sooner rather than later, and that ubuntu and redhat get back to deb/rpm instead. But I realise that's not going to happen, and it's unfortunate. I see you provide debs (via ppa), so I'll use those. But if you weren't providing debs, I'd want an AppImage. AppImage ftw. |
I'm not very familiar with AppImage yet — only did some brief testing with it to get FSearch to run. I'll try to provide an AppImage for testing in the next few weeks and if they turn out to work well with FSearch and don't require a lot of work to maintain, then I don't see any reason why we shouldn't have them. |
Hello, you said you already did some brief testing, but just in case it's useful to you: I successfully built fsearch as an AppImage with a single command using linuxdeploy with its gtk plugin, on a debian 10 docker image (
results in a 28 MiB executable which also runs fine on ArchLinux. Only problem is that the app isn't themed :-/ not sure if that's fixable |
@phil294, thanks, I tried The |
no, they should indeed be truly self-contained. I had the impression that appimage-builder wrongly leaves out some dependencies if you haven't installed them but I have not tested it long enough so it's possible I misconfigured something. It seems that linuxdeploy only allows a complete build when all dependencies could be found, a desktop file is present etc., which was reassuring to know when I used it. I have no ideas regarding its release plans, no, sorry, I'm only experimenting myself with a few apps. |
For those of us whose distributions don't have gtk+3 3.16 (see the thread on QT interface) would there be any possibility of providing an Appimage?
The text was updated successfully, but these errors were encountered: