fsearch
fsearch copied to clipboard
cboxdoerfer
Any possibility of doing an Appimage?
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?
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 trusty to https://launchpad.net/%7Echristian-boxdoerfer/+archive/ubuntu/fsearch-daily? Then I could convert it to an AppImage relatively easily.
@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.
This issue is about AppImage. Flatpak does not give you "1 app = 1 file" that you can easily move around.
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 filesystem=host or filesystem=home in the flatpak manifest, which gives the application either access to almost everything or only the home directory. I'll probably use the host option by default, which works reasonably well. But or course, if someone really needs to access everything, they should use the "native" package instead of the flatpak version.
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.
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 (--privileged to enable libfuse):
./linuxdeploy-x86_64.AppImage --appdir AppDir --output appimage --executable ./fsearch --plugin gtk --desktop-file ./io.github.cboxdoerfer.FSearch.desktop --icon-file ./io.github.cboxdoerfer.FSearch.svg
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 linuxdeploy as well and it did work, but unfortunately it's still in an alpha state, so I don't feel comfortable yet to create official builds with it. Do you happen to know if there are any plans for a stable release in the near future?
The appimage-builder tool also worked to a degree, but I remember there were some runtime issues when I tried to run the FSearch AppImage on a different distribution (some missing or incompatible library, I forgot which one it was exactly). Not sure if this was because I missed something or because AppImage's aren't truly self-contained.
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.