Qt World Summit 2025

These past two days I attended the Qt World Summit 2025

It happened in Munich in the SHOWPALAST MÜNCHEN. The venue is HUGE,  we had around 800 attendees (unofficial sources, don't trust the number too much) and it felt it could hold more. One slightly unfortunate thing is that it was a bit cold (temperatures in Munich these two days were well below the average for May) and quite some parts of the venue are outdoors, but you can't control the weather, so not much to "fix" here.

 

The venue is somewhat strangely focused on horses, but that's nothing more than an interesting quirk.

Qt World Summit is an event for the Qt developers around the world and the talks range from showcases of Qt in different products, to technical talks about how to improve performance along others less Qt centric talks about how to collaborate with other developers or about "modern C++".

As KDE we participated in the event with a stand trying to explain people what we do (David Redondo and Nicolas Fella were more in the stand than me, kudos to them)

For following years we may need to re-think a bit better our story for this event since I feel that "we do a Linux desktop and Free Software applications using Qt" is not really what Qt developers really care about, we maybe should focus more on "You can learn Qt in KDE, join us!" and "We have lots Free [Software] Qt libraries you can use!".

 

Talks for the videos will be published "soon" (or so I've been told). When that happens the ones I recommend you to watch are "Navigating Code Collaboration" by  LAURA SAVINO, "QML Bindings in Qt6" by ULF HERMANN and "C++ as a 21st Century Language" by BJARNE STROUSTRUP, but the agenda was packed with talks so make sure to check the videos since probably your tastes and mine don't 100% align.

 

All in all it was a great event, it is good to see that Qt is doing well since we use it for the base of almost everything we do in KDE. Thanks to The Qt Company and the rest of the sponsors for organizing it. 

 

 

The KDE Qt5 Patch Collection has been rebased on top of Qt 5.15.4

Commit: https://invent.kde.org/qt/qt/qt5/-/commit/5c85338da3c272587c0ec804c7565db57729fd48

 

Commercial release announcement: https://www.qt.io/blog/commercial-lts-qt-5.15.4-released 

OpenSource release announcement: https://lists.qt-project.org/pipermail/development/2022-May/042437.html

 

I want to personally extend my gratitude to the Commercial users of Qt for beta testing Qt 5.15.4 for the rest of us.

 

The Commercial Qt 5.15.4 release introduced some bugs that have later been fixed. Thanks to that, our Patchset Collection has been able to incorporate the reverts for those two bugs that affected Android and Windows and the Free Software users will never be affected by those!

How i ended up fixing a "not a bug" in Qt Quick that made apostrophes not being rendered while reviewing an Okular patch

But in Okular we don't use Qt Quick you'll say!

Well, we actually use Qt Quick in the mobile interface of Okular, but you're right, this was not a patch for the mobile version, so "But in Okular we don't use Qt Quick!"

 

The story goes like this.

I was reviewing https://invent.kde.org/graphics/okular/-/merge_requests/431 and was not super convinced of the look and feel of it, so Nate gave some examples and one example was "the sidebar in Elisa".

 

So I started Elisa and saw this

You probably don't speak Catalan so don't see that lesquerra is a mistake it should be l'esquerra. 

 

Oh the translators made a mistake i thought, so i went to the .po file https://websvn.kde.org/trunk/l10n-kf5/ca/messages/elisa/elisa.po?view=markup#l638 and oh surprise! the translators had not made a mistake (well not really a surprise since they're really good).

Ok, so what's wrong then?

I had a look at the .qml code https://invent.kde.org/multimedia/elisa/-/blob/release/21.04/src/qml/MediaPlayListView.qml#L333 and it really looked simple enough.

 

I had never seen a Kirigami.PlaceholderMessage before but looking at it, well the text ended up in a Kirigami.Heading and then in a QtQuick Label. Nothing really special.

Weeeeeeird.

Ok i said, let's replace the the whole xi18nc in there with the translated text and run elisa. And then i could see the ' properly.

Hmmmm, ok then the problem had to be xi18nc right? Well it was and it was not.

The problem is that xi18nc translates ' to ' to be more "html compliant" https://invent.kde.org/frameworks/ki18n/-/blob/master/src/kuitmarkup.cpp#L40

 

And unfortunately Qt Declarative 5.15 Text item default "html support" is something Qt calls "Styled Text" that only supports five HTML entities, and apos is not one of them https://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/quick/util/qquickstyledtext.cpp?h=5.15.2#n558

 

So where is the bug?

 

The Text documentation clearly states that ' is in the list of supported entities.

One could say the bug is that every time we use xi18nc in a Text we should remember to change the "html support" to something Qt calls "RichText" that actually supports '.

But we all know that's never going to happen :D, and in this case it would actually be hard since Kirigami.PlaceholderMessage doesn't even expose the format property of the inner text

So I convinced our friends at Qt that only supporting five entities is not great and now we support six ^_^ in Qt 6.2, 6.1 and 5.15 (if you use the KDE Qt patch collection) https://invent.kde.org/qt/qt/qtdeclarative/-/merge_requests/3/diffs

P.S: I have a patch in the works to support all HTML entities in StyledText but somehow it's breaking the tests, so well, need to work more on it :)

The Qt Company is stopping Qt LTS releases. We (KDE) are going to be fine :)

Obvious disclaimer, this is my opinion, not KDE's, not my employer's, not my parents', only mine ;)

Big news today is that Qt Long-term-supported (LTS) releases and the offline installer will become available to commercial licensees only.

Ignoring upcoming switch to Qt6 scenario for now, how bad is that for us?

Let's look at some numbers from our friends at repology.

At this point we have 2 Qt LTS going on, Qt 5.9 (5.9.9 since December) and Qt 5.12 (5.12.6 since November).

How many distros ship Qt 5.9.9? 0. (there's macports and slackbuilds but none of those seem to provide Plasma packages, so I'm ignoring them)

How many distros ship Qt 5.12.6? 5, Adélie Linux, Fedora 30, Mageia 7, OpenSuse Leap 15.2, PCLinux OS (ALT Linux and GNU Guix also do but they don't seem to ship Plasma). Those are some bigger names (I'd say specially Fedora and OpenSuse).

On the other hand Fedora 28 and 29 ship some 5.12.x version but have not updated to 5.12.6, Opensuse Leap 15.1 has a similar issue, it's stuck on 5.9.7 and did not update to 5.9.9 and so is Mageia 6 which is stuck on Qt 5.9.4

Ubuntu 19.04, 19.08 and 20.04 all ship some version of Qt 5.12 (LTS) but not the lastest version.

On the other a few of other "big" distros don't ship Qt LTS, Arch and Gentoo ship 5.14, our not-distro-distro Neon is on 5.13 and so is flatpak.

As I see it, the numbers say that while it's true that some distros are shipping the latest LTS release, it's not all of them by far, and it looks more like an opportunistic use, the LTS branch is followed for a while in the last release of the distro, but the previous ones get abandoned at some point, so the LTS doesn't really seem to be used to its fully potential.

What would happen if there was no Qt LTS?

Hard to say, but I think some of the "newer" distros would actually be shipping Qt 5.13 or 5.14, and in my book that's a good thing, moving users forward is always good.

The "already released" distros is different story, since they would obviously not be updating from Qt 5.9 to 5.14, but as we've seen it seems that most of the times they don't really follow the Qt LTS releases to its full extent either.

So all in all, I'm going to say not having Qt LTS releases is not that bad for KDE, we've lived for that for a long time (remember there has only been 4 Qt LTS, 4.8, 5.6, 5.9 and 5.12) so we'll do mostly fine.

But What about Qt 5.15 and Qt 6 you ask!

Yes, this may actually be a problem, if all goes to plan Qt 5.15 will be released in May and Qt 6.0 in November, that means we will likely get up to Qt 5.15.2 or 5.15.3 and then that's it, we're moving to Qt 6.0

Obviously KDE will have to move to Qt 6 at some point, but that's going to take a while (as example Plasma 5 was released when Qt was at 5.3) so for let's say that for a year or two we will still be using Qt 5.15 without any bugfix releases.

That can be OK if Qt 5.15 ends being a good release or a problem if it's a bit buggy. If it's buggy, well then we'll have to figure out what to do, and it'll probably involve some kind of fork somewhere, be it by KDE (qt already had that for a while in ancient history with qt-copy) or by some other trusted source, but let's hope it doesn't get to that, since it would mean that there's two set of people fixing bugs in Qt 5.15, The Qt Company engineers and the rest of the world, and doing the same work twice is not smart.

Beware of some of the Qt 5.13 deprecation porting hints

QComboBox::currentIndexChanged(QString) used to have (i.e. in Qt 5.13.0) a deprecation warning that said "Use currentTextChanged() instead".

That has recently been reverted since both are not totally equivalent, sure, you can probably "port" from one to the other, but the "use" wording to me seems like a "this is the same" and they are not.

Another one of those is QPainter::initFrom, which inits a painter with the pen, background and font to the same as the given widget. This is deprecated, because it's probably wrong ("what is the pen of a widget?") but the deprecation warning says "Use begin(QPaintDevice*)" but again if you look at the implementation, they don't really do the same. Still need to find time to complain to the Qt developers and get it fixed.

Anyhow, as usual, when porting make sure you do a correct port and not just blind changes.

Qt Contributor Summit 2018

About two weeks ago i attended Qt Contributor Summit 2018, i did so wearing my KDAB hat, but given that KDE software is based heavily on Qt I think I'll give a quick summary of the most important topic that was handled at the Summit: Qt 6

• Qt 6 is planned for a November 2020 release
• Qt 5 releases will continue with the current cadence as of now with 5.15 being the last release (and also LTS)
• The work branch for Qt 6 will be branched soon after Qt 5.12
• Qt 6 has to be easy to migrate from Qt 5
• Qt 6 will use C++17
• Everything to be removed in Qt 6 should be marked as deprecated in 5.15 (ideally sooner)
• What can be done in Qt 5 should be done to Qt 5
• Qt 6 should be a "boring" release user feature wise, mostly cleanup and preparing for the future
• Qt 6 should change things that break at compile time, those are easy to fix, silent runtime changes are scarier
• Qt 6 will not use qmake as build system
• The build system for Qt 6 is still not decided, but there's people working on a qbs build and noone working on any other alternative

On a community related note, Tero Kojo the Community Manager for The Qt Company is leaving and doesn't seem a replacement is on sight

Of course, note that these are all plans, and as such they may be outdated already since the last 10 days :D

How to check if your touch screen is really sending touch events

I've had this problem twice in the last year, I'm testing something related to touch in my laptop and I'm stuck trying to figure out if it's my code that is wrong or if my screen is misconfigured and it's only sending mouse events.

Thanks to Shawn of Qt fame for having helped me the two times and explained me how to test if my screen is sending touch events, I'm writing this blog so i don't forget and ask him a third time :D

First step is figuring out the xinput id of the touch screen of my laptop

tsdgeos@yoga:~:$ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Wacom Co.,Ltd. Pen and multitouch sensor Finger id=9 [slave pointer (2)]
⎜ ↳ ETPS/2 Elantech TrackPoint id=13 [slave pointer (2)]
⎜ ↳ ETPS/2 Elantech Touchpad id=14 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Sleep Button id=8 [slave keyboard (3)]
↳ Wacom Co.,Ltd. Pen and multitouch sensor Pen id=10 [slave keyboard (3)]
↳ Integrated Camera id=11 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=12 [slave keyboard (3)]
↳ ThinkPad Extra Buttons id=15 [slave keyboard (3)]
↳ Video Bus id=7 [slave keyboard (3)]

In this case would be id=9

Then you can do

tsdgeos@yoga:~:$ xinput test-xi2 9

and if the output contains RawTouchBegin and RawTouchEnd events, it means that the screen is correctly sending touch events :)

Next you probably want to check if Qt actually is seeing those events, for that there's a few ready to use demos in the qtdeclarative source code, so I would do

tsdgeos@yoga:~:$ qml qt5/qtdeclarative_58/examples/quick/touchinteraction/multipointtouch/multiflame.qml

And after putting my five fingers on the screen I would see

So all is good, the bug is my code and not in Qt or the configuration of my touch screen :D

Qt 5.4 QML -> C++ QVariant issues

I usually don't blog about what I do in my day-time job in my personal blog but since this may affect some of the KDE/Qt developers I will do this time.

Qt 5.4 was released three months ago; at Canonical we're starting to move the Ubuntu Pĥone codebase to it now and it has an important behavior change as noted in it's changes file (that is quite hard to find by the way, it took me like 5 minutes to find, and that's knowing it existed, searching for "qt 5.4 changelog" does not return http://qt-project.org/wiki/Change-files-in-Qt-5.4.0 that is the important page) that has affected us in many places

The important behavior change is that now some QVariants will be passed to C++ as QJSValue-QVariants instead of QStringList-QVariants, QMap-QVariants, etc so if your code did things like checking the variant type now it will fail, so basically for any C++ function that receives QVariants from QML you need to add extra code to unbox the QVariant, i.e.

void MyClass::myFunction(QVariant v)
{
    // unbox the QVariant-QJSValue
    if (v.userType() == qMetaTypeId<QJSValue>()) {
        v = v.value<QJSValue>().toVariant();
    }
    // This is your old code that checks the type
    // of the QVariant is a valid one
    if (v.type() != QVariant::Map &&
        v.type() != QVariant::List &&
        v.type() != QVariant::StringList) {
        qWarning() << "Bad param" << v;
        return;
    }
    // From here your old code that does things
}

Unit testing KColorButton

Around two weeks ago, a bug about was reported in which Okular crashed when changing the color of highlighted text. After a bit of debugging i found that the bug was actually in kdelibs in the KColorButton class.

This is a class I had never looked internally so it was a bit hard to decide where to start looking for a fix. Then I decided to look at the git log and realized the last commit introduced by a fix for color selection not working correctly on double click.

I took my chances and saw that reverting that patch actually removed the crash, so now I knew where to look :-)

After a few minutes looking at the code i came up with a 3-line patch that fixed the crash and still made double click work correctly. I'm so awesome \o/

But that wasn't enough, I needed to *prove* I had fixed it, so i decided to create some tests, that was a bit harder since it involved "clicking" in buttons and stuff, but QTest to the rescue and a few hours later I had this nice unit test that will warn us if that breaks again :-)

So next time you fix a bug, unit test it! And don't complain it's graphical, that's no excuse!

And of course the tests run just fine in build.kde.org even if they show buttons/dialogs :-)

Qt Contributor Summit 2012

So here I am sitting on the lounge of the Qt Contributor Summit listening to jlayt-highschool-time music and doing two simple qtbase patches. I have to say that it's been a nice two days of technical discussion, here my highlights:
 * RIM are shipping full Qt libraries for BlackBerry 10 and next unreleased/unannunced QNX release
 * At last it is clear that QML Components are a pressing need and there were like 4 different talks/bofs/panels about it
 * There's lots of random huge companies using Qt, from HP in plotters to Scania on cranes, so the future is bright :-)
* People at Nokia/Qt are worried about their future but no one really knows anything set on stone so all you get is fear cropping up
And now some pictures
https://twitter.com/tsdgeos/status/215727012717924352/photo/1
https://twitter.com/tsdgeos/status/216176177910530050/photo/1
https://twitter.com/tsdgeos/status/216176177910530050/photo/1

Sad story of the day: Qt and XF86XK_TouchpadToggle

Today I realized Gnome has support for XF86XK_TouchpadToggle, i.e. if you press the key in your keyboard that has the touchpad with an X symbol over it, it toggles the enabled state of the touchpad.

This is very useful if you are like me and attach/detach a mouse various times during the day.

Since as far as I know this is not supported in KDE, this afternoon I decided to write a quick kded module that would listen to XF86XK_TouchpadToggle and call the corresponding XInput2 functions to toggle the state of the touchpad.

Investigating XInput2 was supposed to be the difficult part since it is out of my area of comfort, but at the end it resulted it was not that difficult and the desired effect can be achieved with no more than 10 lines of code.

After getting the correct XInput2 calls I started to build the skeleton of my kded module and when I was going to register the global KAction to listen for XF86XK_TouchpadToggle I realized Qt does not have support for this key, which means I can not use a KAction for that. Sad :-/

This has resulted in my getting diverted from my original goal and writing a patch for Qt5 to support the XF86XK_TouchpadToggle key and two other ones. Sadly this does not solve my immediate itch so I will either live with that itch or try to detect the keypress at the X level, but i'm not sure that's something I want to do :D

Update: I went the X11 way and it was not that painful. I now have some code that works, putting it in a git repo as soon as I get one :-)

Cross thread signal delivery fixed!

At work we've been chasing for a long time a problem in which thread T1 emitted signal S1 and then signal S2 connected to an object in thread T2 but they were received in that object in the reverse order, that is, S2 first and S1 later.

First we though it was our fault since the code in those classes is not as clean as it should be, but after days we could not find anything specially wrong in our code so started looking down to Qt.

Just after one day I was able to locate a problem in QObject::moveToThread that did not keep the entries in QPostEventList properly sorted and was able to produce a quick patch to fix our issue. Unfortunately it has taken around one month for that patch to hit upstream (no idea if it stalled in my company, digia or nokia) and the bug being fixed by Olivier (with a patch better than mine).

Bottom line: If you can not find the bug in your code it's maybe because it's not there :D

N9 disappointment

It seems the default applications will be closed source, so yeah, looks cool, uses Qt and bla bla bla, but still not a real Free Software phone as they sold it to us.

Of course I'd be more than happy to be proven wrong.

Qt Designer texts: disambiguation vs comment

Qt Designer has two fields regarding translations for text properties (e.g. the text of a Label, or the tool tip of a Widget) disambiguation and comment (that unfortunately map to the comment (for disambiguation) and extracomment (for comment) XML attributes in the .ui file), let me give a bit of explanation of what they mean since I've found some errors on it's usage while fixing a bug we had in our translation scripts (aka scripty). First some background on how translation works, when you ask for a string to be translated (e.g. "Run") you can give some context that acts as an extra key (e.g. "Verb" or "Noun") so translators can do different translations (Run, Verb) -> Ejecutar (Run, Noun) -> Ejecución This extra key is what you write in the disambiguation field On the other hand when you write something in the comment field, it only appears as a comment to the translator, so if you have two texts with the same text (e.g. "Run") and different comments (e.g. "Verb" or "Noun") it will not work, so only use the comment field to give extra information for fields whose text is unique but the meaning might not be easy to understand to the translator. So there is no reason at all to do things like <string extracomment="General information">General information of the identity.</string> since you are giving less information in the comment field than in the text itself Also just remember it makes no sense to add disambiguation or comment to a text property that is empty since at the moment we can not translate empty strings, so things like this are also not useful at all <string extracomment="Open file dialog"/> Finally if you use KUIT markers they need to be in the disambiguation field

Qt, gitorious, merge requests and Open Source

Begin of rant

Some time ago Qt/Nokia decided to open their repos (great! even if they are not the real repos) and also decided to start accepting contributions from non Qt/Nokia employees in a way that they will make you the favour of accepting your code for free without making you fax things and talk with lawyers (you still have to grant them a perpetual license to do whatever they want with your code).

The fact that you have to grant them a perpetual license to do whatever they want with your code was the reason i decided myself not to contribute to Qt.

But the flesh is weak and i actually found something that i though would be nice to have and was actually easy to implement. So i went ahead and did it (http://qt.gitorious.org/qt/qt/merge_requests/814) seven weeks ago.

Since then my merge request has received exactly two comments. One from a non Qt/Nokia employee saying "Looks good to me (and useful!)" and one from a Qt/Nokia employee saying "Your indentation is wrong" (which i think is not but that's unrelated).

And that's it.

I know phones don't have a need for QHeaderViews, but Qt/Nokia could pretend they still are supporting the desktop (which is what brought them to the position they are) and if they get a patch from a reasonably known community member that gets acked by a well known community member have the decency of following up the patch.

End of rant.

Nokia Certified Qt Developer

So i just got a mail saying i'm now a Nokia Certified Qt Developer. Great!

Beware of QDomElement::setAttribute with floats and doubles

QDomElement::setAttribute with floats and doubles formats the numbers according to the current locale as specified by the documentation and this is for sure going to bite you. It did for us in Okular where people lost annotations when moving from one computer to another since the user was using a , locale in one of them and a . locale in other.

So if you use QDomElement::setAttribute with floats and doubles just add QString::number to the second parameter or as Thiago suggested switch to QXmlStreamWriter