With near infinite difficulty we managed to release Krita 4.2.9 in the last week of March… So now it’s time to look ahead! All Krita developers work from home anyway, whether they do sponsored work or are volunteers, but it’s quite hard to keep focus these days. Several of us are in quarantine, others are in lock-down — with people in Hong Kong, China, India, Russia, Poland, Germany, the Netherlands, U.S.A, Canada, Mexico and Brazil we live under a wide variety of pandemic responses. The Libre Graphics Meeting in Rennes has been moved to 2021, as has the Krita Developers Sprint that was going to happen right after LGM.
But life goes on, and we’re on the verge of another edition of Google Summer of Code. Krita has received a bunch of excellent proposals! Let’s keep our fingers crossed for our prospective students!
And, of course, a lot is happening in Krita’s repository! About two weeks ago we merged the resource management rewrite branch into master. Now, let’s unpack this in what we’ve been doing, and what this means… For the past five years, we’ve been working on rewriting the way Krita handles things like brush presets, brush tip and tags. This turned out to be a huge amount of work, sucking up lots and lots of energy. But in March we felt we could risk merging everything into master so it would get into the development builds.
So we merged… But we all knew that the branch wasn’t ready yet. There are bugs, there are things lacking, but it was time to take this step — now more people can look into the resource handling changes. Of course, this gave an immediate spike in the number of open bugs:
This week we also discussed our roadmap: 4.2.9 will be the last 4.2 release. We’ll release 4.3.0 in about two months, but it won’t be the release with all the resource work done. What’s currently master will be 5.0, and it will be the release where the old text tool will be finally gone. It will have the resource rework, and probably also lots of new features and summer of code work.
But we’ve been working so hard on fixing bugs, that all of us want a bit of a change, so it’s also time to work on fun features.
One of the features we’re working on goes under the code-name “RGBA Brushes”. Starting with the work of Peter Schatz, Ramon Miranda and Dmitry are creating something rather fun. You can read all about it on Krita Artists. I’ll let Ramon show it!
Talking of Krita Artists… This discussion site, set-up and managed by Raghukamath, is getting more and more popular. It’s now the first place anyone should go who has a question, who wants to show off their artwork, or who wants to discuss possible new features for Krita.
What else is going on… Emmet and Eoion are working on the Animation Next Project — this means they are methodically going through all the papercuts, bugs and feature requests for Krita’s animation feature with a goal of improving the complete experience of making an animation in Krita.
Ivan is, among other things, working on work-arounds for the sorry state of display drivers on macOS. We would like to get Krita in the Apple Store… But still feel it isn’t good enough.
Sharaf is working on getting Krita in the ChromeOS Play store and the fdroid Android store. Krita on Android is pretty stable, thanks to his previous work, and we’ve seen it work just fine on the Pixel Book Google has lent us — it was Google who approached us with the idea of getting Krita on their “big screen devices”, that is, Chromebooks. Krita on the Play Store will be a free download, but we will ask users for a donation on ChromeOS and Android: we do need to keep development sustainable.
As for a roadmap… Those, in our experience, never come true. But we do want to have more fun with brushes, improve the assistants, improve the new text tool. There’s work to be done on layer styles, even though they are already much better in the master branch than in the stable branch.
Since the last report about KDE Itinerary there has been work on Thunderbird integration, a presentation at FOSDEM, a major update to the Android build environment and many more changes. We also entered the finishing line towards the 20.04 releases, and got hit by the fallout of the COVID-19 countermeasures.
With most travel being suspended for the foreseeable future, we wont be able to field-test KDE Itinerary or collect sample data either obviously. The current situation is however highlighting a few areas we could improve.
The probably most obvious one is supporting the trip cancellation workflow. The schema.org data model has that covered, but we hadn’t implemented this yet, due to cancellations being rare, and manual deletion of reservations being already possible. Technically this requires that we can process “minimal” elements that only carry the information that a booking with a certain number has been cancelled. For meaningfully displaying this, we need to find the corresponding booking in the app database or the calendar, and update that. By now this has been implemented in the data model, the extraction engine and the KMail plugin, full support in the app itself is still ongoing.
Another aspect worth investigating is displaying official advises/warnings about imminent risks/disaster situations for the locations along your trip. A global pandemic is certainly the once in a century extreme case for this, more likely are severe weather, flooding, fire, evacuations for defusing WW2 bombs (yes, that’s still a thing here), terrorist attacks, etc. While you might be subscribed to such warnings for your home locations, it’s far less likely you’d get this in a timely manner (and in your language) for a country you only visit for a few days.
In Germany there are dedicated apps for local disaster warnings, such as Katwarn or NINA, and you don’t need to dig long to find the content for this as JSON. Travel advises on the other hand I haven’t found as machine readable data yet. How does this look in other countries? If such information is available in enough places it might be worth implementing support for this in KDE Itinerary.
The biggest and most requested feature is probably Kai’s work on the Thunderbird integration, even if not released yet.
The newly added transfer feature from the last report received a number of extensions:
More work on this is still expected, based on real-world feedback, once we can all travel again.
The location information in the timeline so far showing power plug incompatibilities or driving side changes are now also displayed for timezone changes.
The statistics page added earlier this year was also extended by a few more information:
We now also have a basic address editor for hotel or restaurant reservations that allows picking a geo coordinate on the map. This is mostly a temporary measure until we have found a good way for geo coding, so that you get better results for e.g. transfer elements until then.
@graphstructures, as found on some websites.
Android build infrastructure:
As usual, there’s also a number of smaller but still noteworthy changes all over the place.
qsTrcalls show up correctly translated now.
KMail itinerary plugin:
The main development tool for data extraction, KItinerary Workbench received a number of improvements as well:
This work continues to rely on donated data samples, thanks to everyone who has helped with this so far!
If you want to help in other ways than donating test samples too, see our Phabricator workboard
for what’s on the todo list, for coordinating work and for collecting ideas. For questions and suggestions, please feel free
to join us on the KDE PIM mailing list or in the
#kontact channel on Matrix or Freenode.
If you’re feeling stuck indoors during the lock down you can browse some happy pretty pictures on KDE’s new Instagram account.
Instagram is one of those social medium services and is run by everyone’s favourite Facebook. The good side of it is that it’s based on happy pretty pictures rather than angry people (Twitter) or political disinformation (Facebook) but the bad side of that is it is common to feel inferior because you’re not as good looking as the people in the pictures. Well that’s not a problem because everyone using KDE or helping out the community is automatically good looking.
It’s being run by me and Niccolò Venerandi (veggero) for now but if you want to help out give us a ping. And if you have pretty pictures to go on there send them over to us.
We know many of you have looked forward to the hustle and bustle of Qt World Summit in May. While we unfortunately had to postpone it, we have put together a live online conference with many speakers from the Qt ecosystem to tie you over from the comfort of your favorite screen.
We often get asked: “how long until the 1.0 release?”. Or: “how far away is Plasma Mobile 1.0?”. The usual answer to both these question is “It’ll be ready when it is ready”. But, really, how do we know that it is ready?
Recently some of us prepared a check list of items which we consider necessary before we can declare Plasma Mobile “ready” or at rc1 status.
We currently have applications that cover many basic needs, such as:
There are some more applications which are currently in individual developer’s personal namespace and not yet moved to the official repositories:
Most of these applications have some bugs or missing features, for example:
There are some tasks in KWin Wayland that we hope to get resolved before the 1.0 version of Plasma Mobile,
Also, performance profiling/improvements in KWin are very welcome.
Currently we have a basic set of system configurations:
However, we are still missing some configuration needs:
We need your help to reach the 1.0 release goal. Some of these tasks are really easy to implement and a great way to get involved. If you are interested in helping us out, you can contact us at
We will help you find a suitable issue you can help us with. You can also find the full list of issues on phabricator.
Also check out these resources to help you get started with Plasma Mobile development.
We are planning a mini online sprint that will happen next week so we can finish some of the tasks mentioned above and help with the onboarding of new developers. If you are interested, take a look at the phabricator task.
Plasma has been designed from the get go (2006 or so.. it seems at least 2 eternities ago ) to not make any assumptions on the type of device and to do a clear separation between the core technology/runtime and the various GUI plugins that end up implementing a full desktop experience.
In an architecture decision informed by previous prototypes we did in KDE4 times for mobile devices UIs, in Plasma 5 we split it further and introduced the concept of a “shell package” which lets further customization between devices than what Plasma in KDE4 times allowed.
Because of that we could do the Plasma Mobile shell without changes to the architecture that runs both the Desktop shell and the mobile version, despite being a completely different UI.
While working on different shells such as Plasma mobile and the Mycroft voice assistant (more on that later) we noticed that the best possible help for building a shell for a new type of device from the ground up is a very minimal shell that doesn’t make many assumptions about the final gui, but just provides few building blocks that will be in the end customized by the developer.
Enter Plasma Nano. Plasma Nano is a minimal shell not intended for end users which the developer will extend to match the final desired user experience (think about subclassing in object oriented languages)
The normal television set is becoming more and more from just a “dumb monitor” to a full featured computer system. But for several factors its UI must be completely different from both a desktop system, and from a mobile system.
Those so called 10 foot user interfaces have some particular constraints. The screen will always be seen from pretty far (altough you can’t be sure exactly the distance the users will look at it) so every graphical element must be very clear and big enough to be seen from a distance (indeed ~10 feet / 3 meters or so) so very big text, clear and spaced (too high information density should be avoided)
Every control should be accessible with the least number possible of buttons. It should be easily controllable with just the remote control, and in particular with just arrow keys, and “ok” button and one to go back. Often tv remote controls have a plethora of buttons, tough which makes the user experience only more confusing.
Another important way of interaction recently in smart tvs to go around the lack of complex input methods is voice control. It is ideal there as the commands to the TV would be very basic like “watch this series on Netflix” and things like that. This of course is giving birth to a slew of very legitimate privacy concerns, but this technology is too good and convenient to throw it away because the current implementations are done by less than honest corporate giants.
Mycroft is an open source project which is aiming to build a fully opensource voice-based personal assistant with a growing number of skills.
Understanding voice is in two independent parts: speech to text (going from the sound file of the recorded voice to a normal string of letters) and actual semantic understanding of the sentence to then translate it to a concrete action (fetching weather data, a Youtube video and so on). The latter part is the bulk of the work for a personal assistant and is what Mycroft implements. it can then use an external service for speech to text.
It can use a variety of services, from Google (speech to text, not full assistant) to a different number of free and proprietary services. In the end, they want to use the Mozilla Deepspeech project, which would make the stack 100% free. You can already configure it to use deep speech or other engines, even if not fully ready yet (want to help out? Mozilla is looking for voice samples to make their product better and ready for mass consumption!)
A voice assistant looks better with a GUI part as well, as the echo show and google assistant demonstrate.
Some of us worked together with the Mycroft people to produce an extensive set of QML bindings for the Mycroft system, (that will provide as wellthe user interface for future Mycroft based smart speakers). They’re a third-party QML module that can be freely used by any Qt-based applciation for voice integration.
Plasma Bigscreen can optionally use those QML bindings to provide parts of the QML UI of the user experience (so yes you can ask via voice to your TV if it’s going to rain tomorrow or to watch the music video of so-and-so on YouTube)
Those QML bindings can provide from Mycroft a variety of GUI features, from simple notifications like a clock if you ask what time it is, to a full featured interactive app, like we did for the Youtube skill, which is a Youtube browser app which can be used both via the voice only, the remote control only, or a combination of both and provides a footprint for future rich voice-interactive user interfaces.
|- layouts editor -|
|- preferences -|
Like everyone else, I am also in quarantine, and during this quarantine I got closer to the program that I love, inkscape. I started to make smartphone mockups again, which I published on my Instagram profile (maybe I will also make posts here). But I started a new icon theme , since I have many free hours a day, I have a lot of time to devote to this project.
I plan to release a first alpha by tomorrow evening :). I hope you like it very much. Let me know what you would change. See you tomorrow with the next post.