Developer Announcement - Qt 5.15 available for app developer testing


Over the past few weeks, myself and @rinigus had the idea to build and make available Qt 5.15 to other developers on SailfishOS.
This is not some magical rebuild of the operating system using a newer Qt version, but instead, packaging and making available Qt 5.15.8
as an alternate set of APIs available to application developers. The new Qt build installs in /opt/qt5 and it is possible to use in parallel
with the default system Qt 5.6.

Why have we done this

It started as a fun experiment to see if it was even possible, as SailfishOS is currenty stuck at Qt 5.6, and there are many improvements
in newer releases, and newer APIs available. Due to licensing issues, Jolla has been unable (so far) to update the Qt release, and we think
this avoids that issue by shipping newer a Qt as a community effort.

What is availabale

We hope to bring many Qt modules to SailfishOS, and KDE frameworks including Kirigami. The following modules are currently available:

  • qtbase
  • qt3d
  • qtconnectivity
  • qtdatavis3d
  • qtdeclarative
  • qtgraphicaleffects
  • qtgamepad
  • qtimageformats
  • qtlocation
  • qtmultimedia
  • qtnetworkauth
  • qtquickcontrols
  • qtquickcontrols2
  • qtsvg
  • qtsensors
  • qttools
  • qtvirtualkeyboard
  • qtwayland
  • qtwebchannel
  • qtwebsocket
  • qtxmlpatterns
  • kirigami2 5.104

What not to expect

Do not expect this to integrate nicely with the Qt 5.6 Silica components and the SailfishOS operating system, it is basically entirely seperate.

Why should I use this

We think the use case for this is to bring exisiting applications based on the likes of qtquickcontrols2, kirigami, plasma etc to users of SailfishOS.
You can also certainly use it to develop new SailfishOS and Linux applications, with the caveats described above around integration.

This sounds amazing, how do I use it

All packages are currently in one obscure OBS repository [1] so you can just install them from there. We have names packaged with the opt-qt5 prefix to not interfere
with existing packages, and are taking care that they will not interfere with system packages or interfere minimally. After we resolve any packaging issues, the intention is to make this available via SailfishOS:Chum.
There is a GettingStarted guide on the wiki, with a sample project, see [2]

What issues will I see

Right now, the libraries in /opt/qt5 will advertise their provided libraries via RPM provides facility. This will have to be fixed before wider usage by users.

The new QtWayland would prefer to use xdg-shell, which isnt available in the SailfishOS compositor Lipstick. This causes issues like dissapearing windows
when minimized, and the zoom levels are very much too small. To fix this, @rinigus has repurposed Flatpak wrapper application into “qt-runner” which application developers
can include as a dependency, and use it to launch the application.

Finally, it looks like Qt 5.15 at /opt is pushing SDK to the limits with the frequent and reproducible failures in builds on either one or all architectures. Failures usually
involve creation of files with weird permissions or the whole directories changing them. So, it could that building apps could be more complicated in this case.

How can I help?

As a developer, you can install, use and experiment with the new Qt version and provide feedback. You can develop against them and try all the things we havn’t yet been able to. Please leave feedback in this thread or via IRC in #SailfishOS.

Issues can be reported at GitHub - sailfishos-chum/qt5: Qt5 meta package for Sailfish OS and the PRs submitted against the packages in SailfishOS:Chum community · GitHub

[1] Show home:rinigus:qt515:packaging - SailfishOS Open Build Service
[2] Getting Started · sailfishos-chum/qt5 Wiki · GitHub


This is great news! Could you elaborate why you decided to go for Qt 5.15 instead of Qt 6?

  1. so its not such a radical jump, meaning increased chance of success
  2. some backends we use have been dropped from qt6, eg, geoclue, so with qt6 there would be no location support

this doesnt mean we couldnt add qt6 using the same method in the future though.


Just out of curiosity: How is geolocation been done in Qt6 then?

also qtsensors sensorfw backend isnt ported to qt6, so that means sensors wouldnt work either.

1 Like

Thanks so much guys! I will definitely going to open up a beer at the evening to celebrate this!

1 Like

That’s great! I’ve always heard that sfos has old Qt, this sounds promising :+1::+1:


Really great news. I would like to donate something, could you add a link into the readme? :slight_smile:

Any pointers on how one might do that?
I have an idea for a trivial app that could use this.

Any chances of a minimal example forked from the sample/skeleton app?

1 Like

@attah If you add @rinigus’s repo to your build environment and install the opt-qt5-*devel pacakges you should be good to go using just a plain QQc2 app template or such from any modern qt creator. For testing things, i made a template app and compiled it on-device


I think you can easily make RPM as well. Just take one of simpler SPECs on our repos and look at used macros.

CMake example: GitHub - sailfishos-chum/qt-sfos-maliit-platforminputcontext

QMake example: qtconnectivity/qtconnectivity.spec at main · sailfishos-chum/qtconnectivity · GitHub


I don think thats really necessary, especially as this is a team effort.

Is it possible to use one of them as drop in from qml? To for example use newer qtlocation to get currently obtainable here api keys working?

I was just asking myself the same thing. @rinigus replied that cherry picking isn’t going to work, but I’m not sure if it can’t be done for stuff like the geoservices plugins. But generally, you’re stuck with the whole of that qt version. Still, loading libraries from arbitrary locations should be possible :wink:

1 Like

Is this something that can be used in store apps or only for stuff in chum?

The compositor remains SFOSs biggest issue. :neutral_face:

1 Like

I would think its Chum only.

1 Like

Created a developer quick start guide and sample project

@attah ^^


I was trying to remember how it’s done, and one way that would ‘probably’ work for the ‘plugins’, like geoservices osm’, is this old gem: The Solution

However, there’s enough glue to be made that it almost makes more sense to just create a new plugin and deploy it with the app. I’m going to see if I can finally get this done to at least be able to use OSM maps in QML.


With Qt 5.15 available, we could also work on … compositor. Probably several options are there. Fro starters, you can probably run it inside qt-runner. So, you would get compositor-in-compositor kind of solution. Later, you could maybe invert situation and run some other compositor as the main one. So, all in all, it allows you to experiment with this as well.


KDE Kirigami is still using 5.15. They are porting to Qt 6, so it may change soon. In addition to all arguments above cited by @piggz, we have gcc that got old for Qt 6: Supported Platforms | Qt 6.4