Too much of a good thing

So the last couple of months, after our return from Italy, were nicely busy. At the day job, we were getting ready to create an image to send to the production facility for the QML-based embedded application we had been developing, and besides, there were four reorganizations in one month, ending with the teams being reshuffled in the last week before said image had to be ready. It was enough pressure that I decided to take last week off from the day job, just to decompress a bit and focus on Krita stuff that was heaping up.

Then, since April, Krita-wise, there was the Kickstarter, the kick-off for the artbook, the Krita 3.0 release… The 3.0 release doubled the flow of bugs, donations, comments, mails to the foundation, questions on irc, reddit, forum and everywhere else. (There’s this guy who has sent me over fifty mails asking for Krita to be released for Windows XP, OSX 10.5 and Ubuntu 12.02, for example). And Google Summer of Code kicked off, with three students working on Krita.

And, of course, daily life didn’t stop, though more and more non-work, non-krita things got postponed or cut out. There were moments when I really wanted to cancel our bi-weekly RPG session just to have another Monday evening free for Krita-related work.

I don’t mind being busy, and I like being productive, and I especially like shipping: at too many day jobs we never shipped, which was extremely frustrating.

But then last Wednesday evening, a week ago, I suddenly felt queer after dinner, just before we’d start he RPG session. A pressing, heavy pain on my breast, painful upper arms, sweating, nausea, dizziness… I spent the next day in hospital getting checked for heart problems. The conclusion was, it wasn’t a heart attack, just was all the symptoms of one. No damage done, in any case, that the tests could figure out, and I am assured they are very acccurate.

Still, I’m still tired and slow and have a hard time focusing, so I didn’t have time to prepare Krita 3.0.1. I didn’t manage to finish the video-export refactoring (that will also make it possible to pass file export configurations to Krita on the command line). I also didn’t get through all the new bugs, though I managed to fix over a dozen. The final bugs in the spriter export plugin also are waiting to be squashed. Setting up builds for the master branch for three operating systems and two architectures was another thing I had to postpone to later. And there are now so many donations waiting for a personal thank-you mail that I have decided to just stop sending them. One thing I couldn’t postpone or drop was creating a new WBSO application for an income tax rebate for the hours spent on the research for Krita’s scripting plugin.

I’m going forward with a bit of reduced todo list, so, in short, if you’re waiting for me to do something for you, be aware that you might have to wait a bit longer or that I won’t be able to do it. If you want your Krita bug fixed with priority, don’t tell me to fix it NOW, because any kind of pressure will be answered with a firm nolle prosequi.

Appimages, Snaps, XDG-Apps^WFlatpaks

Lots of excitement… When Canonical announced that their snaps work on a number of other Linux distributions, the reactions were predictable, sort of amusing and missing the point.

In the end, all this going back and forth, these are just turf wars. There are Redhat/Fedora people scared and horrified that Canonical/Ubuntu might actually set a standard for once, there are probably Canonical/Ubuntu people scared that their might not set a standard (though after several days of this netstorm, I haven’t seen anything negative from their side, there are traditional packagers worried that the world may change and that they lose their “curating” position.

And there’s me scared that I’ll have to maintain debs, rpms, flatpaks, snaps, appimages, OSX bundles, MSI installers, NSIS installers and portable zips. My perspective is a bit that of an outsider, I don’t care about the politics, though I do wish that it isn’t a dead certainty that we’ll end up having both flatpaks (horrible name, by the way) and snaps in the Linux world.

Both the Canonical and the Fedora side claim to be working with the community, and, certainly, I was approached about snap and helped make a Krita snap. Which is a big win, both for me and for snap. But both projects ignore the appimage project, which is a real community effort, without corporate involvement. Probably because there is no way for companies to use appimage to create a lock-in effort or chance monetization, it’ll always be a community project, ignored by the big Linux companies.

Here’s my take, speaking a someone who is actually releasing software to end users using some of these new-fangled systems.

The old rpm/deb way of packaging is excellent for creating the base system. For software where having the latest version doesn’t matter that much for productivity. It’s a system that’s been used for about twenty years and served us reasonably well. But if you are developing software for end users that is regularly updated, where the latest version is important because it always has improvements that let the users do more work, it’s a problem. It’s a ghastly drag having to actually make the packages if you’re not part of a distribution, and having to make packages for several distributions is not feasible for a small team. And if we don’t, then when there are distributions that do not backport new versions to old releases because they only backport bugfixes, not releases, users lose out.

Snap turns out to be pretty easy to make, and pretty easy to upload to Ubuntu’s app store, and pretty easy to find once it’s there, seeing that there were already more than a thousand downloads after a few days. I don’t care about the security technology, that’s just not relevant for Krita. If you use Krita, you want it to access your files. It takes about five minutes to make a new snap and upload it — pretty good going. I was amazed and pleased that the snap now runs on a number of other distributions, and if Canonical/Ubuntu follows up on that, plugs the holes and fixes the bugs, it’ll be a big plus. Snap also offers all kinds of flexibility, like adding a patched Qt, that I haven’t even tried yet. I also haven’t checked how to add translations yet, but that’s also because the system we use to release translations for Krita needs changing, and I want to do that first.

I haven’t got any experience with flatpak. I know there was a start on making a Krita flatpak, but I haven’t seen any results. I think that the whole idea of a runtime, which is a dependency thing, is dumb, though. Sure, it’ll save some disk space, but at the cost of added complexity. I don’t want that. For flatpak, I’ll strike a wait-and-see attitude: I don’t see the need for it, but if it materializes, and takes as little of my time as snap, I might make them. Unless I need to install Fedora for it, because that’s one Linux distribution that just doesn’t agree with me.

Appimages, finally, are totally amazing, because they run everywhere. They don’t need any kind of runtime or installation. Creating the initial AppImage recipe took a lot of time and testing, mainly because of the run-everywhere requirement. That means fiddly work trying to figure out which low-level libraries need to be included to make OpenGL work, and which don’t. There might be bumps ahead, for instance if we want to start using OpenCL — or so I was told in a comment on LWN. I don’t know yet. Integration with the desktop environment is something Simon is working on, by installing a .desktop file in the user’s home directory. Sandboxing is also being worked on, using some of the same technology as flatpak, apparently. Automatic updates is also something that is becoming possible. I haven’t had time to investigate those things yet, because of release pressures, kickstarter pressures and all that sort of thing. One possible negative about appimages is that users have a hard time understanding them — they just cannot believe that download, make executable, go is all there’s to it. So much so that I’ve considered making a tar.xz with an executable appimage inside so users are in a more familiar territory. Maybe even change the extension from .appimage to .exe?

Anyway, when it comes to actually releasing software to end users in a way that doesn’t drive me crazy, I love AppImages, I like snap, I hate debs, rpms, repositories, ppa’s and their ilk and flatpak has managed to remain a big unknown. If we could get a third format to replace all the existing formats, say flatsnapimage, wouldn’t that be lovely?

Wouldn’t it?

Running Krita Snaps on Other Distributions

This is pretty cool: in the week before the Krita release, Michael Hall submitted a snapcraft definition for making a Krita snap. A few iterations later, we have something that works (unless you’re using an NVidia GPU with the proprietary drivers). Adding Krita to the Ubuntu app store was also really easy.

And now, if you go to snapcraft.io and click on a Linux distribution’s logo, you’ll get instructions on how to get snap running on your system — and that means the snap package for Krita can work on Arch, Debian, Fedora, Gentoo — and Ubuntu of course. Pretty unbelievable! OpenSUSE is still missing though…

Of course, running a snap still means you need to install something before you can run Krita while an AppImage doesn’t need anything making it executable. Over the past month, I’ve encountered a lot of Linux users who just couldn’t believe it’s so easy, and were asking for install instructions 🙂

The 2016 Kickstarter

This year’s kickstarter fundraising campaign for Krita was more nerve-wracking than the previous two editions. Although we ended up 135% funded, we were almost afraid we wouldn’t make it, around the middle. Maybe only the release of Krita 3.0 turned the campaign around. Here’s my chaotic and off-the-cuff analysis of this campaign.

Campaign setup

We were ambitious this year and once again decided upon two big goals: text and vector, because we felt both are real pain points in Krita that really need to be addressed. I think now that we probably should have made both into super-stretch goals one level above the 10,000 euro Python stretch goal and let our community decide.

Then we could have made the base level one stretch goal of 15,000 euros, and we’d have been “funded” on the second day and made the Kickstarter expectation that a succesful campaign is funded immediately. Then we could have opened the paypal pledges really early into the campaign and advertise the option properly.

We also hadn’t thought through some stretch goals in sufficient depth, so sometimes we weren’t totally sure ourselves what we’re offering people. This contrasts with last year, where the stretch goals were precisely defined. (But during development became gold-plated — a 1500 stretch goal should be two weeks of work, which sometimes became four or six weeks.)

We did have a good story, though, which is the central part of any fundraiser. Without a good story that can be summarized in one sentence, you’ll get nowhere. And text and vector have been painful for our users for years now, so that part was fine.

We’re also really well-oiled when it comes to preparation: Irina, me and Wolthera sat together for a couple of weekends to first select the goals, then figure out the reward levels and possible rewards, and then to write the story and other text. We have lists of people to approach, lists of things that need to be written in time to have them translated into Russian and Japanese — that’s all pretty well oiled.

Not that our list of rewards was perfect, so we had to do some in-campaign additions, and we made at least one mistake: we added a 25 euro level when the existing 25 euros rewards had sold out. But the existing rewards re-used overstock from last year, and for the new level we have to have new goodies made. And that means our cost for those rewards is higher than we thought. Not high enough that those 25 euros pledges don’t help towards development, but it’s still a mistake.

Our video was very good this year: about half of the plays were watched to the end, which is an amazing score!

Kickstarter is becoming a tired formula

Already after two days, people were saying on the various social media sites that we wouldn’t make it. The impression with Kickstarter these days is that if you’re not 100% funded in one or two days, you’re a failure. Kickstarter has also become that site where you go for games, gadgets and gags.

We also noticed less engagement: fewer messages and comments on the kickstarter site itself. That could have been a function of a less attractive campaign, of course.

That Kickstarter still hasn’t got a deal with Paypal is incredible. And Kickstarter’s campaign tools are unbelievably primitive: from story editor to update editor (both share the same wysiwyg editor which is stupidly limited, and you can only edit updates for 30 minutes) to the survey tools, which don’t allow copy and paste between reward levels or any free text except in the intro. Basically, Kickstarter isn’t spending any money on its platform any more, and it shows.

It is next to impossible to get news coverage for a fundraising campaign

You’d think that “independent free software project funds full-time development through community, not commercial, support” would make a great story, especially when the funding is a success and the results are visible for everyone. You’d think that especially the free software oriented media would be interested in a story like this. But, with some exceptions, no.

Last year, I was told by a journalist reporting on free and open source software that there are too many fundraising campaigns to cover. He didn’t want to drown his readers in them, and it would be unethical to ignore some and cover others.

But are there so many fundraisers for free software? I don’t know, since none get into the news. I know about a few, mostly in the graphics software category — synfig, blender, Jehan’s campaign for Zemarmot, the campaign by the Software Freedom Conversancy, KDE’s Randa campaign. But that’s really just a handful.

I think that the free and open source news media are doing their readers a disservice by not covering campaigns like ours; and they are doing the ecosystem a disservice. Healthy, independent projects that provide software in important categories, like Krita, are essential for free software to prosper.

Exhaustion

Without the release, we might not have made it. But doing a Kickstarter is exhausting: it’s only a month, but feels like two or three. Doing a release and a Kickstarter is double exhausting. We did raise Krita’s profile and userbase to a whole other level, though! (Which also translates into a flood of bug reports, and bugzilla basically has become unmanageable for us: we need more triagers and testers, badly!)

Right now, I’d like to take a few days off, and Dmitry smartly is taking a few days off, but there’s still so much on my backlog that it’s not going to happen.

I also had a day job for three days a week during the campaign, during which I wasn’t available for social media work or promo, and I really felt that to be a problem. But I need that job to fund my own work on Krita…

Referrers

Kickstarter lets one know where the backers are coming from. Kickstarter itself is a source of backers: about 4500 euros came from Kickstarter itself. Next up is Reddit with 3000 euros, twitter with 1700, facebook 1400, krita.org 1000 and blendernation with 900. After that, the long tail starts. So, in the absence of news coverage, social media is really important and the Blender community is once again proven to be much bigger than most people in the free software community realize.

Conclusion

The campaign was a success, and the result pretty much the right size, I think. If we had double the result, we would have had to find another freelancer to work on Krita full-time. I’m not sure we’re ready for that yet. We’ve also innovated this year, by deciding to offer artists in our communities commissions to create art for the rewards. That’s something we’ll be setting in motion soon.

Another innovation is that we decided to produce an art book with work by Krita artists. Calls for submissions will go out soon! That book will also go into the shop, and it’s kind of an exercise for the other thing we want to do this year: publish a proper Pepper and Carrot book.

If sales from books will help fund development further, we might skip one year of Kickstarter-like fund raising, in the hope that a new platform will spring up that will offer a fresh way of doing fund raising.

Cross-compiling Krita using MXE

Writing code that builds with multiple compilers is good way to catch errors, improve code quality and conformance. Or so I have always been taught. Hence, when we ported Krita to Windows, we ported it to the native compiler for Windows, Microsoft Visual C++. That took some doing, but in the process we found lots of little things that, once fixed, improved Krita’s code. When we ported Krita to OSX, where the native compiler is clang, the same happened.

And then we added two dependencies to Krita that have trouble with Visual C++: G’Mic and Vc. G’Mic implements a parser for a custom scripting language for writing filters, and that parser is written in a way that makes life really hard for Visual C++. Basically, the 32 bits builds never worked and the 64 bits builds need a stack of about a gigabyte to parse the scripts. And Vc, a library to add vectorization/simd support easily, from version 1.0 and up just doesn’t build at all on Windows.

It’s probably not a coincidence that both are heavy users of templates, and in the case of Vc, of C++11. But Krita needs both libraries: our users love all the filters and tools the G’Mic plugin gives them, and without Vc, our brushes and pixel compositing code becomes really slow.

What could we do? Hair was liberally pulled and not a few not unmanly tears shed. We could try to build Krita on Windows using one of the GCC ports, or we could try to build Krita on Windows using clang. We already tried to use Intel’s icc to build Krita, but that broke already when trying to build Qt. (Though that was in the early Qt 4 days, so maybe things are better now.)

But building on Windows will always be slower, because of the slow terminal and the slow file system, and we know that the Windows releases of Gimp and LibreOffice are actually built on Linux. Cross-compiled for Windows. If complex projects like those can manage, we should be able to manage too.

Unfortunately, I’m a bear^Wdeveloper of very little brain, and figuring out which blogs and articles are up to date and relevant for OpenSUSE Leap was already quite hard, and when I saw that the mingw packages for Leap were a year old, I wasn’t prepared to even put a lot of time into that.

Enter MXE. It’s a kind of KDE’s emerge, but for Linux, a bunch of Makefiles that can make a cross-platform build. It comes with a huge bunch of pre-configured libraries, though Unfortunately not everything we need.

So, using MXE, I built Qt and most dependencies. Still missing are Vc, OpenColorIO, GSL, Poppler-qt5 and openjpeg. I also needed to remove some of the hacks we did to make Krita compile with MSVC: we had added a couple of dummy header files to provide things like nothl and friends (these days superseded by QtEndian). A 3rd-party library we embed, xcftools, had its own equivalent of that stuff. But apart from that…

Everything mostly built out of the box, and the result runs in Wine (as evidenced by the “native” file dialog:

What’s left to do? Build the remaining dependencies, add translations, create a packaging script (where’s windeployqt?), and test.

Krita AppImages

Years and years ago, before Krita had even had one single official or unofficial release, we created something called “klik” packages. Basically, an iso that would contain Krita and all its dependencies and that could be used to run Krita on any Linux distribution. The klik packages were quite hard to maintain and hard-ish to use, though. It was easier than trying to build rpm’s for SuSE, Redhat, Mandrake, debs for Debian, PKG for Slackware and whatever else was out there, though.

Fast-forward a decade. Despite advances like Launchpad and the OpenSuse OBS, it’s still hard to create Krita packages for every distribution. There are more distributions, more versions, more architectures… Just maintaining the Krita Lime PPA for Ubuntu and derivatives takes a serious amount of time. Basically, the problem of distributing ones application to Linux users is still a problem.

And if you’re working on even a moderately popular application that has a moderate development velocity, if it’s an application that users rely on to do their job, you really want to provide your work in a binary form.

Distributions do a good job combining all the software we free software developers write into distribution releases; distributions really make it easy and convenient to install a wide range of applications. But there is a big mis-match between what users need and what they get:

Most users want a stable, unchanging operating system that they can install and use without upgrading for a couple of years. On top of that, some users don’t want to be bothered by desktop upgrades, others cannot live without the latest desktop. That’s often a personal preference, or a matter of not caring about the desktop as long as it can launch their work applications. And those work applications, the production tools they use to earn their money with, those need to be the very latest version.

So, Krita users often still use Ubuntu 12.04. It’s the oldest LTS release that’s still supported. But Ubuntu doesn’t support it by providing the latest productivity applications on top of the stable base, not even through backport ppa’s and if you use the Ubuntu-provided Krita, you’re stuck in what now feels like the dark ages.

Enter the spiritual successor of Klik: AppImage. AppImages sprang into the limelight when they got Linus Torvalds’ Seal of Approval. That distributing software on Linux is problematical has been a thorn in his eye for a long time, and when particularly when he started working on an end-user application: Subsurface. When the person behind AppImage created a SubSurface package, that resulted in a lot of publicity.

And I contacted Simon to ask for help creating a Krita AppImage. After all, we are in the middle of working up to a 3.0 release, and I’d like to be able to produce regular development builds, not just for Windows and OSX, but also for Linux.

Krita’s AppImage is built on CentOS 6.5 using a long bash script. It updates CentOS using the Epel repository so we get a reasonably recent Qt5, then installs an updated compiler, gets Krita, installs dependencies, builds dependencies, builds krita, checks all the output for their dependencies, copies them into a tree, edits eveyrthing to look for dependencies locally instead of on the system and packages it up with a small executable that runs the Krita executable. The one thing that was really hard was figuring out how to integrate with the GPU drivers.

You can get the recipe here: https://github.com/boudewijnrempt/AppImages/blob/master/recipes/krita/Recipe.

There are some refinements possible: AppImage offers a way to update AppImages by only downloading and applying a delta, which we don’t support yet. It’s possible to setup a system where we can generate nightly builds, but I haven’t figured out the combination of docker, travis and github that supports that yet, either. And Simon is working on an improved first-run script that would ask the user whether they would like to have some desktop integration, for instance for file handling or menu integration. All of that is in the future. There are also a handful of distributions that disable fuse by default, or close it for non-root users. Unfortunately, CentOS is one of them…

For now, though, it’s really easy to generate binaries that seem to run quite well on a wide variety of Linux distributions, that performs just like native (well, the packages is native), are easy to download and run. So I’m ready to declare “problem solved!”

A Week in the Life of a Krita Maintainer

Sunday, 10th of January

Gah… I shouldn’t have walked that much yesterday… It was fun, to see A’s newborn daughter, A, and then we went to Haarlem to buy tea and have dinner. But with a nasty foot infection, that wasn’t wise. So, no chance of serving in church today. Which means… More Krita time! Around 9:30 started the first OSX build, CentOS build and Windows build, time to try and figure out some bug fixes. Also, reply to forum posts and mails to foundation@krita.org… And prepare review requests for making Krita .kra and OpenRaster .ora images visible in all Qt applications, as images and thumbnails. Fix warnings in the OSX build. Fix deprecated function calls everywhere. Yay! Wolthera and Scott start cleaning up color stuff and the assistants gui. Dinner.

Monday, 11th of January.

Dammit, still cannot walk. But that means… More Krita time! I’m missing a whole day of income, being a small, independent enterpreneur, but I’ve got a better chance of fixing those Windows, OSX and Linux builds. Looks like OSX works fine now, Windows sometimes, but there’s still something wrong with the Linux builds. I think we need more people in our project, people who like making builds and packages, so I can go back to bug fixing. Bug fixes… Let’s fix the CentOS build issue by dropping the desktop file to json file conversion build-time. Fix a memory leak in the jpeg filter, been there for ages. Make it possible to load and save GBR and GIH brushes! Kickstarter feature lands! Not with the big rewrite of our import/export system I’d wanted to do, but it’s better now than it was, import/export can specify a mapping from filename extension to mimetype, so we can load files that the shared desktop’s mime database doesn’t know about yet. Break selecting the right style and theme — oops! Finally fix the unreadable Close button on the splash screen (when the user used a light-colored theme). User-support mail, forum posts, irc chat… Dmitry adds cut, copy and paste of layers, another kickstarter feature! Yay!!! Tonight is roleplaying night, need to prepare the adventure for my players, with maps. (Session report is here.)

Tuesday, 12th of January

Six-forty-effing-five. Alarm clock. I was dreaming of Qt builds going awry, so probably a good time to get up. Erm… Mail, more mail, and forum posts during breakfast. Orange juice, coffee, tea. Off to the railway station around 7:40. Do a couple of Italian lessons with Duolingo while waiting for the train to arrive, interspersed with Facebook Page Manager community management moments. On the train. Sleepy! Time to start working on our OSX port. Beelzy did an awesome job providing me with lots of patches, now they need to be integrated. Cool, Dmitry doing lots of cleanups! But where did Nimmy go? We really need his patch to make Krita work on OSX… Ah! And there’s the bad boy, we accidentally had the wrong application icon. Let’s remove that one, and use ours instead. And then 9:12, arrival in Duivendrecht. 9:25, arrival at the day job — Krita cannot pay my bills yet, so I’m working on a QtQuick1 to QtQuick2 port for a Dutch home automation company. Work, work, work, without a break, until 17:30, when it’s time to go back to the train. Dinner — and yay! Smjert has got his setup fixed and is fixing bugs again. Users keep mailing foundation@krita.org with support questions, and I’m just too nice… Answered. Time to go to bed, around midnight.

Wednesday, January the 13th

Exciting! Windows builds and OSX builds were working last Sunday, and today the Linux appimage builds are working on most systems! We might be able to release the pre-pre-pre-pre-pre-alpha tomorrow! And we’re creating the correct OSX application bundles, with icon! And Timothee has fixed the icon, and Jouni has started implementing importing image sequences as animations! And the alarm clock buzzed me at 6:45. Wait, that’s not yay-worthy. Refactor the PNG export dialog a bit. Work, work, work. I realize that after three months I’m one of the people at this office who’s been here longest. There are ten people who’ve been here for more than six months, twenty who’ve been here for six to three months and it seems there’s a legion who’ve just started… Fix the top toolbar sliders. And I’ve got extra-double-plus long hacking time on the train because the track is blocked and I have to make a detour via Zwolle. No, tonight I’m not going to finish the release notes or the fixed Windows (OpenGL is broken. wth), OSX and Linux packages. Time for dinner, a bath and bed. And all kickstarter rewards except for some shirts have arrived!

Thursday, January the 14th.

Gah, six colon four five. Time to get up. And I was dreaming of a bunch of kittens playing in a hay-loft that was being converted into yuppie student housing. Must be significant or something. At least I wasn’t trying to form keys out of my pillow cover so I could type “./configure” in the qt source directory, which is what my mind tried to make me do last night. Oooh! Ben Cooksley has enabled docs.krita.org, our new manual home! Exciting! People having trouble with preset files, photoshop files, krita files. Let’s try to offer a helping hand, while guzzling orange juice, tea and coffee. Dmitry adds multi-node editing of layer properties, Wolthera fixes canvas rotation. A british VFX studio tries Krita and the artists are excited — must not forget to follow-up Layer property shortcuts, drag&drop in tabbed mode and more gets pushed by Dmitry. At work, there are meetings, and more meetings. The train home fortunately isn’t delayed, because we’ve got our priest and his wife for dinner. After dinner, I go out for a beer with our priest. The barlady wonders what kind of a monk he is, is put right, and later on, after choir practice, our wives join us. No more coding tonight, I’ve had two beers.

Friday, January 15.

My last day on my current contract, but my agenda is full with meetings and things for next week. Next week is also the mini-sprint to prepare the next kickstarter. I’m guessing they’ll want to keep me, we’ll see on Monday. Breakfast. Forum posts. This guy is a bit agressive, though no doubt well-meaning. Mail. Time to get started with the spriter plugin! Jouni fixes the build… I’m fixing OSX stuff left and right, and trying to figure out howto make builds faster, and get them tested. Maybe we can release on Sunday? It’s only a pre-alpha, but still exciting! More forum posts. More work — meetings, it’s the end of our sprint, so sprint review, sprint retrospective, sprint planning…

Saturday, 16 January

I sleep until 9:30. Well, I wake up at seven, but then go back to snoozing and dreaming of the comic book scenario that’s been whirling around my mind for a while now. It’s going to be cool, if I can sit down and do something about. Fried eggs and bacon. Coffee. Orange juice. Tea. Time to fire up some more builds. Things are falling together! Some preliminary tests by other OSX users shows that my packages are okay, on recent hard, with a range of OSX versions. Figuring out the Linux and Windows builds. Some more bug fixing. Jouni pushes an even more advanced image sequence importer. In the evening, guests, but I’m too tired to go down for the Vigil service, and my foot is aching again. But I did buy new, better shoes and some pullovers, because my old shoes and pullovers were completely gone and tattered. That should help…

Sunday, January 17th.

Getting up at 8:45. Time to check a bit of mail, forward an enquiry about a Secrets of Krita download to Irina. Forum posts. This guy sure posts a lot, but it’s all bug reports. Liturgy, fortunately I can serve. Coffee afterwards, then upstairs and switch on the desktop, the windows laptop and the OSX laptop. Ah! The problem with Intel drivers and OpenGL is the same problem we’ve got on OSX: insufficient support for the Compatibily Profile of OpenGL, which breaks Qt’s OpenGL QPainter engine. Good… There’s a way forward. But first…

RELEASE!!!

The New Laptop

So, some time ago, I was wondering a) what new laptop to get and b) what to do with Krita on OSX. As for the laptop, I felt I wanted something fast, something with at least 16GB of memory and a largish screen. Preferably with a good keyboard. As for OSX, I felt it might not be worth either mine or the Krita Foundation’s money to plunk down the serious moolah that Apple is asking for their hardware… After all, how many people fall for Apple’s glamourie, in the real world, after all? Especially now that the reality distortion field’s progenitor is no longer among us.

Then I did an interview with CGWorld’s Jim Thacker, about Krita. He’s very much someone from the graphics software world, not the free software world. And he expressed his amazement at my dismassal of Apple. And then my bank account was getting seriously empty, and I had to take a temporary consulting gig to make sure I could continue paying my mortgage. And at the place I’m working now, and in the commuter train I’m travelling on, more than half of the people have Apple laptops.

I don’t know why… And I guess they don’t know why, either. Well, Windows has always been kind of ugly, especially Windows 7 and 10. Windows 8 I really liked, by the way — if you have a touch screen, the interaction design is simple, effective and efficient. Everything is consistent, easy and pleasant. The few metro apps I used, I loved. But, well, Apple. Apparently more people than I was able to imagine think getting an Apple laptop is a good idea.

So, all together, I decided to go and get an Apple laptop, too. Let’s try to make Krita 3.0’s OS X port a first-class citizen! It can only expand our community and make our next fundraiser stronger!

So we got a 15″ Macbook Pro Retina. Not the most expensive model, but it was still plenty expensive. More than a thousand cups of coffee. Here’s what I think of it, after a month or so.


What follows now is part hardware, part software review. I guess I need to state up-front that while I’m a long-time free software person, I’ve never been an Apple hater any more than a Microsoft hater. Or lover. I’ve used or owned three Apple computers before this one.

The first was a Powerbook Pismo I got when Tryllian went broke and the artist department was disbanded. That thing had a great screen, a great keyboard (apart from the missing keys), a great shape and style, ran OS 9 and OS X equally well. I had wanted one of the tiBooks, but they were all broken. The Pismo served me for a long time as a writing machine, as a holiday games, music and photo machine, as a Krita development machine (it dual-booted to Debian). I loved it, and then a clumsy daughter tripped over the power cable, causing it to drop nearly half a meter, onto the floor. It sparked and smoked whenever I applied current to it afterwards, so I discarded it.

Sadness! But when I started working for Hyves, I got a first generation 17″ macbook pro. Still a thoroughly respectable keyboard (apart from the missing keys), great screen, really fast. And using an Apple laptop was sort of inevitable, since at Hyves we were developing a cross-platform chat client for the Hyves social network. Hyves was the Dutch Facebook, by the way. It’s dead now. So was the Macbook Pro, after a year. After a year in my backpack the screen started developing vertical green, red and blue lines. Actually… It was the second device Hyves got me, the first one was dead on arrival. Still, it had a decent keyboard.

At KO GmbH, one of our less well-considered ventures was to develop a WebODF-based app for the iPad. To that end, we got an iPad and a 2011 Mac Mini. The iPad is still with Jos, but after a while, building Krita for OSX also seemed a good idea, so I got the Mac Mini. It’s got a nice amount of memory, 8GB, and the disk is exceedingly roomy, at 1TB. But… The disk is also really slow, and the Krita hack, build, deploy, test, hack again cycle could easily take an hour! Which is the reason I never really did much Krita on OSX hacking since the 2014 kickstarter, when I first ported Krita to OSX.

(The keyboard I use with the Mac Mini, by the way, is more than excellent. It’s a WASD custom-built keyboard, and I bought it for using with the Thinkstation desktop machine. It’s got a penguin key.)


So, time for the fourth Apple computer. My needs were:

  • Fast
  • Large screen
  • Good keyboard

Two out of three isn’t bad… Except for a laptop that costs more than 2000 euros. I got a 15″ Macbook Pro with a 256Gb SSD. For only about 500 euros more, I would have had a bigger disk, and the disk on this laptop is already fullish, what with two Linux and one Windows virtual machines and an OSX build tree or two.

So, what’s good? The screen is really good, sharp, clear, excellent color, unless you turn the brightness down. It’s not as clear and sharp as the Dell XPS 12 screen, but it doesn’t have the Dell’s ghosting problem. And if you turn the brightness down? The contrast goes down and the colors go down and it looks washed out.

Unfortunately, it isn’t a touch screen, which frustrates me, because I have gotten used to direct interaction in the past couple of years. I also don’t get the way Apple uses display scaling, but that’ll come, no doubt. It seems to me that if you just blow up ever pixel to four pixels the result isn’t really sharper, but somehow it is, for text at least.

It’s also fast. It builds Krita faster than my desktop workstation, which is really impressive. And useful, because apart from writing mail, handling bugs and irc, building Krita is pretty much what I do. Oh, and a little coding…

For the coding, I need a good keyboard, and that’s where this laptop falls down.

The keyboard is ghastly. Honestly. The only reason anyone can think it’s adequate is because they are too young to have used really good keyboards on laptops.

Not only does it still miss Home, End, PgUp, PgDn and Delete (the key Apple labels as Delete is Backspace), the keys have next to no travel. Yes, I get it, thin is the new black. But not when it impairs my productivity. The keys are little black squares of sharp-edged plastic with no shape. And they are also sort of wobbly.

As on Thinkpads, Fn and Control are reversed. Which makes the remarks you read now and then from people who’ve chosen to buy Apple instead of Lenovo because of the Fn key position rather silly.

Because of the lack of Home and End, and because of Apple’s confusion about what those keys should do, it gets really tricky to navigate to the start or end of a line, something which anyone who codes does all the time. You need a different key combination in the shell, in vi, in Qt Creator, in TextMate, everywhere! I am a fast touch typist, but I am having to look under my left hand at the block of Fn, Control, Option and Command all the time to hit the right combination. I still cannot switch between the browser and the terminal and remember the shortcut to move to the next or previous tab, they are different! Honestly, I am not making this up.

The other thing that’s below par, though probably related to the “really fast” bit, is the battery life. Two hours of coding and building will drain the battery down to about 40%. When building in a Windows VM and in OSX at the same time, the charger seems to have a hard time keeping up. I saw the battery drain while it was plugged in. No, I’m not asking you to believe me, I don’t believe myself either.

There are other niggles about the hardware: the laptop gets really hot (again probably related to the “really fast”…), the edges are sharp, the power button is where my little finger expects the delete button. The aluminum case is really prone to scratches, even the plastic zipper of my laptop bag manages it.

But actually, Apple’s design is one reason I didn’t want to wait another six months for the updated model. Just imagine a Macbook Pro that is remodeled after the Macbook redesign, with keys with all of two-tenths of a milimeter of travel! Better live for a bit with an older processor.

Now for the other part of the deal…

Software

The software. OSX. It’s an operating system. Not a particularly brilliant one, but it does run applications. And it’s got a gui with a a window manager. A particularly aenemic window manager that needs extensions to tile windows left and right, but that’s getting “modernized” by making it more like a tablet. In the El Capitan version, it really, really, really wants you to run your applications full-screen. Okay. It’s a bit stupid that from version to version the meaning of the title bar button changes, apparently randomly, too.

What is also quite irritating is the bunch of crap extra applications that take up space and are completely useless to me: safari, garageband, imovie, pages, keynote, itunes and so on. I wonder if I can just trash them…

As a development platform, OSX sucks, too, with limited OpenGL support, huge crippling changes between versions and horrible developer documentation. Oh, and a bunch of proprietary languages and API’s that nobody in their right mind would even consider learning, because they are bound to be deprecated just when they get established.

Conclusion

The short version: I still take the Dell XPS 12 with me on the train most days. It’s slow, small, the keyboard is lacking, and it’s still a more usable computer. If that isn’t a damning indictment, I don’t know what is.

The slightly longer version: the only valid reason to buy an Apple computer is because you need to write software for OSX or iOS, in other words, to provide the people who didn’t have a valid reason to get an Apple with software.

Coda

I bought this laptop from a website with a .nl extension. The website was in Dutch. It’s no doubt being maintained by people who live in the Netherlands and pay income tax in the Netherlands. After ordering it, it was manufactured in China, and shipped from Shanghai to Korea, from Korea to Kazachstan, from Kazachstan to Germany, from Germany to the Netherlands. And then to me. I paid VAT in the Netherlands. At no point in the buying of this piece of crap was Ireland involved.

Except that Ireland’s where the bill was ostensibly coming from.

Tim, me boy, you sell a crap OS on a crap piece of hardware and you’re cheating my country of the tax income it needs, which I and the other Dutch people then need to make up, just so you can sit on a pile of cash big enough to make all of Africa into an affluent continent. If you were an honest dealer, my tax burden would be lower and my laptop would, presumably, be better. And so would the world. Time to think different?

Release date for Krita 2.9

After a short discussion, we came up with a release date for Krita 2.9! It’s going to be… February 26th, Deo volente. Lots and lots and lots of new stuff, and even the old stuff in Krita is still amazing (lovely article, the author mentions a few features I didn’t know about).

Then it’s time for the port to Qt5, while Dmitry will be working on Photoshop-style layer styles — a kickstarter feature that didn’t make it for 2.9.0, but will be in 2.9.x. A new fundraiser for the next set of amazing features is also necessary.

Of course, there are still over 130 open bugs, and we’ve got a lot to do still, but then the bugs will always be with us, and after 2.9.0 a 2.9.1 will surely follow. But I do care about our bug reports.

Some people feel that in many projects, bugreports are often being discarded in an administrative way, but honestly, we try to do better! Because without user testing and bug reporting, we won’t be able to improve Krita. After all, hacking on Krita takes so much time that I hardly get to use Krita for more than ten, twenty minutes a week!

We fixed, closed or de-duplicated 91 bugs in the past seven days. Of course, we also got a bunch of new bug reports: 25.

So, I want to take a bit of time to give a public thank-you to all our bug reporters. We’ve got an awesome bunch of testers!

For example, one tester has reported 46 bugs against the 2.9 betas: that is a pretty amazing level of activity! And we have by now fixed 33 of these 46 bugs. By testing betas and painstakingly carefully reporting bugs, often with videos to help us reproduce the issue, Krita has become so much better.

If you use Krita and notice an issue, don’t think that you’ll hurt us when you report the issue as a bug — the only thing we ask from you is that you do a cursory check whether your bug has already been reported (if it isn’t immediately obvious, report away, and if it’s been reported before, no problem), and that we can come back to you with questions, if necessary.

Master builds for OSX and Windows, an update

So I spent three full days trying to make working builds for OSX and Windows. Mostly OSX, with a side-dish of Windows. Here’s a short update. I’m using this git repository as a build system. It’s basically a set of cmake extern projects, one for each dependency. It’s still a mess, there are definitions for dependencies we no longer need, like glew.

Both on Windows and on OSX, I setup a development tree with this repo, a build directory for the dependencies, an install directory, a download directory and a second build directory for doing Krita development.

I’m using Qt 5.6 alpha, by the way, compiled to exclude dbus and some other things.

OSX

On OSX, there were some weirdnesses: OpenColorIO seems hardcoded to want myptch as a patch command, not just on Windows, but everywhere… That needs patching, of course, or symlinking patch to mypatch.

Eigen3 doesn’t want to build because it needs a dart file for some test setup which we don’t want to build. Patch in the cmake project.

Qt’s macdeployqt needs patching as well, the patch is in the cmake project. After building Qt with -rpath, it became necessary to manually set the rpath on desktop2json: as built by kcoreaddons, it won’t run because it cannot find Qt.

Finally, I managed to build everything including Krita. In order to run Krita, it’s necessary to use macdeployqt to deploy all plugins, libraries and frameworks to the app bundle, and then manually use install_name_tool to add @executable_path/../Frameworks to the rpaths of the executable.

But… Somehow, macdeployqt refuses to deploy the QtNetwork framework out of all Qt frameworks it deploys to the krita.app bundle. No idea why, yet, I had to stop debugging that because it was bedtime… More next weekend, but it is progress.

Windows

On Windows, I use the same kritadeposx repo: the name is wrong. When everything works, I want to add the externals definition to krita’s repo. In any case, with some coaxing, I got most things to build. Almost.

Qt was a bit of a problem: QtDeclarative just doesn’t build with Visual Studio 2015. Not sure why, for now I didn’t need that module.

Then it turned out that ki18n cannot find the gettext executable. I could bull past that by commenting out the line where it looks for it, but then the same happens when trying to configure Krita. It needs more investigation why this happens.

At that point the laptop overheated and shut down and I wasn’t motivated to start it up again, so again more next weekend… With hopefully more progress.