Guidelines and HOWTOs/Flatpak

Flatpak is a solution for creating sandboxed software builds for GNU/Linux systems. You can find more information here.

KDE Runtime

KDE Software approach to Flatpak is still not ready. Nevertheless, it's being shaped up. If you're interested in helping, please send an e-mail to [email protected].

The idea behind flatpak is that your applications will depend on a runtime. KDE provides a runtime with Qt and all KDE Frameworks 5 (except for the 4th tier) to make sure it's easily adaptable for any KDE Application and possibly most Qt-based applications as well.

This runtime can be added by following these instructions:

wget http://distribute.kde.org/kdeflatpak.asc
flatpak remote-add kde http://distribute.kde.org/flatpak-testing/ --gpg-import=kdeflatpak.asc
flatpak install kde org.kde.Platform
flatpak install kde org.kde.Sdk

Warning

Do NOT use this in production, it's work in progress and it doesn't enable important safety features. It might also eat your pet or first-born.

Compile your application

Now you get to compile your favorite application. If you want to see how it's done, you can see some of the ones that have already been built. You can find it here.

To compile an applications, you should create a json file similar to the ones in the previous link. Then you'd just need to trigger the build and get it into a repository. For testing, I recommend just creating a local one (to publish an rsync will be required).

mkdir app repo
flatpak-builder --ccache --require-changes --repo=repo --subject="Build of AWESOMEAPP `date`" app org.kde.AWESOMEAPP.json

This will do everything required and create a repository in ./repo. To test the application we add the repository (called remotes), we install the application and then we run it:

flatpak remote-add awesomeapp repo --no-gpg-verify
flatpak install awesomeapp org.kde.AWESOMEAPP
flatpak run org.kde.AWESOMEAPP

Now you will see that some things don't work and you'll have the privilege to start fixing things!

Note

All flatpak commands (such as remote-add and install) accept a --user option to install things at the user level, without being prompted for the sudo password every time.

Contribute!

In the following repositories you'll find the code in charge of packaging the runtime (Qt 5 and KF5) and then several (but not all, yet) KDE Applications.

• Runtime: https://quickgit.kde.org/?p=flatpak-kde-runtime.git
• Applications: https://quickgit.kde.org/?p=flatpak-kde-applications.git

Flatpak portals

Portals are high-level session bus APIs that provide selective access to resources to sandboxed applications. The implicit expectation of portals is that the user will always be involved in granting or rejecting a portal request, thus most portal APIs will lead to user interaction in the form of dialogs.

Since such dialogs must fit into the user experience of the desktop shell, the portal APIs are implemented by a generic frontend called xdg-desktop-portal which calls out to desktop-specific implementations that provide the actual UI. The bus name through which the portal APIs are available is org.freedesktop.portal.Desktop, with the object path /org/freedesktop/portal/desktop implementing the various portal interfaces.

Note

You can find more information about flatpak portals here.

KDE implementation of portals

Currently there is some basic implementation of FileChooser, AppChooser and Notifications portal, which you can find here under xdg-desktop-portal-kde. To force Qt applications, which are running in sandbox, call flatpak portal frontend instead of e.g. displaying a file dialog we implemented a platform plugin. This plugin basically just replaces file dialog and openURI with DBus calls. If you want to test KDE flatpak portals, you can use this simple test app.