Jan Grulich

Flatpak

When Your Webcam Doesn’t Work: Solving Firefox and PipeWire Issues

- jgrulich Leave a comment

If you are a regular reader of my blog posts, as I am sure you are, you will know that we made a switch with Fedora 41 and now use PipeWire as the default backend for camera handling in Firefox. It won’t come as a surprise that such a huge change is not without its problems. After talking to many of you and debugging the same issues over and over again, I would like to go through most of the common issues and show you how to fix them, and also shed some light on the whole stack.

For Chrome/Chromium users out there, most of the issues mentioned here also apply to you, as most of the PipeWire camera code is shared in WebRTC, but I must mention that the PipeWire camera is completely broken in M131 and fixed in M132.

Issue #1 – Permission issue – “Camera is blocked” or “The request is not allowed” etc.

This is the most common problem and is usually caused by the user not giving access to the camera to an application that is requesting it. When Firefox wants to use a camera, it makes a request to the camera portal (xdg-desktop-portal). This results in a system dialogue asking for camera access for Firefox. If access is granted, it will be granted for all future sessions, but if access is denied or the dialogue is closed, it will remember this decision and all future requests to use the camera will be automatically denied.

You can check this by running:

$ flatpak permissions devices camera
Table   Object App                 Permissions Data
devices camera                     yes         0x00
devices camera org.mozilla.firefox yes         0x00

In the result you will see that “org.mozilla.firefox” has “yes” stored in the permission store. There is also an empty entry with “yes” stored. The empty entry is usually for applications for which we were unable to get an application id. This happens for host applications that are launched in an unusual way, such as the Alt + F2 command or from a terminal. If you have a permission problem, you will most likely see “no” stored there, and this is what is causing the problem for you.

You can clear this and be prompted again for camera access running this command:

flatpak permission-remove devices camera org.mozilla.firefox

You may be wondering why flatpak is involved, since you don’t use flatpak applications. Flatpak is not really necessary, but I use its command line to work with the permission store and it is easier for me to just give you a command and you give me the result, otherwise you could also use Flatseal to check your camera permissions. The permission store comes from portals (xdg-desktop-portal), which we use to get access to your camera. While portals were originally intended to be used mainly by sandboxed applications (Flatpak, Snap), they are now also used for things like screen sharing (Wayland) and now the PipeWire camera, making them an essential part of the Linux desktop stack. Always make sure that xdg-desktop-portal is installed with a specific portal backend for your desktop, e.g. xdg-desktop-portal-gnome for GNOME or xdg-desktop-portal-kde for Plasma.

Issue #2 – No camera found

This can be a problem with many components. Let’s start with the most important one, which is finding out if Wireplumber (the session and policy manager for PipeWire) detects it.

You can run:

$ wpctl status
Video
 ├─ Devices:
 │      50. Integrated Camera                   [v4l2]
 │      62. Integrated Camera: Integrated C     [libcamera]
 │      63. Integrated Camera: Integrated I     [libcamera]
 │      69. Integrated Camera                   [v4l2]
 │      85. Integrated Camera                   [v4l2]
 │      93. Integrated Camera                   [v4l2]
 │  
 ├─ Sinks:
 │  
 ├─ Sources:
 │      76. Integrated Camera (V4L2)           
 │  *   80. Integrated Camera (V4L2)           
 │  
 ├─ Filters:
 │  
 └─ Streams:

Here we are mainly interested in “Sources“, as this is what will appear in Firefox. Typically, most laptop cameras appear here twice, as one is an infrared camera for Windows Hello support, which we already filter out in Firefox. If your camera doesn’t appear there, it won’t work in Firefox or any other application that uses PipeWire.

If your camera is listed there but doesn’t appear in Firefox, I usually recommend that people try OBS Studio, which has great support for PipeWire cameras. This will always tell you if the problem is in Firefox or somewhere else. If it works in OBS Studio, you can open a bug to Firefox with all the necessary information (see below). If not, it is probably a bug in PipeWire.

We are already tracking one issue with the v4l2 plugin in PipeWire. This is most likely a race condition for which we have at least a workaround in the form of switching from v4l2 to libcamera.

In order to use libcamera, you can create following file:

$HOME/.config/wireplumber/wireplumber.conf.d/99-libcamera.conf

With the following content:

wireplumber.profiles = {
 main = {
   monitor.v4l2 = disabled
   monitor.libcamera = optional
  }
}

And restart both Wireplumber and PipeWire:

systemctl --user restart pipewire wireplumber

If this doesn’t solve the problem for you, please follow the instructions below to report a bug to Firefox.

Another known problem, probably a rare one, is if you restart PipeWire while Firefox is still running. This is because we keep a connection to PipeWire and when you restart it, that connection is broken and not initialised again. This problem affects OBS Studio in the same way and I’m already working on a fix. The solution here is to restart Firefox.

Debugging and reporting issues to Firefox

You came here because none of the above worked? You can still report a bug with all the necessary information to help us identify the problem. First, you want to report a bug to Firefox upstream. You can do this here by selecting the “Core” product and the “WebRTC: Audio/Video” component and providing all the logs from below.

Include DBus communication with xdg-desktop-portal.

Open a terminal of your choice and run:

dbus-monitor --session

Keep it running, while you try to access the camera in Firefox. For example, using the WebRTC getUserMedia test page. You should see all the DBus communication in the log from dbus-monitor.

Also a useful information might be to know whether the camera portal see any camera by running:

dbus-send --print-reply --dest=org.freedesktop.portal.Desktop /org/freedesktop/portal/desktop org.freedesktop.DBus.Properties.Get string:"org.freedesktop.portal.Camera" string:"IsCameraPresent"

Including log from Firefox by running it with:

MOZ_LOG="MediaManager:5,CamerasParent:5,CamerasChild:5,VideoEngine:5,webrtc_trace:5"

And a log from:

pw-mon

Which will provide all advertised formats by your camera and supported formats by Firefox.

Last resort

Once you have done your duty and opened a bug with all the above information, which I’m really grateful for, you can now go to “about:config” in Firefox, disable “media.webrtc.camera.allow-pipewire” and restart Firefox. This will switch back from PipeWire to v4l2, but I hope you will accept this as a temporary solution until we can identify and fix your problem.

Debugging and reporting issues to Chromium

All the logs you can provide also apply to Chrome/Chromium, with the exception to logs from the app itself.

In order to get logs from Chrome/Chromium, you need to run it with:

google-chrome --enable-logging --vmodule=*/webrtc/*=1

Once you have collected all the necessary logs, you can open a bug here for the “CameraCapture” component and add me to the bug (use grulja AT gmail.com) or let me know at least so I’m aware.

To switch back from PipeWire to v4l2 you have to go to “chrome://flags” and disable “PipeWire Camera support“, but you already know that since you had to enable it yourself before :).

How to use libportal/libportal-qt

- jgrulich Leave a comment

There was a blog post from Peter Hutterer about Flatpak portals posted few months back. Peter explained what are portals and how do they work. Portals are used mostly because of security and sandbox/Wayland restrictions. Many times your only way to get access outside (opening a file, sending a notification, sharing a screen, etc.) is to use a portal. For most use-cases applications or developers don’t need to care about them as their support is usually implemented in libraries they use. For example Qt and GTK use portals internally so apps can use still the same APIs as before and they don’t need to worry about their apps not working in sandboxed environments. BUT there are still scenarios where libraries have unsufficient or none portal support, or a different options are desired so what are the options in this case if you still need to use portals?

  1. Do everything yourself, which means you will implement all the DBus calls and handling yourself.
  2. Use a library. Most logic choice would be libportal, but there is also a project called ASHPD for Rust users.

What is libportal and libportal-qt?

The libportal library provides GIO-style async APIs for Flatpak portals. It hides all the DBus complexity users would face in case of using portals directly and provides a user-friendly library instead. You might think that the libportal-qt is the same thing, just with Qt-style APIs, but the idea behind it is that each toolkit (Gtk3, Gtk4, Qt5, Qt6) has a different way to get a window handle which is needed to associate portal dialogs with the app that invoked them. So libportal-qt just provides a way to get a XdpParent object from a QWindow. As a C++/Qt developer I don’t mind using C/Glib APIs and I used it many times, but there is still one speciality I fail to use everytime, my friend GVariant. Some of the portal APIs in libportal expects a GVariant for all the complex structures, for example to specify a filter option for OpenFile() call from the fillechooser portal, you have to build a very complex GVariant based on the DBus specification.

Remember I told you libportal-qt doesn’t offer Qt-style APIs? This is not necessarily true, because I implemented all the complex structures you will have to pass in most of the portals and implemented functions that will return them as GVariants so you don’t need to get in touch with GVariants at all.

How to use libportal-qt?

First of all, all libportal flavours have pkgconfig file installed so it’s easy to use them from any build system and you just need to search for libportal-qt5 (we don’t have -qt6 version yet).

And how does the code look like? For example let’s say you want to open an image:

// Creates a filter rule, this can be a Mimetype or Pattern.
XdpQt::FileChooserFilterRule rule;
rule.type = XdpQt::FileChooserFilterRuleType::Mimetype;
rule.rule = QStringLiteral("image/jpeg");

// Create a filter with our rules, we will then pass it to OpenFile() call as GVariant.
XdpQt::FileChooserFilter filter;
filter.label = QStringLiteral("Images");
filter.rules << rule;

// Create a GVariant from our filter. This will result into variant in form of:
// "[('Images', [(1, 'image/jpeg')])]"
g_autoptr(GVariant) filterVariant = XdpQt::filechooserFiltersToGVariant({filter});

// Get XdpParent to associate this call (portal dialog) with our window.
XdpParent *parent = xdp_parent_new_qt(m_mainWindow->windowHandle());

// Finally open a file. XdpQt::globalPortalObject() is another convenient function 
// that creates a global instance of XdpPortal object so you don't need to take care
// of creating it yourself. For some of the arguments we just pass a nullptr to don't 
// specify them.
xdp_portal_open_file(XdpQt::globalPortalObject() /*XdpPortal object*/,
                                  parent /*XdpParent object*/, "Title", filterVariant /*filters*/,
                                  nullptr /*current_filter*/, nullptr /*choices*/, 
                                  XDP_OPEN_FILE_FLAG_NONE /*flags*/, nullptr /*cancellable*/, 
                                  openedFile /*callback*/, this /*data*/);
xdp_parent_free(parent);

// Then the callback would look like this, eg.
static void openedFile(GObject *object, GAsyncResult *result, gpointer data) {
    g_autoptr(GError) error;
    g_autoptr(GVariant) ret = 
        xdp_portal_open_file_finish(XdpQt::globalPortalObject(), result, &error);

    if (ret) {
        // Another convenient function that will get you uris and choices from 
        // GVariant returned by xdp_portal_open_file() call.
        XdpQt::FileChooserResult result = filechooserResultFromGVariant(ret);
        
        // Do whatever you want to do with the result. Here we just print opened selected files.
        qDebug() << result.uris;
    }
}

As you can see, no GVariant got hurt and you can easily open a file without any GVariant knowledge. Besides FileChooser portal helpers, we also have Notification portal helpers, because serializing icons and buttons is also something that is not trivial. For the rest of the portals you either don’t need to use complex GVariants so you can use them easily without helper functions same way as shown above, or some portals like ScreenCast or RemoteDesktop are not used that often and we don’t have helper functions for those just yet.

I hope you can find this helpful in case you want to join this world. The libportal project is hosted on GitHub in case you want to try it just now, because this is still not part of any stable release (will be in libportal 0.6), or report a bug or just look at my GVariant helpers to see what I spare you of.

Upcoming news in Plasma 5.16

- jgrulich 8 Comments

Plasma-nm

WireGuard support

We already had WireGuard support in Plasma 5.15, but it existed as a VPN plugin based on a NM WireGuard plugin, which wasn’t really working very well and didn’t utilize many of already existing NM properties. With release of NetworkManager 1.16, we have a new native support of WireGuard which is much more usable. It now exists as a new connection type so it’s implemented a bit differently compared to other VPNs. This mean that we had to implement first support for this connection type and its properties into NetworkManagerQt and implement an UI on top of that. The UI part of the new WireGuard support, same as the old VPN plugin, were implemented by Bruce Anderson. We are also probably (at this moment) the only one who provides an UI for WireGuard configuration so thank you Bruce for such a big contribution.

OTP support in Openconnect VPN plugin

Another big contribution, this time made by Enrique Melendez, is support for one time passwords in the Openconnect VPN plugin. This support was missing for some time so starting with Plasma 5.16, you should be able to use TOTP/HOTP/RSA/Yubikey tokens for your Openconnect connections.

PAN GlobalProtect VPN

OpenConnect 8.00 introduced support for PAN GlobalProtect VPN protocol. You can now see this new VPN type entry thanks to Alejandro Valdes.

Xdg-desktop-portal-kde

Remote desktop portal

Remote desktop portal brings possibility to control remotely your Wayland Plasma sessions. It utilizes screensharing portal to get the screen content and adds API for mouse/keyboard/touch control. Unfortunately at this moment only mouse support is implemented, mainly because I use KWayland::FakeInput protocol and mouse support is the only one currently implemented there. At this moment there is no Qt/KDE based application using remote desktop portal (or at least released one), but I have added support into Krfb, which is currently on review and I hope to get it merged for KDE Applications 19.08. Alternatively you can use gnome-remote-desktop.

Here is a short demo of remote desktop in action over VNC protocol. On the server side I’m running Krfb on Plasma wayland session and I control it from my second laptop using Krdc.

Integration of sandboxed Qt applications

- jgrulich 5 Comments

We have been using various tweaks to make sandboxed Qt apps well integrated into the system. For KDE Plasma integration, we have been allowing access to kdeglobals config file, where we store the most common configuration, like used icon theme, widget style, etc. A similar approach has been used by Gnome, where they need to allow access to DConf, otherwise applications will not be able to read default system configuration. These tweaks have been usually set in the runtimes and applications using these runtimes automatically inherited all the needed permissions during the build. This has some weak spots, because changing permissions in the runtime requires all applications to be rebuild to pick up the changes, or applications not using the runtimes at all had to allow all the access themself and really not everyone knows what everything needs to be enabled.

This will change with upcoming release of xdg-desktop-portal (version 1.2), which will bring new portal to solve this problem (for both Flatpak and Snap). There is new “Settings” portal, allowing apps to request various configuration from the sandbox, without need to have access outside (kdeglobals, dconf). For Gnome configuration, this has been built in directly in xdg-desktop-portal so there is no need for specific backend support. For KDE Plasma configuration, we have our specific code reading kdeglobals config file in xdg-desktop-portal-kde. This support has already been merged and will be part of Plasma 5.15 release in February. To make applications automatically ask for this configuration through the portal, instead of reading kdeglobals/dconf, I added support to both widely used Qt QPA plugins. For applications running under Plasma we have now this implemented in plasma-integration plugin. This support will be also released with Plasma 5.15 in february. For Qt apps running in Gnome, I added this support into QGnomePlatform, which has been released already some time ago and is already available in Flathub.

Hopefully with all of this released soon and more widely used, we can slowly start removing all the hardcoded permissions for both dconf and kdeglobals config file in the runtimes.

Flatpak support in KDevelop

- jgrulich Leave a comment

Recently I had a discussion with Carlos Soriano from our Red Hat desktop team about Flatpak support in KDevelop, he was told, when discussing Flatpak support in gnome-builder during KDE Akademy, that we already have support in KDevelop for flatpaks. I told him we really do, but that it’s more in the state of proof of concept and it’s probably not that easy to use it as in gnome-builder. We have this support since KDevelop 5.2, but it never made it to release notes and I guess not many people know about this. I only found some information about it in a blog post from Aleix Pol. I decided to give it a try, I actually already tried it once when I saw that blog post last year, but this time I would like to give a small how to and encourage you to try it and give some feedback to Aleix so we can improve this workflow.

Let’s start:

1. Open a project in KDevelop

This should be something you can build and run in Flatpak, which means usually an application. The easiest way is to open KDevelop, go to Project → Fetch project, and download your favourite application and open it as project.

2. Get flatpak manifest

Our plan for future is to distribute flatpak manifests together with applications in their repositories, currently we don’t do that so you have to either write your own, or go to our flatpak-kde-applications repository and get manifest for your application from there. Copy it to the root directory of your project. I think the name of the manifest needs to match your application appstream name, otherwise you will not be able to build it as flatpak.

3. Build flatpak

You can now right-click with your mouse on the application manifest and select “Build flatpak org.kde.AppName for x86_64” to build current manifest. I assume you have needed runtime and sdk installed, if not, you can get them from Flathub. If for example you see your app has runtime-version: 5.11 in the manifest, then run flatpak install flathub org.kde.Platform 5.11 and flatpak install flathub org.kde.Sdk 5.11.

This will build the app as specified in the manifest, still your modifications, if you made any to the application, will not be applied yet.

4. Use flatpak runtime

If you built your application successfuly in the previous step, you can now switch the app to be build under Flatpak runtime. This is either in the menu under Run → Runtime or it should be also accessible from the toolbar.

If you switch to Flatpak runtime, you will get a dialog to configure a build directory. Select a different build directory, for example to $HOME/path/to/project/build-flatpak and set installation prefix to /app, which is where applications are installed under flatpak.

5. Final build

If you now click to build your application, you will see it runs flatpak build command to build your application. To launch it, you need to configure a launcher to use binaries from build-flatpak folder. If you are in the flatpak runtime, then it will automatically start your application with flatpak run command.

6. Benefits

You might be asking why anything like this is useful or why such integration has been made. There are few reasons for that.

  • Reproducible builds: this means that if you build your app + your change for example with KDE Runtime based on Qt 5.11, anyone else will be able to build it against same runtime and your new feature or fix should behave identicaly.
  • Usage of different libraries: you might be running latest Qt, but someone reports you that your application is crashing using older version of Qt. You definitely don’t want to build older Qt and install it to a prefix and make your application use it, just to fix a bug you cannot reproduce. With this KDevelop integration, it’s just a matter of changing runtime version in the application manifest.
  • Easy installation of build environment: for people who are new to all of this, it is definitely easier to install everything with just one basic flatpak command. You need to usually just run flatpak install flathub org.kde.[Platform, Sdk] 5.11. This will install everything you need to build every KDE application and you don’t need to mess with your system libraries.

This is kcalc running on KDE Runtime 5.9, while my system is on Qt 5.11.1.

7. Provide feedback

If you try this and have some suggestions for improvements, please share them with Aleix Pol, this is in my opinion something worth improving and helpful for beginners. You can also consider improving it yourself, you should be even able to do that from KDevelop running in flatpak, as flatpak can also run flatpaks inside.

How to enable and use screen sharing on Wayland

- jgrulich 16 Comments

Two days ago I wrote about our work on screen sharing in web browsers. While there was a lot of work done recently on this area, it’s not still in the state where everything would just work out of the box. There are few steps necessary to make this work for you and here is a brief summary what you need. This is not a distro specific how to, but given I use Fedora 28 and I know that everything you need is there, it’s most likely you will need to figure out the differences for your distribution or build it yourself.

PipeWire

PipeWire is the core technology used behind all of this. In Fedora you just need to install it, it’s available for Fedora 27 and newer. Once PipeWire is installed, you can just start it using “pipewire” command. If you want to see what’s going on, you can use “PIPEWIRE_DEBUG=4 pipewire”  to start PipeWire with debug information. For Fedora 29, there is a feature planned for PipeWire which should make it to start automatically.

Xdg-desktop-portal and xdg-desktop-portal-[kde,gtk]

We use xdg-desktop-portal (+ backend implementation) for communication between the app requesting to share a screen and between desktop (Plasma or Gnome). You need xdg-desktop-portal, which is the middle man between the app and backend implementation, compiled with screencast portal. This portal will be build automatically when PipeWire is present during the build. In Fedora you should be already covered when you install it. For backend implementation, if you are using Plasma, you need xdg-desktop-portal-kde from Plasma 5.13.x, again compiled with screencast portal, which is build when PipeWire is present. For Fedora 28+, you can use this COPR repository and you are ready to go. I highly recommend using Plasma 5.13.2, where I have some minor fixes and if you have a chance, try to compile upcoming 5.13.3 version from git (Plasma/5.13 branch), as I rewrote how we connect to PipeWire. Previously our portal implementation worked only when PipeWire was started first, now it shouldn’t matter. If you use Gnome, you can just install xdg-desktop-portal-gtk from Fedora repository or build it yourself. You again need to build screencast portal.

Enabling screen sharing in your desktop

Both Plasma and Gnome need some adjustments to enable screen sharing, as in both cases it’s an experimental feature. For Gnome you can follow this guide, just enable screen-cast feature using gsettings. For Plasma, you need to get KWin from Plasma 5.13.x, which is available for Fedora in the COPR repository mentioned above. Then you need to set and export KWIN_REMOTE=1 env variable before KWin starts. There is also one more thing needed for Gnome at this moment, you need to backport this patch to Mutter, otherwise it won’t be able to match PipeWire stream configuration with the app using different framerate, e.g. when using Firefox.

Edit: It seems that exporting KWIN_REMOTE=1 is not necessary, it probably was only during the time when this feature was not merged yet. Now it should work without it. You still need KWin from Plasma 5.13.

Start with screen sharing

Now you should be all set and ready to share a screen on Gnome/Plasma Wayland session. You can now try Firefox for Fedora 28 or Rawhide from this COPR repository. For Firefox there is a WebRTC test page, where you can test this screen share functionality. Another option is to use my  test application for Flatpak portals or use gnome-remote-desktop app.

Edit: I didn’t realize that not everyone knows about xdg-desktop-portal or PipeWire, below are some links where you can get an idea what is everything about. I should also mention that while xdg-desktop-portals is primarily designed for flatpak, its usage has been expanded over time as it perfectly makes sense to use it for e.g. Wayland, where like in sandbox, where apps don’t have access to your system, on Wayland apps don’t know about other apps or windows and communication can by done only through compositor.

 

Screen sharing in Plasma wayland session

- jgrulich 14 Comments

One of the important missing features in Plasma wayland session is without a doubt possibility to share your screen or record you screen. To support this you need help of the compositor and somehow deliver all needed information to the client (application), in ideal way something what can be used by all DEs, such as Gnome. Luckily, this has been one of the primary goals of Pipewire, together with support for Flatpak. If you haven’t heard about Pipewire, it’s a new project that wants to improve audio and video handling in Linux, supporting all the usecases handled by PulseAudio and providing same level of handling for video input and output. With Pipewire supporting this, there was recently a new API added to xdg-desktop-portal for screen cast support and also for remote desktop. Using this API, applications can now have access to your screen content on Wayland sessions or in case they are running in sandbox. With various backend implementation, like xdg-desktop-portal-kde or xdg-desktop-portal-gtk, they just need to support one API to target all desktops. Screen cast portal works the way, that the client first needs to create a session between him and xdp (xdg-desktop-portal) backend implementation, user then gets a dialog with a screen he would like to share and starts screen sharing. Once he does that, xdp backend implementation creates a Pipewire stream, sends back response to the client with stream id and then client can connect to that stream and get its content. Once he no longer requests content of the selected stream, xdp backend implementation gets information that nobody is longer connected to the created Pipewire stream and can stop sharing screen information and xdp backend implementation is again ready to accept next requests for screen sharing. This is all happening in the background so there is really no cool picture I can show, at least this dialog which you get when you request to share a screen.

I finished support for screen cast portal in xdg-desktop-portal-kde last week and currently waiting for it to pass review and be merged to master. This is also currently blocked by two not merged reviews, one adding support for sending GBM buffers from KWin and one with new Remote Access Manager interface in KWayland, both authored by Oleg Chernovskiy, for which I’m really greatful. This all will hopefully land soon enough for Plasma 5.13. Testing this is currently a bit complicated as you need everything compiled yourself and besides my testing application there is really no app using this, except maybe Gnome remote desktop, but there should be support in future for this in Krfb, Chrome or in Firefox. Hopefully soon enough.

Last thing I would like to mention is for GSoC students. We also need remote desktop portal support to have full remote desktop experience so I decided to propose this as a GSoC idea so students can choose this interesting stuff as their GSoC work.

Gnome integration for Qt based applications in Flatpak

- jgrulich 5 Comments

Following blog post from Patrick Griffis about new themes support in Flatpak, we started working on supporting this new feature too. Currently wherever you start a Qt application, it would always look like a KDE application or something would be missing, like icons so you would end up with bad experience and mixed feelings. This is going to change now as we now support Gnome in form of icons, widget style and Qt platform theme and with this, when you run a Qt application in Gnome, it will look definitely better and more natively than before. We packaged regular adwaita icons which are used by default in Gnome as extension of freedesktop runtime. For widget style we use adwaita-qt style, which is a Qt style attempting to look like Gtk’s adwaita and the most important part putting this all together is QGnomePlatform, a Qt platform theme which reads your Gnome configuration and applies it to running Qt applications. QGnomePlatform also enforces Qt apps to use adwaita icons and adwaita-qt style by default so that’s another reason why it is important. Both adwaita-qt and QGnomePlatform projects are by the way authored by Martin Bříza, a collegue of mine from Red Hat so if you meet him in person somewhere buy him a beer for that he cares about Qt integration in Gnome :). Now coming to a question how to install this and make it work. Basically all you need to do is install following extensions and you shold be done:

flatpak install kderuntime org.freedesktop.Platform.Icontheme.Adwaita
flatpak install kderuntime org.kde.KStyle.Adwaita
flatpak install kderuntime org.kde.PlatformTheme.QGnomePlatform

Your Qt apps running in flatpak should then automatically pick up all of these extensions without any further modification, same way it does automatically when you run it outside the sandbox. Simply done!. I’m also aware that there are more Gtk themes, like adwaita-dark or high-contrast, both are also available in form of Qt style and we will probably package them later, but at this point it is mostly proof of concept that this can be done and works nicely. You can follow our wiki page if you want more information about runtimes, repository with applications and so on and from me it’s all for now.

Btw. below you can see okular running in flatpak and using adwaita-qt style with adwaita icons.

Telegram desktop client for flatpak #3

- jgrulich 4 Comments

I have been working lately on fixing issues we had with telegram when using Qt’s flatpak platform plugin to have portals support. This was all crashing due to system tray. Qt tries to fallback to xembed when platform theme doesn’t provide any system tray implementation. Unfortunately Qt assumes that we are using xcb platform plugin (used everywhere by default) and tried to call some functions on it, but unfortunately we were using flatpak platform plugin which loads xcb only internally and because of that it was crashing. To solve that I had to implement my own xembed support into our flatpak platform plugin without using xcb specific functions. This was all happening only on Gnome, because in KDE our platform theme has it’s own implementation of system tray using SNI and xembed is not used there at all. With all those fixes I decided to make telegram to finally use flatpak platform plugin by default.

What is also new is that I created one more branch with alpha releases. Right now I have master branch with latest stable telegram in version 1.0.29 and devel branch with latest alpha release 1.0.37 bringing support for calling.

You can get it the same way as before, following instructions from previous blog post, except that now you have to specify branch you want to install.

Discover: Open desktop ratings

- jgrulich 3 Comments

As I’m trying to keep improving the flatpak backend in discover I decided to add support for reviews. To do so I implemented support for GNOME’s Open Desktop Ratings which is rating/review system used by gnome-software. Result of this is now fully functional review system, where you can read user comments and ratings and submit your own reviews. We also use same mechanism as in gnome-software for generating user_hash which identifies you in odrs server and given that you are able to modify/delete your reviews from both discover and gnome-software (note that discover doesn’t support this yet). You can also vote for already existing reviews so others get feedback on how useful each review is. We also decided to use same review system in our PackageKit backend and replace current Ubuntu Popularity Contest system so not only flatpak users will benefit from this. During testing of this review support we’ve hit many UI issues related to review system causing users not to be able see reviews or write new ones which were introduced during transition to kirigami. We fixed all of them and you can look forward to improved experience in the upcoming discover release. To improve this further, we or at least I, would like to also add a new widget showing current total app ratings as of now you can only see reviews with comments only, not overall app rating, but this needs some discussion and design consideration.

Here are some screenshots to prove that this is already working:

If you want to test it, which we would like you to do, you can just compile discover from master branch (with -DBUILD_FlatpakBackend=ON cmake parameter for flatpak support). That’s all from me for now. Have a nice weekend :).

Scroll To Top