Quodlibet: Look into flatpak

[lazka]

https://wiki.gnome.org/Projects/SandboxedApps

[probonopd]

And/or http://www.appimage.org - essentially a self-mounting ISO that contains an application and all dependencies it needs to run on various Linux distributions.

[lazka]

Thanks

[lazka]

lollypop has some code here: https://github.com/gnumdk/lollypop/tree/master/flatpak

[charlesjt]

Today Flatpak is an excellent way to distribute applications for Linux. It has a better adoption among distributions, offers advanced features and is easy to install.

[probonopd]

@charlesjt AppImage has the highest "adoption" because it does not need special support (such as runtimes) from the distribution besides FUSE and common libraries that are "there". The result is that AppImages run out of the box on many desktop Linux distributions, no installation needed.

[charlesjt]

@probonopd No, only one distro (Nitrux OS) offers AppImages by default. On the other hand it is necessary to install additional stuff such as appimaged, firejail, etc. to have additional features (which offer other alternatives such as flatpak by default).

Although it is true that AppImages can be executed in most distributions, not all of them have a consistent behavior, such as adding a desktop access with icon or in some cases, 2 different files are offered (one for older distros). On the other hand, other projects require that your software be installable which rules out this alternative, not always adds a check sum to the file loaded (the user must add excecution permissions in addition to manually locate it somewhere so that it is not accidentally deleted}.

AppImages is an excellent method for portable applications, but not a better alternative to Flatpak (lower application weight, dependency deduplication, atomic updates, etc.) Before I was open to using Snap on my system, but it's really a problem It works out of Ubuntu or Solus OS out of the box, in addition to requiring use of AppArmor and external repos.

[probonopd]

No, only one distro (Nitrux OS) offers AppImages by default.

A distribution does not _need_ to offer AppImage.

Although it is true that AppImages can be executed in most distributions, not all of them have a consistent behavior

That is the whole point of the AppImage format - application authors are in full control and can do as they please.

AppImages is an excellent method for portable applications

Then I guess my ask is that Quodlibet is (also) provided as a _portable_ application.

[charlesjt]

A distribution does not need to offer AppImage.

On the contrary, it is very necessary. Without appimaged in the distro repos for better integration or some kind of integration in the most popular software stores is not user friendly.

That is the whole point of the AppImage format - application authors are in full control and can do as they please.

Come on, it's quite a disadvantage. Although there are very different software distribution methods, there are certain _standards_ for the desktop. In some cases missing a icon, desktop icon, a descriptive name, etc. it is not a reflection of total control on the part of the developer, but an oversight or a problem in the distribution system.

Then I guess my ask is that Quodlibet is (also) provided as a portable application.

In Linux I don't see the need for portable applications and less if they are a audio player IMO. Anyway, if it's your interest, open a new dedicated ticket for the topic, here at least my +1 for Flatpak...

[probonopd]

some kind of integration in the most popular software stores

AppImage needs no software stores (although AppImages can be distributed by them). We have had Macs and PCs for decades without app stores. And to this day, you don't download Photoshop from the App Store.

application authors are in full control

A matter of perspective. For me this is a great advantage. When I encounter "missing a icon, desktop icon, a descriptive name, etc." I know that _the application author_ either wants it this way, or should fix it. Google, for example, forbids third parties to redistribute Chrome. And I can see why. They want Chrome delivered 100% in the way they intend it, no icons changed, etc.

In Linux I don't see the need for portable applications

I do. I hop between tens of distributions and many more distribution versions on a constant basis and if I had to download every application specifically for every distribution and version, this would not be fun.

less if they are a audio player

You have a point here, does Linux really need the 1.001th audio player...

[Meriipu]

does appimage mean you have to download all dependencies (in the image) even if you already have them installed?

[probonopd]

does appimage mean you have to download all dependencies (in the image) even if you already have them installed?

It depends on what an author of an application has put inside the AppImage. Generally we recommend to only bundle such dependencies that cannot be expected to be already present on the target systems (which, again, the application author can define) in a recent enough version. So if the author compiles the software on a system with libfoo version n, and is targeting systems that have libfoo no lower than version n preinstalled as part of their default installation, then he does not need to bundle libfoo.

For specialized libraries that cannot be expected to be present in a recent enough version on all target systems, yes, these need to be bundled inside the AppImage, with the result that they have to be downloaded and stored more than once. This is not much different from how Windows, macOS, Android, and iOS apps work in most cases. It's the price to pay for having no dependencies other than the base system.

[charlesjt]

@probonopd I see what you get out of context some of my comments, but respond to yours respectfully.

AppImage needs no software stores (although AppImages can be distributed by them). We have had Macs and PCs for decades without app stores. And to this day, you don't download Photoshop from the App Store.

Sure, I was relying on the current model that the distros are using for the user to install new software, but consider the following: a) Before the software stores on Linux, the user had the package manager, who automate the entire process via CLI or with dedicated GUIs eg Gdebi, yumex, synaptic, etc. _without app stores_ b) A Windows executable shows a wizard that automates the process and installs everything it owes where it should _without app stores_ and c) In macOS it appears a wizard where it says "copy X file in X folder", where everything is perfectly ordered _without app stores_.

No, it's not the same. With AppImages the user must first verify the download file (if a checksum is available), move the downloaded file to a well-known directory, mark the file as executable, [...], create a desktop file if it is not available, etc. (many times repeat the process just for an update).

A matter of perspective. For me this is a great advantage. When I encounter "missing a icon, desktop icon, a descriptive name, etc." I know that the application author either wants it this way, or should fix it.

But it was not the case. With Snap or Flatpak an author could do the same if he wanted, but there is a greater concern to follow the desktop standards, something that helps a lot to the user experience.

Google, for example, forbids third parties to redistribute Chrome. And I can see why. They want Chrome delivered 100% in the way they intend it, no icons changed, etc.

Yeah! It's a great disadvantage of AppImages, something that is possible using Flatpak. Eg Google Chrome, Spotify, etc.

I do. I hop between tens of distributions and many more distribution versions on a constant basis and if I had to download every application specifically for every distribution and version, this would not be fun.

The concept of portable application is totally different from what you describe ... Are those applications that don't need to be installed in the system, can be used in live distros or from pendrives maybe ...

You have a point here, does Linux really need the 1.001th audio player...

Of course yes! the variety of software available is something that the user always appreciates. What Linux doesn't need is another "universal" method to install applications (this does negatively affect the user experience)... But in the FLOSS world it is about freedom.

[probonopd]

In macOS it appears a wizard where it says "copy X file in X folder", where everything is perfectly ordered without app stores.

With most (albeit not all) Mac apps it's literally just an .app bundle (a directory that the Finder treats as an opaque object) that you _may_ copy to /Applications - or _any other location that pleases you_. (If you are interested, I have recently written a longer article about this here.)

No, it's not the same. With AppImages the user must (...) move the downloaded file to a well-known directory

Like on the Mac, _can_, not _must_. An AppImage will also run perfectly fine right from the Downloads directory, or, for that matter _anywhere_.

mark the file as executable, [...], create a desktop file if it is not available, etc. (many times repeat the process just for an update)

...or use the optional appimaged daemon which automates this for you if you prefer that.

Yeah! It's a great disadvantage of AppImages, something that is possible using Flatpak. Eg Google Chrome, Spotify, etc.

With AppImage the upstream application author (Google, Spotify, Chrome) can 100% decide what to put into the AppImage. So totally _not_ a disadvantage!

The concept of portable application is totally different from what you describe ... Are those applications that don't need to be installed in the system, can be used in live distros or from pendrives maybe ...

Extactly: _All_ AppImages are "portable apps" in the sense that they do not have to be installed and are relocateable. I run all my AppImages on multiple different systems like Ubuntu, Fedora, openSUSE etc. without installing or re-downloading them.

[charlesjt]

With most (albeit not all) Mac apps it's literally just an .app bundle

Yes I know. The point is that the system offers an integration that makes it simple for user, something that AppImage doesn't offer and you deny that it is necessary and contradicts itself when mentioning appimaged as an optional module (it should be mandatory for things to work as they should)

With AppImage the upstream application author (Google, Spotify, Chrome) can 100% decide what to put into the AppImage. So totally not a disadvantage!

Come on, if that were the case, there would not be the problem of distribution of third-party software that we have in the gnu/linux ecosystem. That third parties can package software like Google Chrome in a legal way is a real advantage.

@probonopd Actually I don't want to continue answering, because you omit many of my comments where I argue that AppImage is not a good idea and I only receive replies of the type "please see this from another point of view" that doesn't contribute much to the discussion. If you are still interested in talking about AppImage please open a new ticket for the topic, because here the topic is Flatpak.

[fkrull]

Well, entirely coincidentally (honestly, I swear), I've also been working on Flatpak packaging for Quod Libet: https://github.com/fkrull/quodlibet-flatpak. At the risk of sounding arrogant, I think mine is more thorough and supports more features. :)

Most things work fine. I didn't thoroughly test every core feature, but those're mostly things that shouldn't stress the sandbox anyway.

Plugins

The plugin situation is a bit more sketchy. Things that work:

• MPRIS
• Browse Folders
• Theme Switcher
• Tray Icon (sort of; it works on KDE and Mate, but not on Unity or gnome-shell, but I think that's a general problem)
• Song Notifications
• in general, anything that doesn't talk to the OS or the desktop should be fine

I'm not aware of a plugin that doesn't work correctly (that does work outside of Flatpak), but there are several I couldn't test and a whole bunch I didn't look at.

I included all Python dependencies for the plugins, as well as the binary for kakasi. Any remaining errors in the plugin dialog are missing GStreamer modules. (I'm don't know exactly how those work with Flatpak so I'm not sure if they could be bundled with the application.)

Ex Falso

Ex Falso is installed and works, though I had to call the desktop file "net.sacredchao.QuodLibet.ExFalso" because of Flatpak requirements. There is one issue with it: gnome-shell displays it as "Quod Libet" in the top bar and groups it with QL itself in the window switcher. I don't know if that's a Flatpak thing or if I messed up the app id renaming.

Patches

I ended up with three patches:

• themeswitcher-flatpak.patch adds the directory where Flatpak mounts additional GTK themes inside the sandbox (/usr/share/runtime/share/themes/) to Theme Switcher's search path.
• localedir-flatpak.patch uses /app/share/locale for translations (because Python's gettext module is not smart). This is required for working translations.
• app-id.patch renames the desktop files, appdata files, icons, and any references to those. See also #2792.

The first two I can easily clean up and create PRs for. The third one is basically #2792 done in a rather haphazard way. I'm quite glad that I don't have to do any convincing for that change though...

Further justifications

• I went with the DBus name net.sacredchao.QuodLibet for now, but that could certainly be changed pending #2792.
• I granted complete access to the host file system (well, minus OS things like /usr) because it's only a matter of time until someone wants to access their music collection on a volume somewhere in /mnt.

[lazka]

I included all Python dependencies for the plugins, as well as the binary for kakasi. Any remaining errors in the plugin dialog are missing GStreamer modules. (I'm don't know exactly how those work with Flatpak so I'm not sure if they could be bundled with the application.)

lollypop adds gst-libav and gst-plugins-ugly, seems like a good idea to do the same (at some point): https://github.com/flathub/org.gnome.Lollypop/blob/master/org.gnome.Lollypop.json#L39

[lazka]

For the remaining patches: Might be that we just have to use XDG_DATA_DIRS in those places: https://github.com/GNOME/gnome-sdk-images/blob/b0a5b22100232aa5eb8cbe2bee1f285f454365f7/org.gnome.Sdk.json.in#L32

[lazka]

Things should now work without patches with current master (I haven't tested it though)

[fkrull]

For the remaining patches: Might be that we just have to use XDG_DATA_DIRS in those places

Good find. I'm gonna give it a go.

lollypop adds gst-libav and gst-plugins-ugly, seems like a good idea to do the same (at some point)

I haven't really looked at how GStreamer plugins work, if there's an extension point or exactly what is included. I didn't have any issues playing MP3s, but I didn't try more exotic formats yet. It's worth investigating further, but I need to clean up my branches first.

[lazka]

For the remaining patches: Might be that we just have to use XDG_DATA_DIRS in those places

Good find. I'm gonna give it a go.

(It should be fixed in master)

lollypop adds gst-libav and gst-plugins-ugly, seems like a good idea to do the same (at some point)

I haven't really looked at how GStreamer plugins work, if there's an extension point or exactly what is included. I didn't have any issues playing MP3s, but I didn't try more exotic formats yet. It's worth investigating further, but I need to clean up my branches first.

It's just a bunch of extra .so files in a dir, I assume the dir gets merged with the dir from the base platform(?) and gstreamer will find them.

I think it's needed for wma and aac for example.

[lazka]

@fkrull do you have any plans for moving this to flathub in the end?

[fkrull]

Regarding Flathub: yes, that's the plan.

---

The locales work properly now. I also added libappindicator since it makes the tray icon work in more places (and in the case of KDE, make it work better).

Things that don't work:

• issue #2847
• Unity integration, in particular Unity's special context menu actions.
• Global menus, i.e. Unity or Ubuntu Mate with a global menu. I quite like these, but I guess they never actually made it out of Ubuntu.
• Playing... some?... proprietary audio formats. See below.
• Potentially some other plugins still. There's so many of them.

---

I did some investigation into GStreamer in org.gnome.Platform and what plugins it has (interestingly, org.freedesktop.Platform also has GStreamer, but o.g.Platform replaces it with its own copy).

• o.g.Platform has the obvious plugins (-base and -good) and gst-plugins-bad, but not gst-plugins-ugly (o.fd.Platform has -ugly, curiously, at least parts of it).
• It also has gst-libav linking to the runtime's FFMPEG.
• o.fd.Platform has FFMPEG with "safe" options.
• And then there's "org.freedesktop.Platform.ffmpeg", an extension (which auto-installs rather aggressively) replacing FFMPEG with one with more features. This appears to include AAC at least.

Long story short, the IMO interesting formats should all work. WMA for example doesn't, I tried. There is an extension point for GStreamer plugins, so support for further formats could be packaged separately; which seems more correct than bundling them.

---

The GST plugins that are missing for some QL plugins (bs2b, chromaprint, pitch) are all in -bad, but they appear to require extra libraries so they're missing from the runtime. We can probably bundle those at some point.

[fkrull]

I submitted the package to Flathub now: https://github.com/flathub/flathub/pull/400

[lazka]

Thanks!

[Peque]

Great news! :blush:

[lazka]

https://flathub.org/apps/details/io.github.quodlibet.QuodLibet

[lazka]

@fkrull Do you want to handle the remaining issues on the flathub issue tracker or on this one?