Toying with iOS

So, two years ago I thought porting Krita to iOS or Android might make a dandy research project. A bit of context: if I spend 500 hours a year on an approved R&D project, I get a tax break. Plus, I like doing new stuff now and then. My 2018/2019 R&D project is Resource Management for the 21st Century, a previous one was Python Scripting.

In 2016, there wasn’t a decent Android tablet with a pen available anymore. The Wacom Cintiq Hybrid Companion is stuck on an ancient version of Android and wasn’t being made anymore, and Samsung’s Note tablet was an older model. The iPad Pro was new, so I decided to experiment with that. I got myself an iPad Pro, a Pencil and…

I tried to put a simple little example application on the iPad. I found something that demonstrated using the Pencil, and then discovered that Apple wouldn’t allow me to put code I had built myself on my iPad. I needed a developer account and keys and everything.

I told myself I would investigate that, but never had time to dig in.

Then in 2017, I gave the Cupertino Shylock the 99 ducats it wanted, and got the acccount. Mainly so we could sign our macOS builds and disk images — Apple making it deuced hard for people to run unsigned software. Now they’re going to make it even harder — they want applications in the macOS App Store to be notarized. But I digress…

SO, now, end of 2018, in the week off I usually allow me myself between Christmas and New Year’s Eve, I finally sat down to experiment a bit.

First, I loaded the test application I had selected in XCode. I plugged in my iPad in my Macbook Pro — for the first time since I had bought the hardware! Stuff happened, and I had to click various dialogs, and then the device popped up in XCode.

It was quite difficult to actually find where to put my Apple ID as the “Team” — it didn’t work to tell XCode what to sign the application with, it needed something it choose to call “Team”.

But then everything worked! Yay!

Okay, next step. Get a Qt application running on the iPad. I downloaded Qt again — usually I build it myself with a bunch of patches, but I didn’t want to try to build Qt for iOS myself, nor mess with the development tree I use for Krita.

Qt’s documentation was excellent, and pretty soon I had the Tablet example application running on the iPad. It looks a bit weird, because that’s a QWidget-based application, but that’s fine. ClipStudio Pro on iOS also is a compleat Desktop Application, with popup dialogs and menus and everything, so I am sure Apple wouldn’t mind… And the Pencil was supported really well, so that’s very hopeful.

Now I only had to make one more experiment before starting to tackle maybe porting Krita: port the Tablet example to CMake, load that in Qt Creator and use Qt Creator to build it and deploy it to my iPad.

Well, that was my Waterloo. CMake doesn’t officially support iOS yet. G’Compris, which does, does that by providing a qmake file and some manual instructions. Google turns up a ton of conflicting advice, some old and outdated, some newer and more hopeful. I have tried to make a start on it, but no dice yet. If you know how to make CMake build and deploy to an iPad, answers on a postcard, please!

The Awful Dilemma

I like fixing bugs… It makes people happy who have their bugs fixed, it makes Krita better, and it can be done in relatively small time laps. And it gives one a sense of having been usefully productive to go to the weekly bug summary, and see oneself in the top-five of bug resolvers. Not that I’m there right now, though I was last week, because sometimes one has to dig deeper.

These weeks I’m working on refactoring Krita’s resource systems. Resource in graphics app parlance are things like brushes, gradients, patterns — mostly small files that are stored somewhere on disk and that are loaded on start up. This code dates back to 2000 or so and was originally designed for a world where people would have a few dozen of each resource installed, and where brushes and patterns wouldn’t be bigger than 64 x 64 pixels.

These days, people want to have libraries containing hundreds of resources, and many are huge, like 5000×5000 pixel images. Krita cannot simply load all of that in memory like we’re doing now. It takes too much memory. It takes too much start-up time. It makes organizing resources too hard for the user. Because it uses the ancient KDE system for finding resources in the installation, local installation and local user folder in a tiered system, some resources cannot be edited, like with kxmlgui customization files, any application update will spell disaster.

The whole system will have to be scrapped. We’ll have to have a buffer between the actual resources on disk and the application — a caching database. I kinda feel like I’m jumping down an akonadi-type rabbit hole!

And then there’s tagging and organizing and all the bugs that 18 years of accretion have both fixed, added and papered over. The codebase is the most amazing mix of simple-minded, fiendishly over-complicated and sometimes downright mis-guided patterns and anti-patterns.

So, I’m coding, for the first time since the export filter warning project a couple of years ago, lots and lots and lots of new code. It’s fun! It’ll take at least two months of solid work, probably more, especially since most of it is actual research…

Still, going so deep and losing oneself in the high of concentrated coding means that bug fixing falls by the wayside — even though the result should end with scores of bugs closed — that I feel pangs of guilt. I know that this or that thing is broken, and my fingers itch! But I find it impossible to really carry all that’s needed for this refactoring in my head, and dig into problems in other systems.

Krita 3.0

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.

The World is Wrong!!!

“No shit, the world is wrong! It ain’t got a clue! But here, in this one minute video, I will explain what’s wrong and how I have discovered the right way.”

As soon as you encounter something that can be reduced to the above, it’s a pretty fair sign that the author doesn’t know what he’s talking about. Anyone who thinks they’re so unique that they can come up with something nobody else has thought before is, with likelihood bordering on certainty deluded. The world is full of smart people who have encountered the problem before. Any problem.

That means that a video that’s been doing the rounds on how “Computer Color is Broken” is a case in point. The author brings us his amazing discovery that linear rgb is better than non-linear, except that everyone who’s been working on computer graphics has known all of that, for ages. It’s textbook stuff. It’s not amazing, it’s just the way maths work. The same with the guy who some years ago proved that all graphics applications scale the WRONG way! “And how much did you pay for your expensive graphics software?”, he asked. “Eh? You sucker, you got suckered”, he effectively said, “but fortunately, here’s me to put you right!” It’s even the same thing, actually.

Whether it’s about color, graphics, or finding the Final Synthesis between Aristotle and Plato, this is my rule of thumb: people who think everone else in the world is wrong, are certainly wrong. (Also, Basque really is not the mother of all languages.)

And when it comes to color blending or image scaling: with Krita you got the choice. Use 16 bit rgb with a linear color profile, and you won’t see the artefacts, or don’t use it, and get the artefacts you probably were already used to, and were counting on for the effect you’re trying to achieve. We’ve had support for that for a decade now.

Note: I won’t link to any of these kookisms. They get enough attention already.

The Gorilla and the Gibbon

As a Krita developer, I’m not too happy comparing Krita to Photoshop. In fact, I have been known to scream loudly, start rolling my eyes and in general gibber like a lunatic whenever someone reports a bug with as its sole rationale “Photoshop does it like this, Krita must, too!”.

But when we published the news that a group at University Paris 8 had replaced Photoshop with Krita, that comparison becomes inevitable.

Even though it is just one group that used Photoshop for a specific purpose, one that Krita can fill as well. The news got picked rather widely and even brought the webserver to its knees for a moment. The discussion on Hacker News got interesting when people started claiming that Krita, like Gimp was missing so much stuff, like 16 bit/channel, adjustment layers and so on — even things that we’ve had since 2004 or 2005.

So, where are we, what’s our position? In the first place, with Adobe having about a hundred developers on Photoshop, they can spend thousands of hours a week on developing Photoshop. We’re lucky to get a hundred hours a week on Krita. Of course, we’re awesome, but that’s a huge disparity. We simply cannot duplicate all the features in Photoshop: even if we’d want to, there are not enough developer hours available. And even if there were, there’s the pesky problem of incomplete file format specifications. That means choices have to be made.

We develop Krita for a specific purpose: for people to create artwork. Comics, illustrations, matte paintings, concept-art, textures. Anything that’s not relevant for those purposes isn’t relevant for Krita. No website design, no wedding album editing, no 3D printing, no embedded email client.

But anything that artists need for their work is relevant. And I think we’re doing pretty well in that regard. Krita is an efficient tool that people find fun to use.

If that’s the purpose you use Photoshop for, give Krita a try. If you use Photoshop for something else, don’t bother. Or, well, you can give Krita a try, but don’t be surprised if Krita is missing stuff.

Sometimes, we will do a direct clone of a Photoshop feature: the layer styles dialog Dmitry and I are working on is an example. People want that feature, even if we’ve got filter layers and transformation masks already. It’s going to take about two to three hundred hours just to do all the typing, let alone the actual thinking about how to fit the algorithms into Krita’s image composition code.

But mostly, cloning another application is a bad idea. You are always be running behind, because you cannot clone what hasn’t been released yet, and unless you have more hours per week available than the clonee, you won’t ever have time for introducing unique features that make your project more interesting than the clonee — like Krita’s wrap-around mode. Or the opengl canvas, which we had in 2005, and which Photoshop now also has. (This Nvidia page on how Opengl makes Photoshop more responsive could have been written for Krita. The only thing we miss is embedding a 3D model in your painting, and we’ve already made two Summer of Code students attempt just that.)

So, what’s our roadmap for 2015, if it isn’t “be Photoshop unto all people”?

These are the big issues that we need to spend serious time on:

  • Port to Qt and KDE Frameworks 5. In many respects, a waste of time, since it won’t bring us anything of actual use to our users, but it has to be done.
  • Implement a performance optimization called Levels of Detail. This will make Krita work much faster with bigger images, at the expense of actually doing the pixel mangling several times.
  • Animation. Somsubhra’s animation timeline is a great start, but it’s not ready for end users. We had hoped for a big donation kickstarting this development, but that doesn’t seem likely to materialize.
  • OSX. We’ve got an experimental OSX port, but it’s buggy and broken and missing features. (No HDR painting, OpenGL is broken, the popup palette doesn’t show in OpenGL mode, memory handling is broken — and a thousand smaller issues.
  • Python. Krita has been scriptable in the past. First through KJS, in the 1.x days, then through Kross (which meant javascript, ruby, python). Neither scripting interface exposed all of Krita, or even the right parts. You could create filters in Python, but automating workflow was much harder. There’s a new prototype Python scripting plugin, modelled after Kate’s Python plugin that would make a good start.

To make this possible, we simply have to add hours per week to Krita. Which means starting on the next fund raiser, and publising Krita in more app stores, sell more DVD’s, get more people to join the Development Fund!


Emanuele Tamponi (Thrain) has managed to implement Kubelka-Monk color mixing for Krita’s mixer palette. This means, simply put, that mixing  works like in real life. It uses the reflectancy of pigments to reliably mix color on the computer and get the results you’ve been taught in primary school.

This is really unique. There is no other software available that does this. Corel Painter doesn’t do this. Photoshop doesn’t do this. There are some academic experiments that do this — but it’s impossible to get the code or the binaries for that.

Hip hip for Emanuele!

(Pics will follow when I’ve either compiled Krita (I broke my tree) or have finished moving house, whichever comes first.)

Krita on Windows

Sven posted his thoughs on the difficulties supporting Krita on Windows. I’d like to dig in a bit deeper here. The first question is, is it worth it?

Well, the highly experimental Calligra installer has been downloaded about 15.000 times. That’s a lot of downloads! Judging from the ratio of referrals from and, Krita is probably the reason for two-thirds of those downloads.

So, apparently there is a demand for Krita on Windows that makes people download it even though we’re extremely explict about its extremely experimental status!

We also know that there are bugs specific to Windows, like the slow move tool, a bug with duplicated layers being broken and so on. We know that the top toolbar looks ugly and that there are other issues where being non-native really is apparent.

Another thing I know is that developing on Windows really is no fun. As the Tomahawk Windows dude says:

We do need developers on Windows too, but no-one in a sane state of mind wants to develop there.. 😉

So what Krita needs is to find a volunteer who completely and utterly disagrees with that quote… Someone who loves Windows, cares about the look and feel of an application on Windows, and who simply loves developing on Windows. If you’re that person, contact me!

The other option would, of course, be to find the money to pay someone to work on Windows.

But we’re not talking 1000 euro/month here — we’re out of the student summer job territory! At a conservative estimate, we’d need between five and seven times as much: 5000-7000 euros of regular income to hire a full-time developer. So we’re out of donations territory, out of Summer of Code territory. It’s a big job, which needs to be done well.

If there are 15.000 downloads of an experimental version of Krita in about three months — maybe there is a market. Maybe we could package Krita, put it in an app store like Intel’s app-up, on Amazon, sell it directly, go with a pay-what-you-like model like Ardour. Whatever — and use the proceeds pay a full-time developer to work on the Windows version of Krita. It’ll, indirectly and directly, also benefit Krita on its main platform.

I’m seriously investigating all the options here, including finding some kick-start funding.

(Note: Krita is GPL, but that doesn’t stop us from charging money for a binary, even though we can’t stop anyone from copying the binary around or reselling it — and I don’t even want to do that. Free software is Free software. Being GPL, proprietary extras and improvements are also out of the question. And that’s the way I like it.)

Oh, and as a side-node: next to the highly experimental Calligra 2.4 installer that includes Krita next to the other apps, there’s also an extremely experimental Krita-only installer that packages Krita fresh from git master. Just to help me figure out how to do it. Get yours while it’s fresh at KO GmbH’s download page.

Call for Photoshop documents

Call for Photoshop Documents

One of the new things in Krita 2.4 (soon to be released) is pretty decent Photoshop file import. Not everything is supported, but you should be able to load RGB, Lab and CMYK files with multiple layers, thanks to the work by Siddharth Sharma.

Next is filling in the missing parts, and export, of course!

But for that we need to have a good, representative corpus of PSD files, with known version numbers. A bit like the corpus we have for applications like Words, Stage and Sheets — trunk/tests/calligratests/.

These office documents are tested regularly using special tools Thorsten Zachmann built for Calligra. We need that for Krita as well.

So I want to call upon all readers here to contribute PSD files to our collection. I need to know the version of Photoshop they were created with and the files will be committed to this public subversion repository, so they must be appropriately licensed or be public domain.

Please help us out! You can send the files to

Packt Open Source Awards

While we’re in the middle of the beta period for Krita 2.4 (which promises to be completely amazing, of course!), I got an email from Julian from Packt Publishing, asking me to fill in a questionnaire for the judges of the 2011 Packt Open Source Awards. Nice, thorough questions.

Krita is a finalist in the multimedia category… It’s already great that we got this far: a year ago, Krita never got further than a write-in option whenever there was a vote going on! But we want to win as well!

So please go to packt’s website, register and vote!

Krita, Wacom, Qt and distributions

It’s a never-ending tale of sorrow and tears… The tale of Qt, Wacom and distributions. It happens with distressing regularity that people join us on the #krita irc channel, the krita forums or the krita mailing list. Users, but also developers. Their question? “Krita doesn’t seem to support my Wacom tablet, but Gimp and MyPaint work fine!”

This is never actually caused by Krita. Krita uses Qt’s wacom support, same as for instance Maya does. The Qt Wacom api is good, the rate of events is good, we are fine with that.

The problem is that sometimes Qt breaks when a new version of the wacom drivers is released. And sometimes distributions package the wrong version of Qt and the wrong version of the Wacom drivers together. We don’t have an exact table of what works and what doesn’t work. As developers we tend to drift to distributions that are relatively good at supporting Wacom and Qt together… OpenSUSE hasn’t failed me for a couple of years now! But just check our help forum.

And then there are situations where Qt is blameless, Wacom is blameless and the distribution is really to blame. For instance, when distributions patch Qt to achieve multitouch with an experimental patch that breaks tablet support.

I’m not sure what to do about this: the bugs get reported to the distributions, and when necessary to Qt, but in the meantime, for many people Krita breaks every time they do an upgrade. And we cannot help them!