Make Ulauncher available through Flatpak and Flathub

[rejurime]

It would be great to have Ulauncher available through Flatpak. This would make it easier to distribute Ulauncher.

---

If someone could try doing this manually and then listed the steps here with any caveats found along the way, I (@gornostal) will automate the releases for Flatpak

[rowbawts]

I would be interested in seeing this as well.

[gornostal]

I'm not sure how I feel about this.
Yes, it would be good to have a flatpack package, as well as snap (#208), but I don't want to drop deb and rpm packages.

That means more testing, more maintenance work, and probably just a little bit more new users 🤔

[rprihoda]

Well if you plan to go only deb and rpm packages then you'd need/should setup repos for each distro, which is additional maintenance on it's own. If you go flatpak/snap you no longer have to worry about maintaining repos for each distro.

Just my opinion.

[pierrehenrymuller]

Personally I prefer deb packages, in companies with secure workstations, it is easier to offer a deb to administrators who will deploy them on workstations than a flatpack or snap that are not accepted because it would allow users to install their own applications without being administrators.

If you are going in the direction of packaged applications, also keep the deb and rpm for those who have no choice. I chose Ulauncher also on this aspect.

[rakshazi]

Hello from 2020!

Flatpak is still a good thing, so add a flatpak distribution will be a huge plus

[owzim]

Anyone can create a flatpak version of ulauncher. It does not have to be the developers themselves. If you want flatpak, try researching how to build it and then contribute. @gornostal is right, this adds maintenance overhead, so any help is certainly appreciated. /cc @rakshazi @rowbawts @rejurime

ps: I do not use ulauncher anymore, just a bystander :)

[ghost]

@gornostal Would you plese make this available in Flatpak? I am dying to run it on Centos 7. Please please please...

[gornostal]

@bwv656 I've marked this issue as contributor-friendly.
Looking for people who could give clear steps that they've tried and that work on how create a Flatpak build for ulauncher. Then I'm going to add that to the release automation.

[iCSpotRun]

I understand Flatpak's to have privacy and security benefits over anything depending on PPA's. If I'm right, wouldn't this be motivation enough to support Flatpak's? If not, please kindly educate this Noob ;)

[gornostal]

... over anything depending on PPA's

Some user reported (tagged @Ulauncher in twitter) that Ubuntu marks my PPA as not secure. So I would agree with you on that.
I may have not configured it correctly 🤔

Then to your point about Flatpak's security, I got curious about it and quickly stumbled upon this website: https://flatkill.org/
Haven't read it fully yet. But even if Flatpak's security is a myth, I see benefits in having a flatpak for Ulauncher.
It's just not something I would now focus myself, but I would support contributors.

[yozachar]

Hi, this Reddit post has a response to https://flatkill.org.

Flatpak does not have cli support (not till now) but snap does. So will packaging them in these two formats require much change in the source code?

By the way if anyone's interested, here's the official docs to build flatpak and snap packages.

[friday]

The package file would be hundreds of megabytes instead of 7mb btw. We have some big dependencies (GTK and WebkitGTK).

Would we need to add conditions to our code for this, to access the host file system (like scanning for desktop entries, using system icons, picking icons for shortcuts) and launch app with the host file system scope, access to system themes, and not be killed if ulauncher crashes or is terminated (#778)?

How about extensions that access the file system? For example my clipboard extension uses the system themes edit-paste icon, and it integrates with three different clipboard managers by running shell commands. It uses libnotify to show notifications on the host system and it even supports running a custom command to paste https://github.com/friday/ulauncher-clipboard#copy-hook. It's not exactly sandbox-friendly.

And would we be able to have a config/data directory that persists if people uninstall and reinstall?

[gornostal]

It's not exactly sandbox-friendly

I'll second that!
I recently looked into Flatpak docs, the sandbox permissions have to be defined pre-build, which makes it difficult (even impossible) to allow users to change the sandboxing scope at runtime.

[tim77]

The package file would be hundreds of megabytes instead of 7mb btw.

No, it will not.

We have some big dependencies (GTK and WebkitGTK).

This is part of GNOME runtime https://docs.flatpak.org/en/latest/available-runtimes.html#gnome

[friday]

This is part of GNOME runtime https://docs.flatpak.org/en/latest/available-runtimes.html#gnome

That's nice. It has a lot of the heavy libraries we use actually. WebKitGTK, PyGObject, Libnotify and GObject Introspection 👍

Open Build Service added support for flatpak this year, so if we migrate to that (which we have several others reasons to want to do) supporting Flatpak might not require a lot of additional work for us. Or it might. We have a different focus for now before we can make time to look at packaging.

[Arcitec]

I'd say that Flatpak has become the premier distribution method for Linux desktops now. GNOME and KDE agree. They're both integrating Flathub's app donation/payment features too. And Flatpaks are the main way to install applications on immutable distros.

I realize that nobody on the team uses any of this yet, but maybe someday it'll be worth it to create an official Flathub release. You'd definitely start earning donations from it. I'm one of the people who is just waiting for Flathub donations to become available so that I can start throwing money at all my favorite app developers.

[Arcitec]

As for solving the issue of how to run a background task permanently (the launcher/listener): That's a solved problem. The "Pika Backup" flatpak registers itself for Background Activity and registers a ~/.config/autostart/org.gnome.World.PikaBackup.desktop which runs the following permanent background process:

[Desktop Entry]
Type=Application
Name=org.gnome.World.PikaBackup
Exec=flatpak run --command=pika-backup-monitor org.gnome.World.PikaBackup
X-Flatpak=org.gnome.World.PikaBackup

Any other needs Ulauncher might have are fully supported too, such as DBus services, DBus activation (instead of .desktop Exec= activation), "flatpak portals" for all things such as keybindings etc.

[friday]

Flatpak evangelists always say it is easy/possible, but I haven't seen any PRs or unofficial builds for any desktop application launcher or extensible plugin system capable of running arbitrary code on your system, and Ulauncher is both. See albertlauncher/albert#407 and albertlauncher/albert@d223659 for example.

[Arcitec]

@friday Specifically Albert or Ulauncher, you're right, those don't exist on Flathub. But others do, such as https://flathub.org/apps/hu.kramo.Cartridges

It can launch any application or command on the host. It achieves it with one small change to the executed command:

flatpak-spawn --host <put command here>

This command is available to Flatpaks that have the following in their manifest:

"--talk-name=org.freedesktop.Flatpak",

(Source: flatpak-spawn)

There are plenty of other examples, such as Black Box which is a terminal GUI that uses the same permission to launch a terminal that runs completely unsandboxed on the host. The sandboxed application is able to connect to regular stdin/stdout pipes of the flatpak-spawn'd process.

Likewise, persistence/background processes/"autostart apps" are doable with the same method as Pika Backup mentioned above.

Plugin frameworks would work as-is without any changes necessary, because they'd run inside/side by side with Ulauncher inside the sandbox. The only issue with Plugins would be the ones that try to access the host filesystem, but that's solvable with one neat little trick: --filesystem=host, which means the Flatpak application is able to read/write any file it wants to on the host.

So let's recap:

• Flatpak-Spawn Host: Runs any command outside the sandbox. So the only change needed to Ulauncher's "launch something" code is a "if inside flatpak, prepend flatpak-spawn --host".
• Host filesystem permissions: With this flag, it can access any files on the host.
• Background/autostart app: This is doable too, via the same method as Pika Backup above.

I don't think it's worth it for you to try to do this though. Maybe later, when Flathub has the 1-click donation system that's fully integrated into KDE Discover and GNOME Software (later this year/next year), then it might be worth it. 😸

[otsaloma]

Host filesystem permissions: With this flag, it can access any files on the host.

The most common thing launchers do is index apps. I tried making a flatpak of Catapult long ago and had an "oh, of course" moment when I noticed it was just listing apps in the sandbox. Just checked again as I noticed that in the sandbox certain host directories, like /usr are mounted under /var/run/host. I tried setting $XDG_DATA_DIRS, but I couldn't get Gio.AppInfo.get_all() to list my host apps. Interestingly it did list a couple host apps I have installed under /opt with just desktop files under /usr/share/applications, but not anything installed under /usr – I assume there's some kind of a conflict there. So, yes, technically you can access the host filesystem, but it looks still far from being usable (if not wanting to write a bunch of custom flatpak-specific code).

https://docs.flatpak.org/en/latest/sandbox-permissions.html#filesystem-access

[ManuelSchneid3r]

tl;dr For launchers flatpak is nothing less than an absolute catastrophe.

@otsaloma it is hefty to get launchers into flats. on matrix i got told flatpak is not for us.

dealbreakers:

• / (root) is mapped to /run/host, which has a tremendous effect on most plugins ( /bin, /usr/share, …)
• PATH, ofc it is different if the entire filesystem hierarchy got remapped
• XDG_*_DIRS. Desktop entry spec host apps? It maay be possible to write a wrapper script that queryies the host env using flatpak-spawn and try to inject is somehow into the sandboxed app (not sure if overwriting the overwritten env is a good idea. i mean i think it is there for a reason)
• XDG_*_HOME cache, config, data, ipc sockets - everything. in. different. places.
• Running processes: Yeah one could try to remap any started commandline path. Fortunately at albert most calls go through albert:: runDetachedProcess(…), but is this sophisticated? Any plugin using POpen or QProcess will end up in the sandbox or have to take care of remapping paths on its own.
• …

In the end the transition would be far from minimal invasive. A thing I also absolutely dislike about wayland. Seriously, since about 10 years or so development on linux got a major pain. Let alone the distribution problematic. Finally Flatpak to the rescue I thought. Oh dear…

I spend a lot of time on flatpak. and i think i should stop sooner than later or at least give canonicals snapcraft a shot before. by the way OBS is not a perfect solution either (it could, but it is not atm).