Krita 3.0 is going to be the first Qt 5.x-based Krita. April 13th, 2006, we ported Krita to Qt 4. Seventeen days after porting started, I could publish Krita 2.0 runs!”:
Back then, I was young and naive and deluded enough to think that porting Krita to a new version of Qt would automatically make Krita better. Porting itself was an exciting adventure, and using new technology was fun all by itself.
But porting to Qt 4 was a complete and utter disaster and it took us many years to finally get to a Qt 4-based version of Krita that was ready for users: Krita 2.4, released April 11th, 2012. There were reasons for that beyond the mere porting, of course, including the fact that, like fools, we couldn’t resist doing a complete refactoring of the basic KOffice libraries.
This time, we’re not doing that. But that’s not to say that I’m at all confident that we’ll have a Krita 3.0 that is as good for end users as 2.9. We started porting March 6th. Right now, Krita starts, but you cannot load or save an image and you cannot use any tool. Our input handling is broken because of changes in the event filter handling in Qt. Also, ugly big fonts and no icons. Really simple things, like the list of brush engines, are broken.
I know that we have to port Krita to Qt 5, because Qt 4 is not going to be maintained for much longer, because Linux distributions want to move on, because Qt 5 is being actively developed (except for the parts, like QtWebkit that are being actively deprecated). But it’s taking a lot of effort away from what really counts: making Krita better for end users.
It’s like this…
One can develop software for any number of reasons: because it’s fun to write code, because you get paid for it or because your software makes users happy. I’m going for the last reason. I want to make users happy to use Krita. I want users to have fun using Krita, I want it to be an efficient tool, a pleasure to use.
In order to do that, code-wise, I have to do three things: implement cool new features (including workflow improvements), fix bugs and improve Krita’s performance.
Similarly, I expect people working on libraries or build tools to have as their goal making it possible for me to reach my goals: after all, I’d hope they are writing software for me to use, otherwise I’d better use something else that does help me reach my goals.
Updating our build system and struggling with that because the new way of specifying the list of directories where the compiler looks for header files isn’t compatible with third party software that uses cmake, well, that does not contribute to my goal. This problem has taken four or five people each over four hours of time looking into and it hasn’t been solved yet! Now realize that Calligra has 609 CMakeLists.txt files and about 300 plugins. There are over seventy libraries in Calligra.
Likewise, having to rewrite existing code because someone found a new, better way of handling boolean values in a C library for reading and writing a particular file format is not helping. Your library might be much better quality, now, code-wise, but I, as your user don’t give a damn. Just like my users don’t give a damn what my code looks like; it only needs to work. I only care about whether your software helps me to deliver features to my users. Don’t tell me the new way is cleaner — that’s an illusion anyway. Don’t insult me by telling me the new way will make my maintenance-burden smaller, because you’ve just added a load to it right away.
In general, any change in a library or in a build system that makes work for me without materially improving Krita for Krita’s users is a waste of my time. Doubly so if it’s badly documented. I resent that waste. I don’t have enough time already.
Let’s take this tiny example… QModelIndex::internalId() no longer returns a qint64, but a kind of a pointer abstraction, a signed integer. Well, we have some code that compared that internalId() to -1. This code was written in 2011 by someone who is no longer around. The Qt documentation used to say
“Returns a qint64 used by the model to associate the index with the internal data structure.”
Now it says
“Returns a quintptr used by the model to associate the index with the internal data structure.”
It might just be me… But this change isn’t mentioned in C++ API changes — so, what do we do now? And once we’ve done it, is the style selector for the text tool really better?
Likewise, what do I care that “QCoreApplication::setEventFilter() and QApplication::x11EventFilter/macEventFilter/qwsEventFilter/winEventFilter are replaced with QCoreApplication::installNativeEventFilter() and QCoreApplication::removeNativeEventFilter() for an API much closer to QEvent filtering.” Nothing. Nada. Zilch. I just don’t want to port our event filter to a new api; it worked fine, let it go on working!
I could enumerate examples until dawn, and we’re only a month into porting. We’ve disabled all deprecation warnings, even, because they were so numerous they obscured the real errors.
So, to conclude, I suspect that it’ll take at least six months before the Qt 5 port of Krita is usable by end users, and that we’ll be adding new features and fixing bugs in Krita 2.9 for at least a year to come. Because if there’s one thing that I desperately want to avoid, it’s losing our userbase just when it’s nicely growing because we spend months doing stuff none of our users gives a damn about.