We’ve already got Valorie here in Deventer, and next week we’ll take the slow train, the international train and then the ICE to Vienna, to attend Akademy. Last time Irina and I attended Akademy was in A Coruña, to present the work I had been doing on Plasma Mobile.
This time, I’m not going to present anything. I’ll be around, I want to listen to people, I want to meet people, I want to forget the past two years, which have been really tough, and I want to…
See this thing in real life. Let’s hope the Kunsthistorisches Museum is open, and hasn’t closed the room with the Cellini salt cellar, or loaned it out…
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.
Some time ago, I compared 2:1 devices, which was a new form factor back then. This time, triggered by an experiment with a Wacom Mobile Studio Pro during the last Krita sprint, I want to look into the various drawing devices I’ve used over the years, and which ones worked well, or not.
This was the first device where I could draw with a pen on the screen. I got it in 2007. The pen technology was Wacom, and it worked with Linux out of the box. The pen was a bit tiny, but could be stored in the laptop itself. The screen only had a 1024×768 resolution, which is incredible these days, but it was fine: nobody was creating 4k images back then. The pen was quite accurate, except at the borders of the screen, a familiar Wacom issue. Palm rejection was fine, and it was a very usable little thing. The hinge mechanism was its weak point though: it turned only one way, and one day someone forced it the other way…
Lenovo Thinkpad Helix
When we were developing Krita Sketch and Krita Gemini, Intel sent us two devices: a Lenovo Helix and a Dell XPS 12. The Dell had a touch screen, but was not pen compatible, the Helix came with a pen, but didn’t have the 2:1 drivers that would switch the device from laptop into tablet mode when ripping it out of the keyboard.
The pen was as tiny as the one in the X61T, and also used Wacom technology. It sort of worked fine, but the device itself always felt cramped when using it for art. Part of that was because the screen was only 11″, part of it because when connect to the keyboard, it didn’t bend back enough, part maybe because it always felt a little slow. It was fairly heavy, too. It ran Linux perfectly well, but not in tablet mode: I never figured out how to make Linux switch automatically between landscape and portrait mode.
The idea was fun, but it was far from an ideal art device, or even a good device for someone developing an art application.
Microsoft Surface Pro 3
It was going at a reduced price, and I wanted something with an n-trig pen, to test Krita with. Plus, I was thinking of, you know, picking up drawing again, and maybe learn how to use Krita. I got the lowest-end model.
When I got it, it was running Windows 8, which was a good fit for the device. Better than Windows 10, to be honest. I liked the PDF reader that came with Windows 8, which got replaced by a web browser by now. I liked to use the device to read comics, too, using the Comix reader. But…
For using it as an art device, there were some big problems: there’s a tiny, but noticeable bit of latency between pen and device. It’s even noticeable when clicking on a menu or a button, and very noticeable when trying to draw. I though that was the n-trig pen, or the bluetooth connection, but later on I learned that this might well be Windows. I never even tried to put Linux on it: this device was for testing Krita on Windows with n-trig/windows Ink, and the 64GB ssd was too small to partition.
The pen is thinnish and not too comfortable to hold, more a Bic feeling than a Waterman feeling. Palm rejection while drawing is pretty bad as well, and there seem to be a ton of things that need to be disabled in Windows before things get to a tolerable state, like all the flicks and things.
In sum, it was slow, laggy and burdened by Windows 10 and all its fancy features that only get in the way.
Wacom Cintiq Hybrid Companion
Wacom contacted us in 2013 and offered to donate some devices to the Krita project so we could improve support for them. One of those devices was the Wacom Cintiq Hybrid Companion.
The Cintiq Hybrid Companion was one of the first attempts by Wacom at creating an untethered art device. It felt (and feels) very luxurious: a very nice sleeve, a nice pen case with lots of replacement nibs and a flimsy but pretty stand came with the device. The pen feels great, too.
The device can run independently, and then it runs Android. The Android version never got updated, though, so it’s still stuck at 4. There were a number of interesting art applications included on the Android side, like Manga Canvas. The application I liked best on Android was ArtFlow. I even considered porting Krita to the device, but never got started. Not a big problem… Wacom never made another Android tablet, and Android tablets with pen support are pretty rare these days.
There were, and are, a couple of issues, though. There is a strong parallax effect near the screen edges. It’s smallish and the resolution isn’t very high. It works best when coupled with a big monitor, two windows and two views on the same image. It’s also rather too heavy to keep on your lap, but as a desk-bound thing it’s fine.
When using it with Windows, touch is unreliable, and when using it with Linux, it is pretty hard to calibrate — and somehow, but that probably is a driver issue, after a couple of strokes it messes up the pointer state, and suddenly every mouse move selects or moves windows, even when nothing is clicked and no modifier key is held.
I keep the companion around, and I often play with it and use it as a test tablet, but until the Linux wacom driver bugs get ironed out, I won’t be using it for real stuff.
iPad Pro 12.9″
Last year, I was thinking of porting Krita to iOS and Android, both because there’s demand for it and because we might be able to generate some extra income to fund development by having Krita in more app stores. I decided to start with iOS because there just are very few Android tablets with a real pen. I got an iPad Pro, created a dev account with Apple and put the dev environment on the krita-for-macOS-build-macbook-pro. I played with some demo scribble application, but by that time I had begun to really, really, really dislike iOS.
I dislike its flat ugliness, its lack of consistency, its invasiveness, the ubiquity of advertisements in the “free” apps. I dislike how indiscoverable features can be. I actually bought Procreate for iOS to check out the competition, and this was the first time in years when I had to read the manual to figure things out.
Hardware-wise, it’s a beautiful, if a bit big, tablet. The screen is great. It’s quite fast. The pen is fine as well, if a bit top-heavy, and doesn’t have an eraser end. Charging the pen is ridiculous:
The available software is weird. I tried OpenCanvas, Medibang, Procreate and Autodesk Sketch. OpenCanvas actually has menus, popup dialogs and everything a desktop application has! Medibang looks quite normal by comparison, but looks and feel more like an Android application than an iOS application. Procreate looks and feels native. It’s all quite usable, and all not quite what I want to use, though.
I’m currently using it to read books on C++ in PDF format (I haven’t found a good CBR or ePub reader for iOS yet…) I still intend to try again to port Krita to iOS, but maybe I’d better sell the thing.
Wacom Mobile Studio Pro
A webshop had a barely-used but seriously reduced price offer for this device. It’s the 16″ model. Pretty much Wacom’s flagship pen tablet, running Windows 10. It comes with a dildo^Wcigar tube^W^Wnew style pen holder, and that’s it. No sleeves, no stands, no usb-c-to-something-useful converter. Even if you want to use it Cintiq-like, you have to buy the Wacom Link converter. For a device at this price level — new it’s more than 3000 euros, that’s a bit mean.
The device itself has its good and its less good points.
Good is the screen: it’s big, bright, high-res and has very good color coverage. Good is the pen: it has a nice weight and with the felt tips feels great when painting. Lots of disk space, choice between Intel and NVidia GPU, also good. Lots of express keys, great.
The Intel Realsense 3D camera never worked, though: it crashes when starting the calibration app. The screen has a yellow splotch in the bottom-left corner (or top-right, depending on how you’re holding it).
It’s heavy, of course, but, well, that’s normal for a 16″ device, and I’ve found various strategies to work with it held on my lap nonetheless. It does get warm, though, especially when we’ve made any little mistake that makes Krita more CPU than needed.
I’ve used it with Windows 10 for about a year: this works, but I noticed it changed my drawing style. More blobby, rendery, less line work. And I’m now guessing that that’s because this device with Windows 10 has sort of the same problem as the Surface Pro 3: a little bit of latency between pen and device.
Which is weird, because it’s Wacom, so the pen and the screen are directly connected, not the pen to the os through bluetooh. So when we had the house full of artists for the sprint, and David, Raghu and Timothee were playing with the device, and they all declared they couldn’t work with it like this, we first tried to find out whether we could improve it under Windows. Disabling the Windows window compositor made a bit of difference, but David was still disgusted with the feel of the device.
Then we tried to run Linux on it. A year ago, that was still a big problem, and when Aryeom of Zemarmot got an MSP, Jehan had quite a bit of work to make things run. However, we just plugged an Ubuntu 18.04 USB stick in the USB hub, rebooted, added a second USB stick with Krita and everything worked.
And the latency was gone! The next weekend, I put Kubuntu on it (still waiting for the 18.04 based release of KDE Neon), and that works much nicer. Pity there isn’t a good HiDPI virtual keyboard for Linux/X11 — but I can just keep my normal keyboard connected to it when I’m drawing and sketching at my desk. There are some problems still: the touch screen doesn’t work in Krita (where the touch screen of the hybrid companion works perfectly), and synchronizing the rotation of the screen and the tablet doesn’t work yet.
Lenovo Yoga 920
I’ve also gotten a Lenovo Yoga 920 at a discount, but I haven’t done much with that yet. Now that the battery life of the Surface Pro 3 is gone, the Dell XPS-12’s keyboard broken and with the Helix out of commission, I wanted something I could take with me (when I go to Akademy, for instance) that I could draw on. But I’ve had very good reports: good Linux compatibility, no latency between pen and computer and it’s very portable. I’ll be spending some more time today getting Krita up and running on it.
So… My blog originally started out as a book review blog, and to celebrate its return (we moved from a home-hosted server to something cloudy), let’s talk about two gosh-darned awful books.
The thing is this: I’ve been so busy with actually maintaining a 600 kloc project that I’ve neglected keeping up with the changes in the language the project uses. Yet C++ has changed a lot, even if our codebase hasn’t. I did buy Stroustrup’s C++11 Programming Language book, but never had time to read it.
And now we’re at C++17. So I thought I’d get a couple of books with C++17 in the title to help me figure out what has changed, why it has changed, how it has changed and what the changes are good for. I got two books from Apress, which is a Springer imprint.
So let’s go for a quick syntax overview. C++17 Quick Syntax Reference. The author, Mikael Olsson, is a Fin, and weirdly enough his bio is smaller than the technical reviewer’s bio, Massimo Nardone. Massimo also gets his picture printed, Mikael doesn’t. Judging from the layout, the book itself is obviously either meant for pre-school children or people with vision problems even worse than mine: the letterpress is enormous. All that would not be a problem, but…
A quick syntax reference has no business explaining how to choose an IDE or how to create a Hello World application. A C++17 syntax reference should also teach modern, 2017-level C++, not 1972 level C. The final chapter, Chapter 27, explains what Headers are, Why Use Headers — with this gem of an observation “C++ requires everything to be declared before it can be used.” Then it goes on the show how to #include a header — heady stuff! After some more kindergarten stuff it finished up explaining include guards.
The book isn’t actually written in broken English, but it is unreadable all the same. Just look at this quote from page 58:
“In addition to passing variables by value, reference, or address, a variable may also be returned in one of these ways. Most commonly, a function returns by value, in which case a copy of the value is returned to the caller.”
Okay, writing this book was a waste of time for the author, unless he’s getting rich from it, which I doubt. It’s a waste of time for the reader, and spending more time on it is going to be a waste of time for both me, and you, my reader. The book will be pulped and recycled.
Next. “Clean C++”: Sustainable Software Development Patterns and Best Practices with C++17″ by Stephan Roth.
Same publisher, same awful print quality, but since Stephan produced a lot of text, the font size is very small. This time the author gets his mugshot printed, and the technical reviewer, Marc Gregoire not. Marc is Belgian, Stephan German and I suspect that the copy editor was Martian. The very first sentence is already broken:
“It is still a sad reality that many software development projects are in bad conditions, and some might even be in a serious crisis.”
Some things are nice, the author uses actual code samples from actual projects, like Apache OpenOffice, to show problems. Some chapters have promising titles, like “The Basics of Clean C++”, but then start exhorting the reader that “Names Should Be Self-Explanatory”. I thought I was reading a book on clean C++, not Java for high school students? Apparently, removing the license header from your source files will also make your code more Clean!
“Advanced Concepts of Modern C++” is more interesting, though either I am dumb, or the author was in need of a good editor to help him explain what he means, because much of the text I just cannot follow. I would also have liked some clear explanation of why automatic type deduction is good, while at the same time, we’re exhorted to do Type-Rich Programming. The rest of the book rehashes in an an abbreviated way what was explained much better elsewhere: Object Orientation, Functional Programming, Test Driven Development, Design Patterns and UML.
The book promised to show how to use C++17 to write clean code. Instead it regurgitates every bromide from Code Complete and similar books published in the past two decades without adding anything interesting or even talking about C++17 much.
Maybe I’m hypercritical these days… But this book will also be pulped. In any case, any suggestions for something that will teach me to read and write real modern C++17 are very welcome!
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.
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.
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.
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.
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 🙂