Technically, we’re done porting Krita to Qt5 and KDE Frameworks 5. That is to say, everything builds, links and Krita runs, and there are no dependencies on deprecated libraries or classes anymore. In the process, the majority of Calligra’s libraries and plugins were also ported. It was not an easy process, and if there hadn’t been sponsorship available for the porting work, it would not have happened. Not yet, in any case. It’s something I’ve heard from other KDE project maintainers, too: without sponsorship to work on the port full-time, projects might have died.
Krita wouldn’t have died, but looking back at the previous month’s work, I wonder I didn’t go crazy, in a loud way. I spent four, five days a week on porting, and fixing the porting documentation, and then one or two days on trying to keep the bug count down for the 2.9 branch. As Kalle noted, porting isn’t hard, it’s very mechanical work that despite all the scripts, still needs to be done by a human, one who can make judgement calls — and one who isn’t afraid of making mistakes. Lots of mistakes: it’s unavoidable. Most of them seem to be fixed now, though. It’s like running a racecourse in blinkers.
So, what were the hardest problems?
The winners, ex-equo are KStandardDirs to QStandardPaths and KUrl to QUrl.
The latter is weird, because, actually, we shouldn’t be using QUrl at all. The reason KUrl was used in KOffice, now Calligra, is for handling network transparent file access. That’s something I do use in Kate or KWrite, when writing blogs (my blog system is a bunch of nineties perl scripts) but which I am sure not a single Krita user is actually using. It’s too slow and dangerous, with big files, to depend on, it’s superseded by dropbox, one-drive, google-drive, owncloud and the rise of the cheap NAS. Not to mention that only Plasma Desktop users have access to it, because on all other platforms we use native file dialogs which don’t give access to remote locations. All the QUrl’s we use get created from local files and end up being translated to local filenames.
KStandardDirs is more interesting. KStandardDirs actually was two things in one: a way to figure out the paths where the system and the application can store stuff like configuration files, and a way to build a kind of resources database. You’d define a resource type, say “brush”, and add a bunch of locations where brushes can be found. For instance, Krita looks for brushes in its own brushes folder, but also in the shared ‘create project’ brushes folder and could even look in gimp’s brushes folder.
The resources part isn’t part of QStandardPaths, but is used really heavily in Calligra. The central place where we load resources, KoResourceServer just couldn’t be ported to QStandardPaths: we’d have to duplicate the code for every resource type. But there’s no problem that cannot be solved with another layer of indirection and a lump of putty, and I created a KoResourcePaths class that can handle the resource aliases. I’m not totally convinced I ironed out all the bugs, but Krita starts and all resources are being loaded.
There were a few more classes that were deprecated, the foremost being KDialog. There’s only a hundred or so places in Calligra where that class was used, and here the best solutions seemed to me to fork KDialog into KoDialog. Problem solved — and honestly, I don’t see why the class had to be deprecated in the first place.
Now all the basic porting has been done, it’s time to figure out what is broken, and why. Here’s a short list:
- Loading icons. Right now, I need to patch out the use of the icon cache to load icons. But in any case I am still considering putting the icons in the executable as resources, because that makes packaging on Windows much easier.
- Qt5’s SVG loader had trouble with our svg icons; that was fixed by cleaning up the icons.
- OpenGL was a huge task, needing a nearly complete rewrite — it works now on my development system, but I’m not sure about others.
- Qt5’s tablet support is much better, but now that we use that instead of our own tablet support, we’ve lost some performance (work is ongoing) and some things have changed meaning, which means that the scratchpad and the popup palette are broken for tablet users.
- In general, the user interface feels sluggish: even things like the preferences dialog’s widgets are slow to react.
And when all that is fixed, there is more to do: make new build environments for Windows (hopefully we can start using MSVC 2015 now) and OSX, see about dropping superfluous dependencies on things like DBus and, then…
Testing, testing and testing!
But I am getting confident that Krita 3.0 could be something we can let people try and test this year. And here is, for your delectation, a delectable screenshot: