This year, we’ve got elections in the Netherlands. Which means, I have to choose where my vote goes. And that can be a trifle difficult.
After fifteen years in the free software world, I’m a certified leftie. I’m certainly not going to vote for the conservative party (CDA, formally Christian, been moving into Tea Party territory for a couple of years now), I’m not going to vote for the Liberal Party (VVD) — that’s only the right party for someone who has got more than half a million in the bank. Let’s not even begin to talk about the Dutch Fascist Movement (PVV). The left-liberals (D66) are a bit too much anti-religion, and, shockingly, being a sub-deacon in the local Orthodox Church, I don’t feel at home there. That leaves, more or less, the Socialist Party, the Labour Party and the United Christian party. The Socialist Party has never impressed me with their policies. That leaves two…
Yeah, you know, I’m a Christian. If someone’s got a problem with that, that’s their problem. I’m also a socialist. If someone’s got a problem with that, that’s their problem. If someone thinks I’m an ignorant idiot because of either, their problem.
But today, the Labour Party minister for international cooperation, Lilianne Ploumen, has announced an effort to create a fund to counter Trump’s so-called “global gag rule”. That means that any United States-funded organization which so much as cooperates with any organization involved in so-called “family planning” will lose its funding. She is working to restore the funding.
News headlines make this all about abortion… Which is in any case not something anyone with testicles should concern themselves with. But it isn’t that, and just talking about abortion makes it narrow and easy to attack. As did our local United Christians party, which will never again receive my vote. It’s also about education, it’s also about contraceptives, it’s about helping those Nepali teenage girls who are locked in a cow shed because they’re menstruating. It’s about helping those girls who get raped by their family get back to school.
It’s about making the world a better and safer and healthier place for the girls and women who cannot defend themselves.
And I don’t have to worry about my vote anymore. That’s settled.
Last year, I wrote about how library authors should pretty darn well never ever make their users spend time on “porting”. Porting is always a waste of time. No matter how important the library author thinks his newly fashionable way of doing stuff is, it is never ever as important as the time porting takes away from the application author’s real mission: the work on their applications. I care foremost about my users; I expect a library author to care about their users, i.e, people like me.
So, today I was surprised by Goodbye, Q_FOREACH by Marc Mutz. (Well known for his quixotic crusade to de-Qt Qt.)
Marc, none, not a single one of all of the reasons you want to deprecate Q_FOREACH is a reason I care even a little bit about. It’s going to be deprecated? Well, that’s a decision, and a dumb one. It doesn’t work on std containers, QVarLengthArray or C arrays? I don’t use it on those. It adds 100 bytes of text size? Piffle. It makes it hard to reason about the loop for you? I don’t care.
What I do care is the 1559 places where we use Q_FOREACH in Krita. Porting this will take weeks.
Marc, I hope that you will have a patch ready for us on phabricator soon: you can add it to this project and keep iterating until you’ve fixed all the bugs.
Happy porting, Marc!
Come into the real world and learn how well this let’s-deprecate-and-let-the-poor-shmuck-port-their-code attitude works out.
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.
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.
- On Snappy and Flatpak: business as usual in the Canonical propaganda department
- Maintainers Matter
- Re: Fedora development of Snap packages
- watching the Linux world do its usual incompetence-dance
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?
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 🙂
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.
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.
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!”
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 firstname.lastname@example.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 email@example.com 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…