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!
We left really early this morning on the trains to Würzburg, Hannover, Deventer. I was pretty smart, if I may say so, because I gave ourselves half an hour or more time to change trains. Deutsche Bahn is a wonderful institution, but experience has taught me that especially in summertime, 6 minutes are not enough of a safety margin. So we made all our changes, and even had time to lunch in Würzburg.
So, yesterday really was the last day of Akademy for Irina and me. And all of that day was taken up with the fundraising training by Florian Engel. And it was worth it! Oh, gosh, wake me up in the middle of the night and ask me whether it was worth it!
Practical, to-the-point, flexible, engaging, going deep where we needed that, giving examples from outside of free software so we were all getting new ideas just from those examples. I need to prepare my notes for a discussion during Krita’s Monday meeting, about our September campaign, software platform, and donation page…
For the rest, it was great to meet so many people I hadn’t seen for way too long, including Inge Wallin, with whom I, back in the Nokia days, had founded KO GmbH. Or people I work with every day, but had never met, like Ben Cooksley. Productive discussions about things as diverse as debug symbols in appimages or ways to attract and retain new contributors. Meeting and sitting down with Eliakin, my 2017 student, was awesome as well; pity KDE is so busy that we couldn’t spend more time together!
I went to Akademy feeling that the relationship been Krita and KDE is kinda difficult. Krita is part of KDE, but at the same time, Krita is getting really big. We’re using up quite a chunk of bandwidth, after plasmashell, we’re the project with the second-most bugs reported per year, and still people working on Krita don’t have much of a tie to KDE, and people working on KDE seldom have much of an idea what’s going on in Krita — other than nodding and telliing me Krita is one of KDE’s flagship projects. Sure it is, and I got very much reassured that we’re not using too large a chunk of KDE’s resources, and could even use more. I’m not sure how to “fix” this, if a fix is possible. If we’d have our Krita sprint during Akademy, I’m sure that would help — but it would also be a pretty improductive sprint for Krita.
Tomorrow, there’s the fund raiser training session. Given that we’ve been raising funds for Krita since time immemorial (our first fund raiser was for two Wacom tablets and art pens so we could implement support for them, the second to let Lukas Tvrdy work on Krita for a couple of months and after that, we’ve had the kickstarters), that might seem superfluous. But I’m still hoping to learn lots. After all, it’s not like we’re exactly awash in money.
But today, we, me and Irina, we went all-out for a day in Vienna. Just took the day off, had a lazy morning with breakfast in the hotel room (tea and croissants…), then took the underground to the Karlsplatz. From there, it was an easy walk to the KHM. Vienna is quite compact.
One thing I love about Vienna is the ubiquitous availability of non-sugary soft drinks. That is, soda zitrone — sparkling water with lemon juice. Half a litre of that in the museum cafe rehydrated us sufficiently to go out and see the parts that we hadn’t seen before. The French/Italian/Spanish parts of the museum are not as paralyzing as the Flemish/German/Dutch parts, but there was plenty! In particular, the three portraits of the Infanta of Spain, at ages 4, 6, 8 (or thereabouts) were touching. Gramps, being the Holy Roman Emperor of the German Nation, had asked his son-in-law for regular updates on his little darling grandchild, and got them, painted by Velasquez.
The Roman/Greek/Egyptian part was curious more than impressive: quantity over quality, perhaps, but still, interesting. It’s also the most unreconstructed part of the museum, with the exhibits often being labeled only in type-written German, on yellowing paper.
Having gone through that section, we were conveniently close to the museum cafe again, where they do serve excellent food. So we lunched there, then went back to our favourites in the dutch/flemish/german paintings sections. I spent half an hour with Rogier van der Weyden again, and if there wouldn’t be that fundraising workshop tomorrow, I would spend an hour in that room again, tomorrow. But we’ve got a year pass and we will return. I like the KHM better than the Bodemuseum in Berlin… There were other paintings I have stared at, trying to remember all of it, like the Reynolds in a little side-room. I was going all squiggly-eyed, so I decided to try and find Irina.
As I was staggering towards the exit, I suddenly became aware of being spoken at by a clean-shaven person, in what I thought was Danish or Swedish or some other language I don’t speak. It turned out to be one of the other Akademy attendees, a Dutchman. I had so much trouble coming down to earth and realizing that he was speaking a language that I could understand! Afterwards, I felt like a loon.
From there, we went out in search of beer. It was, by now, afternoon, and a warm one. We failed though! First we reached the Treasury. Our year pass is valid there as well, and we had been told the Treasury museum is in the medieval part of the Hofburg. And since the Hofburg is, sorry…, weird, it’s like an ordinary, rather plain, apartment building like you find them all over Vienna, we were like, let’s see what the medieval parts look like!
Well, there wasn’t much of that visible. But the presentation was really pretty good: excellent explanations, impressive exhibits, lots of ancient costumes, too. What I really want to know, though, is: how can textile dating back to the Norman kingdom in Sicily, C12, be as smooth and hale as the socks and tunics and orarion are that are shown? Those 1000-year old swords: how can the steel look like it was forged last year? I’m sure it’s that old, but how has it been conserved and preserved like that?
From there we went on, and found a Kurkonditorei — I guess it’s Kur, because you can only get beer in 0.3 and not 0.5 measures, which must have a slimming effect. Still, the beer was cool, my sandwich was good, Irina’s topfenknodel were good too, or so I have been told, and there were so many interesting people to watch… We had another beer.
And then it was time to go back to the hotel, shower, read mail, go out back to the venue area, find that the Bep Viet restaurant was packed, have a pizza at the pizza place, go back again, and realize that this has been one of the nicest Akademy’s I’ve attended, and that Vienna’s one of the nicest places I’ve visited.
On our arrival, Valorie went to the A&O, where most KDE people went, and Irina and I went to our “apartment”. We like to dine out, but we also like to cook, especially if we’re somewhere where supermarkets carry things that we cannot get in the Netherlands. So, an apartment. Well, City Center Hoher Markt is not really that kind of apartment. Three sparsely furnished rooms, ours with torn and dirty sheets on the bed, and filthy rugs on the floor shared one sparsely equipped kitchen where it would be impossible to cook.
We actually left the apartment four days early to move into a modern hotel near the hauptbahnhof, so we could get clean sheets, clean towels, and bearable room temperatures.
Pity about the great little bakery at the ground level of the block, where they provide the most amazing coffee and really fresh Viennoiseries.
Next day, Friday, we woke up around six in the morning, or rather, got up, having had no sleep. Too warm, the air fetid with tobacco smoke and burnt frying fat, we decided to get up, get out and walk about until the bakery opened. Like I said, that coffee was amazing.
From there we wandered around a bit, came across the Donau Canal, thought it was the Donau, and that the Donau was rather overrated, realized our mistake, walked around some more, saw some picturesque sights and discovered that Vienna, unlike, say London, is really quite walkable.
It is a lovely city! If I were a resident, I would perhaps advocate a name change to Chantilly, because everything looks like it’s been smothered in architectural whipped cream and meringues. (After all, what’s a name change or two? Been there, done that, got the kimageshop mailing list.)
People are friendly, and they do not insist on speaking English! So we could exercise our German, compare what we’re used to with with what is usual here, and, which is useful, get some excellent coffee while having the totally erroneous feeling we’re blending in.
Vienna, in fact, is so walkable that we arrived at the KHM at nine o’clock in the morning. That’s an hour early, so we went to sit in the Hofburg Garden, cool down a bit, and watch some people in grey suits sit on whitish horses.
The KHM is awesome. First we got a huge glass of sparkling water with fruit juice in the Museum cafe, then saw the most amazing works of art, then had a great lunch, then went on to see more works of art, until my eyes were bubbling and we just had to leave.
Fortunately, the Akademy pre-reg event was imminent.
My first impression was one of shock: had I grown old and forgotten all those familiar people? Had those people grown so old, or rather, young, that I could no longer recognize them?
Realization soon dawned: this is not only a spectacularly well-attended Akademy, but we have a host of first-time attendees! Later, from a show of hands in the main auditorium on the first day, it really looks like about half of us are here for the first time. That’s just so awesome…
The food at the pre-reg was excellent: dainty, portable, tasty, varied, filling. The beer was nice, the wine generously measured, the meetings with people, some of whom I hadn’t seen for years, heartening.
Saturday and Sunday are the conference days proper, with talks and keynotes, while the rest of the week is hacking and birds-of-a-feather sessions. Keynotes are, at Akademy at least, meant to broaden the attendants’ horizon, enlarge their frame of thinking and make them consider the wide, wide world. This year’s keynotes did that for sure.
Saturday’s was all about how a small band of brave people have the foresight to start collecting information now to support the transition of North Korea to a country under the rule of law. The country led by a man who was so warmly met by the current president of the United States is a place where atrocities are so normal that it’s almost impossible to feel shocked, instead of just soul-weary. Dan Bielefeld, in a very understated, collected and impressive way gathered the threads for us, and made it clear to everyone that this just cannot and will not endure.
Sunday’s keynote by Claudia Garad was, in a way, closer to home, but also really inspirational. In “W for Welcome” she explained how the Wikipedia community works to make contributors welcome. This ties in quite neatly, of course, with one of the three Goals of KDE: privacy, usability, onboarding — goals that adorn all our lanyards! (Those lanyards were designed by Kenny, and are awesome.)
For me, Akademy isn’t so much about presentations, though there were some very cool ones, like Paul Brown demonstrating KDEnlive in a very engaging way — and why don’t we have more presentations showing off how to use this or that KDE application? It’s not like even a majority of KDE people present here have any clue about, say, Krita…
The VVave presentation was a bit unique in that it was about one person booming their project — and I think we need more of that! That sort of confidence was also expressed by Nate’s talk: the first time in many years since I’ve heard someone in the free software community urging us to disdain the Moon, or Mars, but reach for the stars.
But, for all of that, for me, Akademy is about the conversations, the meetings, figuring out how share knowledge and making sure we all go home a bit smarter, deeper, wiser — and more engaged than we arrived. That’s even more important than the presentations.
I’ve had wonderful talks with many people, I’ve been able to sit down twice with Eliakin, who did a succesful Summer of Code project with Krita last year, I have met Inge again, my one-time business partner and KOffice/Calligra compatriot — and much-missed friend.
We’ve just had two days of Birds of a Feather sessions. And the KDE e.V. AGM, of course. KDE e.V. is the backbone of the KDE project and community. The yearly general meeting, however, is usually characterized by unbearable tedium. This year’s proceedings were different: all the interesting bits, that is the reports, were given in public, during Akademy, and only the most boring bits, the legally mandated bits, were to be gotten through during the AGM. The goal was twenty minutes. The goal was not met, not by a country mile.
For me, tomorrow is KHM day again, with maybe a side dish of Belvedere, or some strolling about town. Thursday, we’ll have a training in fund raising that will take all day. Timely too, because we want to do another Krita fundraiser in September! And on Friday, we’ll take the train to Würzburg, where we’ll take the train to Arnhem, where we’ll take the train to Deventer, where we’ll discover whether our house still has a roof. It has been said that there have been storms and rains in the Netherlands…
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.
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.
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.
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…
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.
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.
Ever since our first kickstarter in 2014, we’ve been building every release of Krita for OSX. The initial work to make that possible took two weeks of full-time hacking. We did the work because Krita on OSX was a stretch goal and we wanted to show that it was possible to bring Krita to OSX, not because we thought two weeks would be enough to create a polished port. After all, the port to Windows took the best part of a year. We didn’t make the stretch goal, and the port to OSX got stuck.
And that shows. We build Krita on a mid-2011 Mac Mini that runs Mavericks. That has a couple of consequences: Krita doesn’t run well on anything but Mavericks, and the hack-build-test cycle takes about half an hour. That means that fixing bugs is nigh on impossible. Some things have been broken since the start, like OpenGL, other things broke along the way, like proper tablet support, loading and saving jpeg files. And more. Still, though we didn’t make the stretch goal, the demand for Krita on OSX is there: we’re getting about half a dozen queries a week about Krita on OSX. So, what should be the next steps?
Step one: define the goals. That’s easy. Krita on OSX should run on all versions of OSX that are supported by Qt5, be a good citizen, that is, come as an app bundle in a disk image, save settings to the usual locations, use the regular temporary file location and provide the same feature set and performance as on Windows and Linux. (Which might be difficult because of problems with Apple’s OpenGL implementation: Apple wants developers to use their platform-specific alternative.)
Step two: estimate the effort needed. With the Qt5/Kf5 port of Krita, estimation is more difficult because only now people are creating the first Kf5-based applications on OSX, and are running into new and interesting problems. Things like finding resources in standard locations: for Krita 2.x, we had to hack KDE’s standard paths implementation quite severely. The main issues are: OpenGL, tablet support, standard paths, bundle creation, platform integration and optimization.
My best effort estimation is three to four months of nearly full-time work. That’s similar to the Qt5 port, and comes to about 12,000 to 16,000 euros. Add in a decently fast Mac, and we’re looking at, roughly, an investment for 15,000 to 19,000 euros. Add a bit for unexpected events, and let’s say, 20,000 euros. A lot of money, but actually quite cheap for a development effort of this kind. It’s more than the Krita Foundation has availabe, though…
There is a secondary consideration, borne from experience with the Kf5/Qt5 port: if it will take three months of development time, then that development time is not spent on other things, like bug fixes or kickstarter features. That will have an immediate impact on the project! The port has already made the bug list grow horribly long, because work on the port meant less work on bug fixes.
If we decide to it, step three then must be: do it… There are a couple of possibilities.
The first: run a kickstarter campaign to get the money. Wolthera and I actually started setting one up. But we’re just not sure whether a kickstarter campaign is going to succeed, and to fail would be really bad. It would reflect badly on Krita as a wider project and might jeopardize the 2016 kickstarter campaign to fund the next round of feature improvements. It might even cannibalize the 2016 campaign. We’re not sure how likely that is, though, because we’re not sure the campaigns would be targetting the same user group. Right now, our campaigns are supported in equal parts by free software enthousiasts and by artists. We’re not reaching the OSX community, because Krita isn’t ready on OSX, but conversely, we don’t know how to reach the OSX community. We don’t even know whether the OSX community can be involved enough to reach a funding level of at least 15,000 euros.
That makes starting a kickstarter campaign (which is in itself two months of full-time work) a really dicey proposition. Even cutting the goal up into tranches of 5000 euros for the basic port (and a new Mac) and then stretch goals of 2500 euros seemed chancy to us. Plus, if we get stuck at 5000 euros there really is not enough money to do a decent port.
The second possibility: fund it out of pocket, and try to get the investment back. That could be done by making Krita for OSX exclusively available on Steam, or by a possible increase in donations because we can now reach the OSX user community. The first option could be scotched by someone taking our work and making Krita available gratis on OSX. That would be totally OK of course: Krita is free and open source. Nothing says we have to give our binaries aways, but on the other hand, nothing can stop anyone else from giving our binaries away. Or making their own, once the hard work is done. The second possibility, increased donations, is a kind of gamble. It might work out, or it might not…
The third possibility: fund the development out of pocket, but take a longer period to work on it. Get a Mac and devote, say, two weeks of initial work, and then invest a day a week to OSX. Slice up the week. A bit like I’m now doing four days a week of paid non-krita development to fill up my empty bank account, one day a week of porting and one day a week of stable-version bug fixing.
The final possibility is to do nothing. Maybe a capable OSX-loving developer will come around and start doing the work out of love for Krita. But I’m not sanguine about that happening, since we’ve seen four or five people trying to build Krita on OSX, and all but two failed. The first attempt was using MacPorts, which doesn’t lead to an installable app bundle, and the second attempt was the one done for the 2014 Kickstarter.
Which brings us full-circle to the question: what now?
I hadn’t been able to attend the Qt Dev Days since the old Nokia days… My last one was when they handed out the blue N9’s. KDE, as a sponsor/partner for the Qt World Summit, had access to a number of passes, and was going to have a booth, and I applied for one. I like doing booth duty and I think I’m fairly good at getting people to listen to our spiel. Here’s a report from the trenches!
Monday is training day, and the KDE team didn’t have passes for trainings. Besides, it probably was more instructive to sit in the hack room and hack anyway. With about ten KDE hackers around, the room was full and stuffy, but on the other hand, it was like a mini sprint. At the end of the day, I had the kxmlgui framework in a state where I could use it again for Krita without needing to fork it.
Very gratifying was the recognition KDE got on Tuesday, during the intro talk and the keynote by Lars Knoll. We know we’re doing a good job stress-testing Qt, and a good job as a community helping Qt develop and grow, and it was good to see that recognized.
Not so awesome was the need another keynote speaker felt to connect to his public by making a little “I won’t tell my wife” joke. Not terribly seriously over the edge, perhaps, but unpleasant nonetheless. When can we have a tech conference where speakers don’t assume that their public are heterosexual, white, middle-aged married men? I happen to be one of them, of course…
I didn’t attend many presentations. Of the talks I attended, both Guisseppe D’Angelo’s “Integrating OpenGL with Qt Quick 2” and Olivier Goffart’s “Using namespace std:” stood out because the presentation was clear, the information went deep so I could learn something new. Olivier’s way of engaging with the public worked really well.
The real meat of the QtWS was working the booth, though. We had a good presentation: nice blue table cloth, two good posters (need to have OS logo’s next year, most people thought KDE was Linux-only), a presentation running on a big screen and videos (Plasma Phone, Calligra Gemini, Krita) running in a loop on a nice convertible Windows 8 laptop, together with some software, like Krita Gemini and Marble to show people that KDE’s Frameworks are a truly tested technology you can use to create serious real-world technology. Here’s a picture Dan took:
That was a story that worked: almost everyone whom I asked “do you know KDE” answered with “Yes, I even used to use it”. So I’d go on explaining that KDE is more than the desktop they used to use, but that there’s this set of frameworks, full of tried, tested and reliable technology. Some examples later, I’d point them at the inqlude website. KDE really doesn’t have a website that ‘sells’ Frameworks, which is a problem. Inqlude worked, though. I could also help reassure some people that doing a new desktop application with QWidgets wasn’t a choice for a dead technology, also by showing off Krita Gemini: QWidgets and QML in the same application, with a seamless switch. All in all, we reached a fair number of interested people and we had a story that appealed and got through.
Wednesday evening, my feet ached and the arm that I had broken just before aKademy was very painful as well, but I was pretty satisfied. Plus, I had a stack of Kiki postcards, and pretty much everyone whom I handed one smiled, no matter how tired they were!
One cannot visit Berlin and skip seeing one of the museums. That’s my story, and I stick to it. This time, I went to the Gemäldegalerie. Usually, I visit the Bode Museum, which has some incredible sculpture. The Gemäldegalerie was showing a special exhibition around Adobe’s famous Illustrator splash screen’s painter. The exhibition was a tad disappointing though.
Botticelli’s work was shown together with 19th and 20th century works inspired by him. Some of those works were really interesting, some were boring. Warhol’s Venus on an Amiga 1000 is much less interesting than the Amiga 1000 itself. Other works were more interesting, like Antonio Donghi or Evelyn de Morgan. But that’s fine: not everything needs to be riveting. More of a problem was the presentation of Botticelli’s works themselves: a
boring, long row of paintings grouped by subject. As if the exhibition designer was fresh out of inspiration. The central room with the sole two works signed by Botticelli was flooded in a red light that made it impossible to see anything.
Anyway, after the exhibition followed a four kilometer walk through the galleries, with so many great paintings that a certain visual indigestion was inevitable. But I’ll go again, and perhaps again. This might be my favorite for now, with the red-haired girl helping her grandmother, and the dancing pair:
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.
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!
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…