Coincidence? Unlikely

The Stichting Brein — the Dutch equivalent of the RIAA, or so it seems — has lost a court case a few days ago. Seems that internet providers are not obliged to provide information about supposedly copyright infringing customers. At least, not under all circumstances.

So, today’s news is that the Dutch police and secret service are going to create and maintain  a database for matching IP addresses to persons. Of course, this is for the loftiest of goals: we’re combating child pornography and terrorism here!

But my bet is that this just means that next time Brein wants to sue a Kazaa user, they can skip the providers and go to the secret service. And that this will happen a lot more often than that the database will be used to catch terrorists. And that catching so-called “pirates” (you’re not a pirate unless you kill, maim and rob, I feel) was the actual reason for creating this database.

For a non-governmental organization, Brein (and the BSA) do have an awful lot of powers. And for a free country, we’re under an awful lot of surveillance.

Why aren’t you using github?

Is a question we, Krita developers, get asked a lot. As in, many times a week. Some people are confused enough that they think that github is somehow the “official” place to put git repositories — more official than  projects.kde.org, phabricator.kde.org, git.gnome.org or wherever else. Github, after all, is so much more convenient: you only need a github account or login with your social media account. It’s so much more social, it’s so cosy, and no worries about licensing either! So refreshing and modern.

So much better than, say, SourceForge ever was! Evil SourceForge, having failed to make a business out of hosting commercial software development projects is now descending to wrapping existing free software Windows         installers in malware-distributing, ad-laden installer wrappers.

The thing is, though, Github might be the cool place to hack on code these days, the favourite place to host your projects: that is exactly what SourceForge was, too, back in the days. And Github’s business model is exactly what SourceForge’s was. And if that isn’t a warning against giving your first-born children in the hands of a big, faceless, profit-oriented, venture-capital-backed company, then I don’t know what is!

And yes, I have heard the arguments. Github is so familiar, so convenient, you can always remove your project (until Github decides to resurrect it, of course), it’s git, so you’re not losing your code revision history! But what about other artefacts: wiki, documents, bugs, tasks? Maybe you can export them now, I haven’t checked, but what will you import it into?

I’ve spent over ten years of my life on Krita. I care about Krita. I don’t want to run that sort of risk. One thing I’ve learned in the course of a mis-spent professional life is that you always should keep the core of your business in your own hands. You shouldn’t outsource that!

So, one big reason for not moving Krita’s development to github is that I simply do not trust them.

That’s a negative reason, but there are also positive reasons. And they all have to do with KDE.

I know that a lot of people like to bitch about KDE — they like to bitch about the layout of the forum, the performance of the repo browser, the size of the libraries, the releases of new versions of the Plasma Desktop, about fifteen year old conflicts with the FSF (which somehow proves to them that KDE isn’t trustworthy…) The fact is that especially in the Linux world, a bunch of people decided ages ago they didn’t like KDE, it wasn’t their tribe and they apparently find it enjoyable to kick like a mule everytime we do something.

Well, shucks to them.

Then there are people for whom the free software world is a strange place. You don’t see something like Corel Painter being hosted together with a bunch of other software on a bigger entity’s website. It’s confusing! But it’s still strange, to many people, to see that Krita shares a bug tracker, a forum, a mailing list platform, a git repository platform with a bunch of other projects that they aren’t interested in.

Well, I see that as a learning moment. And not as a hint that we should separate out and… Start using using github? Which would also mean sharing infra with a bunch of other projects, but without any sense of community?

Because that is what make KDE valuable for Krita: the community. KDE is a  big community of people who are making free software for end users. All kinds of free software, a wild variety. But KDE as a community is extremely open. Anyone can get a KDE identity, and it doesn’t take a lot of effort to actually get commit access to all the source code, to all projects. Once in,
you can work on everything. All the pieces needed to develop software are here: websites, forums, wikis, bug trackers, repo hosting, mailing lists, continuous-integration, file hosting, todo management, calendaring, collaborative editing, file hosting. The system admin team does an incredible job keeping it all up and running, and the best thing is: we own it. We, the community, own our platforms and our data. We cannot be forced by a venture capitalist to monetize our projects by adding malware installers. We own our stuff, which means we can trust our stuff.

And we can improve our platform: try to improve a closed-source, company-owned platform like github! So suggestions for improvement are welcome: we’re now looking into phabricator, which is a very nice platform giving a lot of the advantages of github (but with some weird limitations: it very clearly wasn’t made for hosting hundreds of git repos and hundreds of projects!), we’re looking into question-and-answers websites. Recently, the continuous integration system got improved a whole bunch. All awesome developments!

But moving development to github? Bad idea.

Twenty years of Qt!

I first encountered Qt in Linux Journal in 1996. Back then, I wasn’t much of a programmer: I had written a GPL’ed mail and Usenet client in Visual Basic and was playing around with Linux. I wanted to write a word processor, because that was really missing, back then.

I tried to use xforms, but that didn’t have open source (it was binary only, can you believe it?), and besides, horrible. Since I didn’t particularly care about having a GUI, I tried to use curses, which was worse. I had taken a look at Motif years before, so I didn’t look again. Sun’s OPEN LOOK had a toolkit that looked nice, but wasn’t. For work, I had used Delphi and MFC, and had had to make sense of Oracle 2000. None of those were useful for writing a word processor for Linux.

And then, suddenly, out of the blue (though I remembered some of the names involved with Qt as being involved with my favorite ZX Spectrum emulator), appeared Qt. Qt made sense: the classes were helpfully named, the api’s were clear and sensible, the documentation was good, the look and feel worked fine. It had everything you’d need to write a real application. Awesome!

So I got started and discovered that, in the first place, I didn’t know what makes a word processor tick, and in the second place, I didn’t know C++… So my project foundered, the way projects tend to do, if you’re trying to do stuff all by your lonesome.

Then I changed jobs, stopped working on a broken-by-design Visual Basic + Oracle laboratory automation system for Touw in Deventer, started working with Tryllian, building Java-based virtual agent systems. Fun! I learned a lot at that job, it’s basically where I Was taught programming properly. I discovered Python, too, and loved it! Pity about that weird tkInter toolkit! And I started using KDE as soon as I had a computer with more than 4 megabytes of ram, and KDE used Qt.

Qt still made sense to me, but I still didn’t know C++, though it looked to me that Qt made C++ almost as easy as Java, maybe easier, because there were seriously dumb bits to Java.

Then PyQt arrived. I cannot figure out anymore when that was: Wikipedia doesn’t even tell me when it was first released! But I threw myself into it! Started writing my first tutorials in 1999 and followed up writing a whole book on PyQt. My main project back then was Kura, an alternative to SIL’s Shoebox, a linguistic database application that later got handed over to the Ludwig-Maximilians University in Munich.

I never could make sense out of Java’s GUI toolkit: Swing didn’t swing it for me. But that was work stuff, and from 2003, I worked on Krita. I started doing my own painting application in PyQt, about the time Martin Renold started MyPaint. I quickly decided that I couldn’t do a painting application on my own, just like I couldn’t do a word processor on my own. By that time I had taken a good hard look at GTK as well, and concluded that anyone who’d propose to a customer to base a project on GTK should be sued for malpractice. Qt just made so much more sense to me…

So I found Krita, learned bits of C++, and since then there haven’t been many days that I haven’t written Qt-based code. And without Qt, I probably would have started a second-hand bookshop or something. Qt not just lets me code with pleasure and profit, it is what keeps me sane, coding!

Cross Platformity

Cross Platformity

Several years ago we started porting Calligra to Windows. Supported by NLNet. Some time later, Intel also supported KO to create two Windows versions of Krita, one for tablets, one for convertible ultrabooks and later still, a new version of Calligra Words, Stage and Sheets for convertible ultrabooks. Meanwhile, the Krita Foundation has been publishing Krita on Windows and OSX for some time now. That’s a fair amount of experience in puslishing software originally written on Linux on other platforms.

Let’s take a look at the starting position.

Calligra, or rather KOffice, as it was called when it started out, was created to be a native KDE application. Integrated with the KDE desktop environment, using all the features that KDE offers, ranging from inter-process communication to system-tray notifications, shared plugin loading, mimetype handling, and other resource icon locating. These applications are KDE applications through-and-through.

There are also some hidden assumptions in the way KDE works on Linux: for instance, that reading thousands of small files on startup isn’t a big deal. We Linux users are fortunate in having a choice of really good, really fast file systems, compared to Windows or OSX users.

So, on Linux, it’s not that big a deal if people aren’t running the KDE Plasma Desktop, since installing the libraries, the icons, maybe some system settings kcms will mean Krita will run just as well in Gnome as in KDE. It’s a pity that some distributions don’t make Krita depend on the oxygen icon set, and that others think that installing Krita means users need marble, but that’s the way Linux packaging works, or doesn’t work.

Now, there are two reasons for bringing a Linux application to another platform, two ways of going about it and two ways of implementing the port.

You can port an application to Windows or OSX because you want to use it yourself, as a Linux user in exile, or you can port an application to Windows because you want to gain a user-base on Windows.

And you can port an application to Windows or OSX by bringing the whole Linux and KDE environment with you, or by making the application as native as possible.

And finally, you can build on the target platform, with the target platform’s native compilers, or you can cross-compile from Linux.

If you’re porting for Linux exiles, the first approach is fine. It’s what on Windows is done by cygwin, msys, KDE’s emerge tool or KDE’s windows installer. It’s what FINK or MacPorts provide on OSX: a package manager, all the tools you’re used to, all the platform services the application depends on. It’s a big undertaking to maintain ports of so many components, and the porting system will often have temporary failures. I’m not saying that it’s wasted work: I use KDE’s windows installer to get Kate on Windows myself.

But it’s not going to work when you want to build a user base for your application on Windows or OSX. The package managers, the installers are too complicated, too alien and drag in too many unfamiliar things. Even using something as Emerge to build, and then package up the built bits into an installer is problematical, because those bits will still expect the full KDE environment to be available.

And a Windows user is going to freak out when starting an application starts daemons that keep running. No kded, therefore. Their “protection” software (snake oil, but scary snake oil) will yammer when there’s weird inter-process network communication. Bye-bye dbus. For a single application like Krita, a mimetype database is overkill. Loading icons by the hundred-weight, individually gives a bad hit on startup time. And yes, we’re getting nastygrams about the number of files we package with Krita versus the number of files Photoshop packs.

It’s really clear to keep in mind what the goal is. Because if you’re working together with someone else, and they’re of the linuxer-in-exile persuasion, and you’re of the native-user persuasion, conflicts will happen all the time. The first crowd won’t mind using glib in update-mime-database because, what’s the problem? While you’ll hate that requirement because building glib on windows and osx ain’t easy, and it’s a big dependency with a lot of other dependencies that come with it, and all just to be able to figure out that a .jpg file is a jpeg file.

Most ‘native’ Windows applications that use 3rd party libraries includes those libraries in their own source tree, either as dll’s or as source code. It’s easy, you never have to deal with newer versions of libraries breaking your code, you can build everything in one go. For some libraries, it’s even the only way: you cannot build the breakpad library outside the source tree of the application that uses it. But for a cross-platform application that also targets Linux distributions, this cannot be done. You cannot include all dependencies in your source tree.

So, we need to find a way to build all dependencies without dragging in a fake Linux or fake KDE environment. Without dragging in a package manager. One that creates applications that behave as natively as possible.

What we’re currently trying to do is this: build a cmake system that builds Krita’s dependencies and then builds krita. CMake’s external project system works pretty well for this. It’s not as complicated as the Emerge system, though there are similarities, and we’re even re-using patches from Emerge for our dependencies.

Here’s the list of all dependencies we currently build:

  • automoc: needed for kdelibs-stripped
  • boost: needed for Krita
  • bzip2: needed for kdelibs-stripped
  • eigen3: needed for Krita
  • exiv2: needed for kdelibs-stripped and Krita
  • expat: needed for exiv2
  • ffi: needed for glib (only on OSX)
  • gettext: needed for glib (only on OSX)
  • giflib: needed for kdelibs-stripped and qt
  • glew: needed for Krita
  • glib: needed for shared_mime_info (only on OSX)
  • gsl: needed for Krita
  • iconv: needed for gettext and exiv2
  • ilmbase: needed for openexr
  • intltool: for glib (only on OSX)
  • jpeg: needed for kdelibs-stripped, qt and krita
  • kdelibs-stripped: specially hacked up version of kdelibs4 that doesn’t need openssl, dbus and a whole lot of other things.
  • lcms2: needed for krita
  • libxml2: needed for kdelibs-stripped
  • libxslt2: needed for kdelibs-stripped
  • opencolorio: needed for krita, has it’s own 3rd party external projects: tinyxml, yaml
  • openexr: needed for Krita
  • patch: needed on windows only, creates a myptch.exe because patch.exe is banned on Windows…
  • pcre: needed for shared-mime-info
  • perl: needed on Windows to build Qt
  • pkgconfig: needed on OSX to build glib
  • png: needed for Krita and Qt
  • qt: we need to build this ourselves to strip out openssl, qtscript, the database stuff and more, and because we build with a version of Visual C++ that Qt4 doesn’t support out of the box
  • shared_mime_info: needed for kdelibs-stripped
  • tiff: needed for Qt and Krita
  • vc: needed for Krita
  • krita: what we finally want…

And this is what’s still missing:

  • kdcraw: would provide camera RAW import
  • poppler: would provide PDF import and export
  • openjpeg: would provide jpeg2000 import and export.

All this is described here for OSX and here for Windows. My goal is to make a CMake based project that can build everything on OSX and Windows, and on Linux, for Windows in one go. It needs much more work, in fact more time than I actually have… Anything that can slim the number of dependencies would be very welcome!

And now it’s coming full-circle: I actually would like to have installers for Krita that work on Linux, too. Just like Blender or Qt Creator have, a 32 and 64 bits installer that people can download, run and get the latest build of Krita, without weird extra dependencies, without waiting for distributions to pick up the next version of Krita. The system we’re building should be able to provide that…

Evolving KDE

Paul and Lydia have blogged about how KDE should and could evolve. KDE as a whole is a big, diverse, sprawling thing. It’s a house of many rooms, built on the idea that free software is important. By many, KDE is still seen as being in competition with Gnome, but Gnome still focuses on creating a desktop environment with supporting applications.

KDE has a desktop project, and has projects for supporting applications, but also projects for education, projects for providing useful libraries to other applications and projects to provide tools for creative professionals and much, much more. For over a decade, as we’ve tried to provide an alternative to proprietary systems and applications, KDE has grown and grown. I wouldn’t be able, anymore, to characterize KDE in any sort of unified way. Well, maybe “like Apache, but for end-users, not developers.”

So I can only really speak about my own project and how it has evolved. Krita, unlike a project like Blender, started out to provide a free software alternative to a proprietary solution that was integrated with the KDE desktop and meant to be used by people for whom having free software was the most important thing. Blender started out to become the tool of choice for professionals, no matter what, and was open sourced later on. It’s an important distinction.

Krita’s evolution has gone from being a weaker, but free-as-in-freedom alternative to a proprietary application to an application that aspires to be the tool of choice, even for people who don’t give a fig about free software. Even for people who feel that free software must be inferior because it’s free software. When one artist says to another at, for instance, Spectrum “What, you’re not using Krita? You’re crazy!”, we’ll have succeeded.

That is a much harder goal than we originally had, because our audience ceases to be in the same subculture that we are. They are no longer forgiving because they’re free software enthusiasts and we’re free software enthusiasts who try really hard, they’re not even much forgiving because they get the tool gratis.

But when the question is: what should a KDE project evolve into, my answer would always be: stop being a free software alternative, start becoming a competitor, no matter what, no matter where. For the hard of reading: that doesn’t mean that a KDE project should stop being free-as-in-freedom software, it means that we should aim really high. Users should select a KDE application over others because it gives a better experience, makes them more productive, makes them feel smart for having chosen the obviously superior solution.

And that’s where the blog Paul linked to comes in. We will need a change in mentality if we want to become a provider of the software-of-choice in the categories where we compete.

It means getting rid of the “you got it for free, if you don’t like it, fuck off or send a patch” mentality. We’d all love to believe that nobody thinks like that anymore in KDE, but that’s not true.

I know, because that’s something I experienced in the reactions to my previous blog. One of the reactions I got a couple of times was “if you’ve got so much trouble porting, why are you porting? If Qt4 and KDE 4 work for you, why don’t you stay with it?” I was so naive, I took the question seriously.

Of course Krita needs to be ported to Qt5 and Kf5. That’s what Qt5 and Kf5 are for. If those libraries are not suitable for an application like Krita, those libraries have failed in their purpose and have no reason for existence. Just like Krita has no reason for existence if people can’t paint with it. And of course I wasn’t claiming in my blog that Qt5 and Kf5 were not suitable: I was claiming that the process of porting was made unnecessarily difficult by bad documentation, by gratuitous API changes in some places and in other places by a disregard for the amount of work a notional library or build-system ‘clean-up’ causes for complex real-world projects.

It took me days to realize that asking me “why port at all” is in essence nothing but telling me “if you don’t like it, fuck off or send a patch”. I am pretty sure that some of the people who asked me that question didn’t realize that either — but that doesn’t make it any better. It’s, in a way, worse: we’re sending fuck-off messages without realizing it!

Well, you can’t write software that users love if you tell them to fuck off when they have a problem.

If KDE wants to evolve, wants to stay relevant, wants to compete, not just with other free software projects that provide equivalents to what KDE offers, that mentality needs to go. Either we’re writing software for the fun of it, or we’re writing software that we want people to choose to use (and I’ve got another post coming up elaborating on that distinction).

And if KDE wants to be relevant in five years, just writing software for the fun of it isn’t going to cut it.

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.

Fun with a Surface Pro 3

Micosoft’s Surface Pro 3 is, or should be, pretty much a perfect sketchbook device. Nice aspect ratio, high resolution, pen included. Of course, the screen is glossy and the pen isn’t a Wacom. But when it was cheap with the keyboard cover thrown in for free I got one anyway — as a test device for Krita on Windows.

In the end, hardware-wise, it’s nice and light, it just looks good, the keyboard doesn’t feel too bad, actually, and it’s got home, end, page-up and page-down keys, a trick that Dell hasn’t managed. The kickstand is rather meh — it’s sharp, hard to open and doesn’t feel secure on my lap. Still, not a big problem.

Windows

I can handle Windows these days, even Windows 8. It’s OSX that I truly despise to work with. However, when I got home and switched it on, I got my first shock… After the usual Windows setup sequence, not only did the device refuse to install the 70 or so critical updates, any and all https traffic was broken!

Turns out that the setup sequence picked the wrong timezone, and that in turn broke everything! Now, I might be a bit of an idiot, but I knew for sure that I had chosen Netherlands as location, US English as language, US English as keyboard. And besides, if your average Linux distribution can automatically set the right timezone, Windows should be able to, too! Since then, I’ve used the restore option a couple of times, and it seems to be really hit and miss whether the setup sequence understands this set of choices!

N-Trig

So, I restored to blank and started over. This time it did install everything. So, I installed the N-Trig wintab driver, Krita X64 2.9.0 and gave it a whirl. Everything worked perfectly. Cool!

Then I tried some other software, and when we released 2.9.1, I restored to blank, installed 86 updates and Krita 2.9.1. Now the 64 bits version of Krita didn’t work properly with the pen anymore: no pressure sensitivity. That’s something others have reported as well: the 32 bits version worked fine… Now N-Trig releases two versions of their drivers: 32 bits and 64 bits, and they claim that you need to use the x86 driver with x86 apps and the x64 driver with x64 apps, but… No matter which driver is installed, x86 Krita and x86 photoshop CS2 work fine. I don’t have any other x64 based Wacom-based drawing application to test with, but all of this sounds very suspicious.

Especially when I noticed that on their other wintab driver download page, they will send you to a driver that fits your OS: 32 bit driver for a 32 bit Windows, 64 bit driver for a 64 bit Windows. I’m not totally sure that the N-Trig people actually know what they’re doing.

And then I tested Krita 2.9.1 on another Windows 8.1 device with a more modern (1024 levels of pressure) N-Trig pen. With the 64 bit driver both x64 and x86 versions of Krita had pressure sensitivity. But… The driver reports the wrong number of sensitivity levels, in one place it claims 256, like the old pens, in one 1024, so Krita gets confused about that, unless we hack around it.

Still, this must be an issue with the drivers installed on the Surface Pro 3, and I haven’t yet managed to make it work again, despite a couple of other wipes and reinstalls. Copying the drivers from the Intel N-Trig laptop to the Surface Pro also doesn’t make a difference. Installing the Surface Pro 3 app doesn’t make a difference. I guess I’d best mail the N-Trig developers.

For now, it’s irritating as heck that I can’t run the 64 bits version of Krita on the Surface Pro 3.

Linux

OpenSUSE 13.2 boots on it, and the pen even moves the cursor around. No idea about pressure sensitivity because while the trackpad is fine, the keyboard doesn’t work yet, so I couldn’t actually install stuff. Google
suggests that kernel patches might help there, but it’s the pen that I care about, and nobody mentions that.

As a drawing tablet

A good artist can do great stuff with pretty much everything. People can do wonders with an ipad and a capacitive stylus with no pressure sensitivity. I’m not much of an artist. I used to believe I could draw, but that was twenty-five years ago, and is another story besides. But I spent an evening with Krita 2.9.1 and the Surface, to get a feel for how it differs from, e.g. the Wacom Hybrid Companion.

The screen is glossy and very smooth. That’s not as nice as the Companion’s matte screen, but the high resolution makes up for it. It’s really hard to see pixels. But… Every time you touch the screen with the pen, it deforms a little bit and becomes a little bit lighter. That’s pretty distracting!

The pen also lags. Not just in Krita, not just when painting, but when hovering over buttons or menus, the cursor is always a bit behind.

There’s no parallax, which is really irriting on the Cintiq. There’s also no calibration needed, the pen is accurate into the deepest corners. That is pretty awesome, especially since it lets me use the zoom slider with the pen. The pen really feels very accurate. In Krita at least: in Photoshop CS2, it’s very hit and miss whether a quick stroke will register.

The tablet itself is nice and light, the form factor pretty much perfect. I can hold it in one hand, draw with the other one, in portrait mode, for quite some time. Try that with a Companion!

The hybrid companion doesn’t get hot, though I heard that the Windows companion does. The Surface certainly does get hot! But the heat is located in one place, not the place where I held the tablet, it was only noticeable because I rest my hand on the screen while drawing. Note for other Surface users: disabling flicks in the control center makes life much easier!

For Krita

I have had reports that the virtual keyboard didn’t work from a Cintiq Companion user, but it works just fine for me on the Surface. I can enter values in all the dockers, sliders and dialogs in desktop mode.

As for the N-Trig pen, we support pressure sensitivity, but the two buttons are weird things and I don’t know yet how to work with them. Which means, no quick-access palette, no quick panning yet.

In any case, we need to do a lot of work on the Sketch gui to make it as usable as, e.g., Art Flow on Android. Heck, we need to do a lot of work on Sketch to bring it up to 2.9! But a good tablet-mode gui is something I really want to work on.

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 2:1 Form Factor

At KO GmbH, we did several projects to show off the 2:1 convertible laptop form factor. Krita Gemini and Calligra Gemini are applications that automatically switch from laptop to tablet gui mode when you switch your device. Of course, one doesn’t get that to work without some extensive testing, so here’s a little collection of devices showing off all existing (I believe) ways of making a laptop convertible:

There’s rip’n’flip, as exemplified by the Lenovo Helix, and arguably by the Surface Pro 3 (which its own twist, the kickstand). There’s the bend-over-and-over-and-over model pioneered by the Thinkpad Yoga (but this is an Intel SDP, not a Yoga, all the Yoga’s are with other ex-KO colleagues) and finally the screen tumbler of the Dell XPS 12.

Every model on the table has its own foibles.

The Helix actually doesn’t do the 2:1 automatic switch trick, but that’s because it’s also the oldest model we’ve got around. The Helix basically has only one angle between the screen and keyboard, and that’s it, and it’s fairly upright. The keyboard is pretty good, the trackpoint is great, of course. In contrast to all the other devices, it also runs Linux quite well. The power button is sort recessed and really hard to press: it’s hard to switch the device on. The built-in wacom pen is impossible to calibrate correctly, and it just won’t track correctly at the screen edges. As tablet, it’s nice and light, but the rip’n’flip thing is flawed: doesn’t alway re-attach correctly.

The Dell XPS 12 is one of the nicest devices of the four. The screen rotation mechanism looks scary at first, but it works very, very well. It’s a nice screen, too. The keyboard is ghastly, though, missing a bunch of essential keys like separate home, end, page-up, page-down. The powerbutton is placed at the left side, and it’s just the right thing to play with, mindlessly, while thinking. This leads to the laptop suspending, of course! The device is heavy, too, too heavy to comfortably use as a tablet. As a laptop, except for the keyboard, it’s pretty good. Linux compatibility is weird: you can either have the trackpad properly supported, or the wifi adapter, but not both. Not even with the latest Kubuntu! There’s no pen, which is a pity…

I cannot talk about the what’s in the Intel SDP system, because that’s under NDA. It’s got a pen, just like the Surface Pro 3, and it’s nice, light and a good harbinger of things to come. The form factor works fine for me. Some people are bothered by feeling the keys at the back of the device when it’s in tablet mode, but I don’t care. Tent mode nice for watching movies, and presentation mode sort of makes it a nice drawing tablet.

The Surface Pro 3 is rather new. I got it as test system for Krita on Windows. It’s the lowest spec model, because that makes the best test, right? I can use the thing on my lap, with the kickstand, but only if I put my feet up on the table and make long legs… The n-trig pen is sort of fine… It’s accurate, there’s no parallax as with the Cintiq or Helix, the pressure levels are fine, too, for my usage that is. But because it’s a bluetooth device, there’s a noticable delay. It’s a bit as if you’re painting with too thick oil paint. I never remove the keyboard cover, which, btw, is perfectly fine to type on. It feels a bit tacky, folded back, but not a big problem.

So that’s it… Four convertible laptops, three have trouble running Linux at the moment, but then, I should do more testing of Krita on Windows anyway. It’s where 90% of Krita’s user base is, it seems. I’d like the Dell way of converting best, if the device weren’t so heavy as a consequence. The Helix convertible never gets turned into a pure tablet in practice; that seems to go with the rip’n’flip design, because the same holds for the Surface Pro 3. The back-bendy type of convertible is just fine as well…