For someone who really doesn’t like the company or the platform, I’ve had curiously many macs. It started with a Powerbook Pismo which I got secondhand to investigate some problems Krita had with big-endianness (it had a powerpc cpu and ran Debian), during the first Krita kickstarter I got KO GmbH to buy a mac mini so I could work on porting Krita to macOS. That one was horribly slow, so then in 1015 I got a 15″ macbook pro. In 2020 I first got an M1 MacBook pro, to look into making Krita ready for the M1 cpu. And after that an M1 mac mini for KDE’s binary factory. I haven’t noticed other projects making use of it, though, and it’s a bit unstable.
And then, since I still could get a good trade-in value, I decided to swap the 13″ M1 for a 14″. The 13″‘ screen was always a bit too small for me and I hated the touch bar with a vengeance.
I’ve been using it now for a bit, and here are my impressions…
The out of the box experience was… Trying my patience a lot! First it needed to download and install 6.1 GB of updates before I could even start sending over my user files. That took hours, even over my really fast glass connection..
Then I wanted to transfer my user folder from the old macbook to the new one; I was warned that that would take five hours. In the end, it was “only” two hours. But that worked really well: everything was copied and ready for me.
Only at that point, by now it was early in the evening could I log in. Asnd that didn’t work. I needed to futz with my Apple ID from another Apple device — and that several times. When that was finally sorted, and I don’t remember <i>how</i> I sorted it in the end, macOS insisted on setting up all kind of stuff I’ll never use, like iCloud.
The next day, I could finally setup my development environment, dropbox and other stuff. Dropbox on M1 macOS has a problem: it can no longer install the kernel extension that would automatically download an off-line file, which means… For every file in Dropbox that I want to use, I need to manually make it available off-line. That’s still not sorted.
As for the development environment, installing XCode took, once again, hours. I only use the command-line stuff, the IDE I use for working on Krita is Qt Creator.
So, now I was all set to go and build Krita. At that point it was clear that this laptop is amazingly fast. Compiled C++ files scrolled by at a clip that I only know from C on other computers.
Actually developing, though, is not such a nice experience. The problem is mainly with the keyboard. As far as keyboards go, the actual keys type fine. It hasn’t got a lot of travel, but it’s easy on the nail polish, it feel good — typing text is a lot of fun. It’s got function keys again, which is also nice.
But…
It’s missing so many keys. I know, that’s par for course with Apple, but when using Krita, a missing Insert key means no easy way to create layers. And there’s a lot of inconsistency between applications. In Terminal, you switch tabs with Control-Tab, in Firefox with Option-Command-Left/Right, in Qt Creator with Option-Tab. I haven’t figured out what it is in Kate. Navigating around text is also inconsistent between applications. And that means that I just never get any finger memory down: especially since I also use all other operating systems…
The window manager is also pretty primitive and needs help from an external utility called Rectangle.
And the permissions stuff is crazy. The wacom tablet driver needs permissions to use Accessibility — as does, for some reason Dropbox.
The hardware for the rest is fine… The screen is good, I don’t mind the notch since I run pretty much everything full-screen, all the time. Battery life is good, but not as good as the 13″‘ battery life was.
As for the rest of the hardware, the screen is fine, I don’t mind the notch, because I pretty much always use all applications full-screen, because of how bad window management is compared to KWin, even with Rectangle.
And I have got a cute cover sticker with Kiki on it!
I have previously written about this subject, and back then couldn’t reach any conclusion. The options open to us were all confusing: we could try to write Krita’s canvas directly in Metal, OpenGL and Direct3D and show those in native windows in our QtWidgets based application.
We could try to rewrite our canvas in QRhi, the semi-private GPU API abstraction Qt 5.15 and up provides — though it might not have enough functionality for us, since it us just written for what Qt needs for QtQuick.
We could try to rewrite all of Krita in QtQuick and integrate our canvas into QtQuick’s render loop: but yes, that means a complete rewrite, because you cannot put a QWidget in a QtQuickWindow, and putting QtQuick into a QWidget window means you’re rendering using OpenGL, which breaks on Windows, now that Qt6 doesn’t come with an Angle option.
So we had a big blue button meeting on Friday, where we discussed this issue and some other issues.
Here’s what we concluded:
We will patch Qt6 to render OpenGL using Angle on Windows and macOS.
In the meantime, using Qt 5.12, we’ll move forward adding QtQuick based elements to Krita.
And we’ll try to make a QtQuickWindow based version of Krita for Android. Sharaf Zaman has succeeded in prototyping that, so we know it can be done now; something we lost in the migration from Qt4 to Qt5.
We also want to strip out the CPU-based canvas in Krita and port our usage of QPainter on OpenGL surfaces to straight OpenGL.
And finally, something we should have done during the port to Qt5, we’ll move uploading the canvas textures into a thread, which should solve the performance problems on macOS.
All in all, it was a very focused and very productive meeting, though I guess the conclusion might be a bit startling. And we’re a bit daunted, but only a bit: we already patch the heck out of Qt anyway.
Two days ago, my macbook pro M1 arrived. I mainly got this device to test Krita on and make ARM builds of Krita, but it’s also the first macbook anyone in the Krita community that allows playing with sidecar and has a touch strip.
So, SideCar works, as expected. There is one problem, though, and that’s that the pressure curve of the Apple Pencil seems to be seriously weird, so I first thought I was painting with a sketch engine brush. But apart from that, it’s nice and smooth.
KDAB has published a library to integrate support for the touchbar: kdmactouchbar — so on that front we might see some support coming.
Krita itself, the x86 build, runs fine: the performance is much better than on my 2015 15″ macbook pro, and rosetta seems to even translate the AVX2 vectorization instructions we use a lot. Weirdly enough, X86 Firefox doesn’t seem to be able to load any website, and Safari is very annoying. Looks like the macOS build of Kate isn’t notarized yet, or maybe I need to use the binary factory build for that. XCode took about two hours to install and managed to crash the system settings applet in the process.
We haven’t succeeded in actually making an ARM build yet. We first need to build the libraries that Krita uses, and some of those seem to build as X86, and some as ARM, and we haven’t figured out how to fix that yet.
The laptop itself is, well, a laptop. It’s not bad, but it would never be my favorite. Yes, it’s very fast, that’s what everyone says, and it’s true: Qt builds in a mere 20 minutes.
The keyboard is nice, much better than the one on the 2015 macbook pro, so Apple was able to make some progress. But the edges of the palm rest — well, all of the edges are really sharp, which is quite painful when typing.
Really cute was the way the language choice on installation tells you to press Enter in all the language, including four dialects of English.
MacOS 11 is also really annoying, with an endless stream of notifications and please-use-your-finger-to-unlock for the most innocuous things. The visuals are appallingly ugly, too, with really ugly titlebars, a cramped system settings applet and weird little pauses now and then. And if the performance monitor can still be put in the menubar, I haven’t found the way to do that.
Anyway, that’s it. We’ll be making ARM builds of Krita one of these days. If you value your freedom, if you like the idea of actually owning the hardware and being able to do whatever you want with it, don’t buy one.
In 2018, I discussed the digital painting devices I had used up til then. These were a Lenovo Thinkpad X61t, a Lenovo Thinkpad Helix, a Microsoft Surface Pro 3, a Wacom Cintiq Hybrid Companion, an iPad Pro 12.9″, a Wacom Mobile Studio Pro 16″ and a Lenovo Yoga 920.
I didn’t discuss the Wacom Graphire, the Wacom Intuos 3, the Huion H610 or the Yiyniva MVP22U that I also had around, probably because apart from the Intuos 3, all of that hardware was stored in the Hardware Attic.
But recently, the Hybrid Companion became even more unusable (it was already bad because of the enormous parallax): the screen’s brightness just couldn’t reach visible levels anymore.
And the Wacom Mobile Studio Pro has been dying for over a year now — not good for expensive hardware bought only in 2017. When running as a computer, it would shut itself down randomly, probably because it was getting too hot. So I got myself a Wacom Link device so I could use it as a regular cintiq, but after two days of usage… The display would reset itself randomly and finally it wouldn’t power up anymore, at all.
Of the hardware in the original survey, I still have the Lenovo Yoga 920 — it just has had its screen replaced for the second time, but apart from that, it’s fine.
The screen was broken… The motherboard too. The replacement was too dim, and had to be replaced.
And the iPad is also still fine, probably because I don’t use it for anything but reading comics. The pencil these days never gets even charged because I don’t want to port Krita to iOS and I dislike all the drawing applications that are available for iOS. And the Pencil is really nasty to hold, because it’s top-heavy.
So, what came next…
In 2019, we acquired a Pixel Chromebook (a loaner from Google) and a Samsung Tab S4, for the ChromeOS and Android port. The Tab S4 is nice for reading comics, too, but screen is small and the pen is a bit too small to hold comfortably, for me at least. And Krita on Android is still a bit rough, so no way that would be my main drawing device. (Though Sharaf is working full-time now on improving Krita on ChromeOS and Android.)
Then we had the 2019 Krita Sprint, and I wanted to setup a working HDR test system, so I got an Intuos Pro Large. I hadn’t realized Large meant Huge though… It’s not a display tablet. I actually still like the old Intuos 3 we got crowdfunded in 2007 better.
The demise of the Mobile Studio Pro left me without a display tablet, so I decided to invest in a real Cintiq.
The 16″ model has been out of stock for quite some time now in the Netherlands. I thought, whatever, and got the 24″ one. There’s this saying about donkeys, and I guess I’ve proven I’m not a donkey, because once again, this was waaaaaaaay bigger than I had expected.
It has completely conquered my analog art table:
I’ve had it for three weeks now. Let me sum up my experience with it in the first part of this blog post. The second part is about the Remarkable 2 I received around the same time (I backed their fundraiser way back then).
First: this is the right size for a display tablet. Everything I’ve used before felt cramped, and that’s coming from someone who likes to paint on 3″ by 3″ panels with oils and brushes. At first, it feels downright heavenly to work on.
But…
There are a bunch of severe issues with it, Windows 10 and the latest Wacom drivers. There are also issues using it with Linux + KDE’s Tablet KCM, but those aren’t really Wacom’s fault. I haven’t used it with my mac yet.
I won’t whine about size and weight. But the bezels are ginormous, and though they are a nice magnetic area for the expresskeys remote to latch on to, they are just too much.
If you turn up the display brightness, the fans start impersonating fighter jets taking off. If you don’t it’s really quite dim. And after a while, you get the fans anyway. I wish my drawing was good enough to get fans that easily.
The thingy you click in to put your pen is is tacky, ugly and flimsy. Not a 2500 euro including VAT experience, not at all.
The legs only have one elevation, though it’s quite a good elevation, for me.
The driver and settings software and Windows 10 is GHASTLY.
Let me elaborate on that, because it really is a big deal.
On Windows, there are two ways for applications to talk to tablets, and vice-versa. The ancient and usually reliable “wintab” and the not-really-new-but-we-pretend-it-is and OS-supported “Windows 8 Pointer API, most often called “Windows Ink”.
By default Windows Ink is enabled. This totally makes it impossible to map either side of the rocker switch to right-click. If you do that, and try to use it, Windows will draw a round circle around the cursor and do nothing. You cannot even use it to right-click in Windows Explorer. Whether this is a Windows bug or a Wacom driver bug, I don’t know. I do know that the regular workaround for this issues, switching off flicks, is no longer possible in the latest builds of Windows 10.
This means, with Windows Ink enabled, you cannot right-click with the stylus. At all.
But if I disable Windows Ink in the calibration screen of the Wacom display settings utility (that means, we switch to Wintab), suddenly the right click button starts working! Yay! Both pan and the popup palette work in Krita!
Only… If you have a multi-monitor setup, and given that this is a display tablet, that’s a given, you will get offsets. The offsets get worse the more screens there are to the left of the cintiq. But even if you place the cintiq lef-most in Windows’ display configuration setting, tablet events arrive a bit to the left of the stylus point. And if your displays have a heterogenous scaling factor, the offset gets wild.
This is not a bug in Krita; it happens everywhere, but it doesn’t happen for the mouse events that are generated after the tablet events are discarded. Those are pretty much in the right place.
In short… You can have a right-click button on the stylus or accurate stylus mapping, but not both.
I guess we’ll learn to work around this in Krita by also looking at the mouse events, and taking the coordinates from that. But please, Wacom and Microsoft, work together to fix this?
So this weekend I wanted to test our last release by painting for a couple of hours. Instead it’s the third weekend I’ve spent investigating mouse/stylus/button issues and settings.
And now about the other device that arrived! It’ll never run Krita, but it promised to be very cool indeed. I got a Remarkable 2 tablet. That’s an e-ink display which promises the best ever writing experience.
I wanted to use it for notes, jottings, character sheets, and making diagrams while thinking. Also reading PDF’s of standards documents, programming manuals and articles about graphics and painting.
The hardware looks gorgeous, too. Very stylish, with a nice black pen, a nice leatherette cover and a flush screen design.
There are two problems, one I don’t care much about, and the other one damning.
The meh problem is that in order to put PDF’s on the tablet, you need an account and a Windows, Android or ipadOS application. Or you can futz around with ssh. Well, given that I ssh into our music sever laptop to start a screen session in which I run ogg123, that’s not a biggie. Might be for others, isn’t for me.
But… I’m a leftie. I’m not just to the left of AOC when it comes to politics, but I draw, paint and write with my left hand. Most of us lefties have learned to turn the paper counter-clockwise until the top is parallel with our hand.
Then we start to write.
On the remarkable this wil every friggin’TIME that I start writing at the top of a page close that page because a gesture from the top downwards closes the open document.
It’s as if I’m crumpling up every piece of paper I’m writing on, always, all the time.
But apart from that, the acccuracy, speed, handwriting detection, screen quality, build quality — it’s all close to perfect. The pen is a bit too rough for my fingers, but okay, that would erode with enough use. Only, using the Remarkable is next to impossible for me!
ETA: I figured it out! I can hide the ui for selecting tools, and that also hides the thingy that closes the document on touch. I can finally use the Remarkable — though I still tend to create new pages all the time with the palm of my hand.
I’m not as deep into Python these days as I was twenty years ago. Twenty years ago, Python was small language with clear documentation and clear, consistent ways of doing things. One thing was hard, though, and that was packaging your python application so people on different systems could use it.
These days, Python is big, has lots of computer-sciency features that I don’t grok, and packaging Python is still hard. And the documentation is, for the most part, not very useful. I didn’t care a lot about that, though, since we only use Python as Krita’s extension language together with PyQt. And we had a nice and working setup for that.
Well, nice… It’s a bit hacky, especially for Windows. Especially since we need to build Krita with mingw, because msvc has problems compiling the Vc library. And Python has problems getting built with mingw-gcc on Windows.
We have three related parts: python, sip, which creates Python libraries out of special hand-written header-like files, and PyQt, which binds Pyton and Qt.
So, we start with a system-wide install of Python. This is used to configure Qt and build sip and PyQt. Then we download an embeddable Python of exactly the same version as the system-wide install, and install that with Krita’s other dependencies.
But last week the KDE binary factory windows images got updated to Python 3.8.1 (from 3.6.0) so we had to update the references to Python in Krita’s build system. There are a couple of places where the exact version is hard-coded, not just in the build system, but also in the code that setups Python for actual usage when Krita runs.
And at that point, our house of cards fell apart. Python 3.8 has a new, improved, more consistent way of finding dll libraries on Windows. At least, that was the idea. Following discussion in Python’s bug tracker, a Python developer declared victory:
Python 3.8 on Windows is getting a new fix for DLL Hell. If you bundle precompiled DLLs with your wheels or use ctypes, you should read https://t.co/tjNwZPII3X and the os.add_dll_directory() function. pic.twitter.com/NwesjRgWCN
c:\dev\krita>python
Python 3.8.1 (tags/v3.8.1:1b293b6, Dec 18 2019, 23:11:46) [MSC v.1916 64
bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import PyQt5
>>> import PyQt5.Qt
>>> import PyQt5.QtCore
Traceback (most recent call last):
File "", line 1, in
ImportError: DLL load failed while importing QtCore: The specified module
could not be found.
This seemed related: the PYQt pyd files link to the Qt dll’s. The pyd files are in lib/krita-python-plugins, the Qt dll’s in the bin folder, and it looks like the QtCore pyd, even though dependency walker shows it can find the QtCore.dll, Python cannot find it anymore.
So, on to the changelog. This says:
DLL dependencies for extension modules and DLLs loaded with ctypes on Windows are now resolved more securely. Only the system paths, the directory containing the DLL or PYD file, and directories added with add_dll_directory() are searched for load-time dependencies. Specifically, PATH and the current working directory are no longer used, and modifications to these will no longer have any effect on normal DLL resolution. If your application relies on these mechanisms, you should check for add_dll_directory() and if it exists, use it to add your DLLs directory while loading your library. Note that Windows 7 users will need to ensure that Windows Update KB2533623 has been installed (this is also verified by the installer). (Contributed by Steve Dower in bpo-36085.)
Well, that sounds relevant, so let’s check the documentation and see if there are examples of using this add_dll_directory…
os.add_dll_directory(path)
Add a path to the DLL search path.
This search path is used when resolving dependencies for imported extension modules (the module itself is resolved through sys.path), and also by ctypes.
Remove the directory by calling close() on the returned object or using it in a with statement.
New in version 3.8: Previous versions of CPython would resolve DLLs using the default behavior for the current process. This led to inconsistencies, such as only sometimes searching PATH or the current working directory, and OS functions such as AddDllDirectory having no effect.
In 3.8, the two primary ways DLLs are loaded now explicitly override the process-wide behavior to ensure consistency. See the porting notes for information on updating libraries.
So I started experimenting myself. And failed. Our code that detects whether PyQt5 is available isn’t very complicated, but no matter what I did — even copying the Qt5 dll’s to the PyQt5 folder, using add_dll_directory in various ways, I would always get the same error.
And now I’m stuck. Downgrading to Python 3.6 makes everything work again, another hint that this dll finding change is the problem, but that’s not the way forward, of course.
For now, the beta of Krita 4.2.9 is delayed until we find a solution.
When I read “Qt offering changes 2020” yesterday, my first reaction was to write a pissy blog post. I’m still writing a blog post with my thoughts about the changes, but I’ll be nice. There are three parts to this post: a short recap of my history with Qt and then my thoughts on what this means for KDE, for Krita and for free software.
I started programming using Qt and PyQt when I read about Qt in Linux Journal, which I was subscribing to back in 1996. That means that I’ve been using Qt for about 25 years. I initially wanted to write an application for handling linguistic field data, and I evaluated GTK+, wxWidgets, Qt, Tk, fltk, V and a few others that have been forgotten in the mists of time. I choose Qt because it had great documentation, a consistent API, the most logical (to me…) way of doing things like setting up a window with a menu or handling scrollbars and finally because it made C++ as easy as Java.
I’ve stayed with Qt for 25 years because, through all the vicissitudes, it kept those qualities. Mostly. There are now a lot more modules, most of which aren’t necessary for my work, there are people working on Qt who seem to be a bit ashamed that Qt makes C++ as easy as Java and want to make Qt as computer-sciency as C++, there have been the licensing issues with the QPL, the changes to GPL, to LGPL and then again some modules back to GPL there have been the Nokia years, the Digia times.
But I’ve always felt that I could build on Qt. And the reason for that is the KDE Free Qt Foundation. To summarize: this is a legal agreement that keeps Qt free software. If the Qt company won’t release a version of Qt under a free software license within a year of a release, Qt becomes licensed under the BSD license.
With yesterday’s message, the Qt company is searching the utter boundaries of this agreement. To recap:
Long Term Support releases remain commercial only (the post doesn’t mention this, but those releases also need to be released under a free software license within a year to adhere to the agreement, at least to my understanding).
Access to pre-built binaries will be restricted: put behind an account wall or be only available to commercial license holders
And there’s a new, cheaper license for small companies that they can use to develop, but not deploy their work to customers.
This is a weirdly mixed bag of “changes”. The last one is a bit silly. Even the “commercial” side of Krita is too big to qualify! We’re five people and have a budget of about 125k…
The middle point is worth considering as well. Now there is nothing in any free software license that talks about a duty to make binaries available.
For a very long time, Krita, when part of KOffice, only made source tarballs available. Right now, we, like the Qt company, have binaries for Linux, Windows, macOS and (experimentally) Android. The Windows binaries are for sale in the Windows Store and on Steam, the Linux binaries are for sale on Steam. And all binaries can be downloaded for free from krita.org and other places.
This move by the Qt company would be like the Krita project shutting down the free downloads of our binaries and only make them available in the various stores. It would be legal, but not nice and would cost us hundreds of thousands of users, if not millions. It is hard not to wonder what the cost to the Qt community will be.
The first change, the restriction of the LTS releases to commercial customers has all kinds of unexpected ramifications.
First off, Linux distributions. Disitributions already rarely use LTS releases, and in any case, with Qt 3 and Qt 4 there didn’t use to be any LTS releases. But disitributions do have to keep older versions of Qt around for unported applications for a longer time, so they do need security and bug fixes for those older versions of Qt.
Then there’s the issue of how fixes are going to land in the LTS releases. At the last Qt contributor summit the Qt project decided on a process where all fixes go through “dev” and then are ported to the stable branches/LTS branches. That’s going to break when Qt6 becomes dev: patches won’t apply to Qt 5.
Albert has already blogged about this change as well, but he only really focused on distributions and KDE Plasma; there is of course much more to KDE than the Plasma desktop and Linux distributions.
As for Krita, we’re using Qt 5.12 for our binaries because we carry a lot of patches that would need porting to Qt 5.13 or 5.14 and because Qt 5.13 turned out to be very, very buggy. For Krita, using a stable version of Qt that gets bug fixes is pretty important, and that will be a problem, because we will lose access to those versions.
In my opinion, while we’ve done without stable, LTS releases of Qt for years, it’s inevitable that Qt 5.15 will be forked into a community edition that gets maintained, hopefully not just by KDE people, but by everyone who needs a stable, LGPL licenced release of Qt5 for years to come.
Splitting up the Qt community, already responsible for handling a huge amount of code, is not a good idea, but it looks like the Qt company has made it inevitable.
And once there’s a community maintained fork of Qt, would I contribute to the unforked Qt? Probably not. It’s already a lot of work to get patches in, and doing that work twice, nah, not interested. If there’s a maintained community version of Qt 5, would I be interested in porting to Qt 6? Probably not, either. It isn’t like the proposed changes for Qt 6 excite me. And I don’t expect to be the only one.
As for the more intangible consequences of these changes: I’m afraid those aren’t so good. Even in our small Krita community, we’ve had people suggest it might be a good idea to see whether we couldn’t port Krita to, say, Blender’s development platform. This would be a sheer impossible task, but that people start throwing out ideas like that is a clear sign that the Qt company has made Qt much less attractive.
If I were to start a new free software project, would I use Qt? Last Sunday the answer would have been “of course!”. Today it’s “hm, let’s first check alternatives”. If I had a big GTK based project that’s being really hampered by how bad, incomplete and hard to use GTK is, would I consider porting to Qt? Same thing. If the KDE Free Qt Foundation hadn’t that agreement with the Qt company, the answer would probably be no, right now, it’s still probably a yes.
Now as for the actual announcement. I think the way the Qt company represents the changes is actually going to help to harm Qt’s reputation. The announcement is full of weasel-wording…
“General Qt Account requirement” — this means that in order to download Qt binaries, everyone is going to need a Qt account. Apparently this will make open-source users more eager to report bugs, since they will already have an account. And, yay, wonderful, you need an account to access the completely useless Qt marketplace. And it allows, and now we’re getting at the core reason, the Qt company to see which companies are using the open source version of Qt and send salespeople their way. (But only if the people making the accounts are recognizable, of course, not if they make the account with their gmail address.) When I was working for Quby, I was unpleasantly surprised at how expensive Qt is, how little flexibility the Qt company shows when dealing with prospective customers — and how we never downloaded the installer anyway.
“LTS and offline installer to become commercial-only” — this will break every free software project that uses services like travis to make builds that download Qt in the build process. Of course, one can work around that, but the way the Qt company represents this is “We are making this change to encourage open-source users to quickly adopt new versions. This helps maximize the feedback we can get from the community and to emphasize the commercial support available to those with longer product life cycles that rely on a specific Qt version.” Which of course means “our regular releases are actually betas which we expect you freeloaders to test for us, to provide bug fixes for us, which we can use to provide the paying customers with stable releases”.
And yes, theoretically, the main development branch will have all bug fixes, too, and so nobody misses out on those bug fixes, and everyone has stability… Right? The problem is that Qt has become, over the years, bigger and buggier, and I doubt whether releases made fresh off the main development branch will be stable enough to provide, say, a stable version of Krita to our millions of users. Because, apart from all the bug fixes, they will also have all the new regressions.
“Summary”. “The Qt Company is committed to the open-source model of providing Qt technology now and in the future and we are investing now more than ever. ” — though only to the extent that the Qt Company is forced to adhere to the open-source model by the KDE Free Qt Foundation.
“We believe that these changes are necessary for our business model and the Qt ecosystem as a whole. ” — my fear is that the Qt Company will not survive the fracturing of the Qt ecosystem that this decision practically guarantees.
Well, that was three interesting articles on the same topic on the same day, namely, billionaires. And read in turn they explain exactly why the Linux Desktop is still at such a marginal market share, and why that’s not because we, who work hard on it, are failures who have been doing the wrong thing all the time. It is in the first place policies, bought with money, that allowed people to build monopolies, taxing individuals and so becoming even more rich and powerful.
(Similarly, it’s not individuals through their choices who are destroying the planet, it is policies bought by the very rich who somehow believe that their Florida resorts won’t sink, that they won’t be affected by burning up the planet so they can get richer. But that’s a digression.)
So, the the first article, by Arwa Mahdawi, discussed the first part of this problem: with enough money, all policies are yours. It’s just a squib, not the strongest article.
Then, Robert Reich, a former US secretary of labor enumerates the ways people can become so exceedingly rich, and none of that is because they are so hard-working and so successful:
Exploit a monopoly: this is illegal under the laws of the United States.
Exploit insider information. This is also illegal.
Buy a tax cut. This seemed uniquely USA’ian until the Dutch prime minister Rutte promised abolition of the dividend tax to Unilever. This would seem to be illegal as well, but IANAL.
Extort people who already have a lot of money. Extortion is illegal.
Inherit the money. This is the only legal way to become a billionaire.
Now the article entitled What Is a Billionaire, by Matt Stoller was posted to the Linux reddit today. Not surprisingly, many people completely didn’t get the point, and thought it was irrelevant for a Linux discussion forum, or was about capitalism vs socialism, or outdated Microsoft bashing.
However, what it is about, is the question: why is Bill Gates not in jail for life with all his wealth stripped off? He’s a criminal, and his crime has directly harmed us, the people working on free software, on the Linux Desktop.
So, to make things painfully clear: Bill Gates made it so that his company would tax every computer sold no matter whether it ran Windows or not. If a manufacturer wanted to sell computers running Windows, all the computers it sold were taxed by Microsoft. He would get paid for the work a Linux distribution was doing, and the Linux distribution would not get that money.
That means there’s a gap twice the amount of this illegal tax between Microsoft and the Linux distribution. If a Linux distribution would want to earn what Microsoft earned on a PC sale, it would have to pay the Microsoft tax, and ask for its own fee.
This cannot be done.
And I know, this has been said often before, and discussed often before, and yeah, I guess, poor Bill Gates, if he hadn’t been bothered so badly with the hugely unfair antitrust investigation, he would also have been able to monopolize mobile phones, and the world would have been so much sweeter. For him, for certain.
I guess we didn’t do all that badly with the Linux Desktop market share being what it is. This is a fight that cannot be won.
Monopolies must be broken up. It’s the law, after all.
I was going to attend the Linux App Summit, and even going to speak, about Krita and what happens to a an open source project when it starts growing a lot. And what that would mean for the Linux desktop ecosystem and so on. But that’s not going to happen.
There was really bad flooding in the south of France, which damaged the TGV track between Montpellier and Barcelona. When we went home after the 2018 Libre Graphics Meeting, we took the train from Barcelona to Paris, and noticed how close the water was.
Well, I guess it was too close. And this is relevant, because I had planned to come to Barcelona by train. It’s a relatively easy one-day trip if everything is well, and gives ten hours of undisturbed coding time, too. Besides, I have kind of promised myself that I’m not going to force myself to take planes anymore. Flying terrifies me. So I didn’t consider flying from Amsterdam for a moment — I was only afraid that other people would try to force me to fly.
Then I learned that there is a connection: I would take the train to Montpellier, and then a bus to Bezieres and then a train again. It would make the whole trip a two-day journey, with, as recommended by the travel agency I bought the tickets from, a stop in Paris. That advice was wrong.
I should have taken my connecting train to Montpellier, got a hotel there, and continued the next day. At this point I was like, okay… I’m just going home. Which I am doing right now. I bet the trip back would be just as difficult, and my Spanish isn’t as good as my French, so I would have an even harder time getting people to tell me what to do exactly, when to travel and where to go.
Do they exist? Especially as free software? I don’t actually know, but I’ve never seen a free software project use something like what I’ve got in mind.
That would be: a website where we could add any number of test scenarios.
People who wanted to help would get an account, make a profile with their hardware and OS listed. And then a couple of weeks before we make a release, we’d release a beta, and the beta testers would login and get randomly one of the test scenarios to test and report on. We’d match the tests to OS and hardware, and for some tests, probably try to get the test executed by multiple testers.
Frequent participation would lead to badges or something playful like that, they would be able to browse tests, add comments and interact — and we, as developers, we’d get feedback. So many tests executed, so many reported failure or regressions, and we’d be able to improve before the release.
It would be a crowd-sourced alternative to something like Squish (which I’ve never found to be very useful, not for Krita, not at the companies where it was used), it would make beta testers not just feel useful, it would make beta testing useful. Of course, maintaining the test scripts would also take time.
It sounds simple to me, and kind of logical and useful, but given that nobody is doing this — does such a thing exist?
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!
