It’s almost a day job…

Following the discussions about QVector and QList on the qt development mailing list is almost a dayjob, I sighed on krita’s irc channel, this morning. It’s also slightly amusing, and it ties in with something I’ve been thinking about lately.

When my KDE Neon installation updated to Qt 5.14, I noticed that I got a lot more warnings than before. And those warnings were all about fresh, new deprecations. I spent two days updating our code to weed out the deprecated constructions, and as a result, our code became buggier.

In particular, the deprecation of QList::toSet, QList::fromSet, QSet::toList and QSet::fromList. Now, in Krita we used these methods a lot, mostly to make sure we’ve got only unique values in a list. All in all, about 72 times. The new equivalent is to use brand-new, spankin’ hot, c-plus-plussy range-based constructors.

Where our code used to look like this (and has looked like that since 2009):

QSet<KoShape*> shapesToOperateOn = QSet<KoShape*>::fromList(selection->selectedEditableShapesAndDelegates());

It now looks like this:

QSet<KoShape*> shapesToOperateOn;
#if QT_VERSION >= QT_VERSION_CHECK(5,14,0)
        QList<KoShape *> shapesDelegatesList = 
             selection->selectedEditableShapesAndDelegates();
        if (!shapesDelegatesList.isEmpty()) {
            shapesToOperateOn = QSet<KoShape*>  
                          (shapesDelegatesList.begin(),                                                 
                           shapesDelegatesList.end());
        }
#else
        shapesToOperateOn = QSet<KoShape*>::fromList(selection->selectedEditableShapesAndDelegates());
#endif

You need to check whether the list or set or vector you’re converting isn’t empty, because otherwise Qt will assert… Which won’t happen with the from/to methods. So, we’ve now got half a dozen lines of code where we had one, and a chance of an assert. Adding the conditions took another day out of my life. No wonder there’s a call for undeprecating these methods.

No, I really don’t care about C++. I’ve never been a C++ developer, I started using Qt 25 years ago through PyQt, and only started using Qt and C++ after a couple of years of Java.

Back then, there was no standard library for C++, and from what I saw back then, there was an idea that to be successful a library needed to look like what seemed the biggest thing in software development back then: Java. I guess that’s where the original developers of Qt got their inspiration from, what with the Java-like iterators, QObject and QMetaObject so you could have an object hierarchy like in Java…

An in the years since I started maintaining Krita, most people who came to the project, came without any knowledge of the C++ standard library. They tended to have used C# or Java at university, maybe Python or Ruby. Java-like Qt was easy to grasp, learn and use, even for people who really had never coded before.

But of course, over the times, C++ evolved, to a point where I, since I’m just a linguist who has programmed for about forty years, cannot read “modern” C++ code anymore, not really. I mean, Ivan Čukić’ Functional Programming in C++ is wonderfully clearly written, but I’d be lying if I said I understood it, and it doesn’t seem to contain much that’s relevant for my day to day work on Krita.

Still, QList does not have an equivalent in the standard library, so it must be really confusing for all those people who encounter Qt for the first time in the 25 years of its existence, and who are used to building their applications with the C++ standard library.

What I’m thinking is, isn’t it weird that the Qt documentation for one of its most core classes actually links to a random blog post that tells people not to use it, instead of explaining the issues in the documentation itself.

Oh, and when using QVector, at least in Krita, we’ve noticed that initializing a new QVector is quite a bit of a performance problem, whereas creating a QList and using it, no problems whatsoever.

To summarize:

  • Changing API just to make Qt more C-plus-plussy doesn’t make Qt more familiar to new developers, only more acceptable to people who have used the C++ standard library.
  • The new ways of doing things seem alway to take more lines of code that are harder to read.
  • Deprecating things to make Qt more C-plus-plussy steals days of my life and doesn’t make Krita better.
  • It actually makes Krita worse, because I cannot use those hours to improve Krita.
  • And trying to follow the discussions about these things takes too much time…

Ps. André Pönitz has what might be the best comment on the QList/QVector discussion.