Friday

3 April, 2020

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:

In general, we’re not exactly close to zero bugs… Even though we close more bugs year over year than there are reported, the number keeps climbing. There must be something wrong with my maths…

Open, new and closed bugs in the past year.

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.

Thursday

2 April, 2020

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.

COVID-19

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.

New Features

The biggest and most requested feature is probably Kai’s work on the Thunderbird integration, even if not released yet.

Thunderbird showing flight details for a boarding pass email.
Thunderbird itinerary extraction plugin.

The newly added transfer feature from the last report received a number of extensions:

  • You can now configure multiple favorite locations, rather than just a single home location. This is typically useful if your travel starts or ends at different places, say your home and your work place.
  • There is now an option in the settings to have transfers suggested fully automatically, including picking a suitable public transport route. As this involves online access, it’s off by default.
  • Inserting transfers manually is now possible in more places in the timeline.
  • Transfers and favorite locations are now also covered when importing or exporting the app’s data.

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.

KDE Itinerary timeline showing a timezone transition information.
Timezone transition information in the KDE Itinerary timeline.

The statistics page added earlier this year was also extended by a few more information:

  • The number of trips is now also shown. Technically this is the number of trip groups in the timeline, which is closest to what one would perceive as a “trip”.
  • Visited countries in the selected time range are shown. While interesting, this is something occasionally also needed for e.g. visa applications or medical forms.
KDE Itinerary statistics page showing trip count and visited countries for the selected year.
Trip count and visited countries shown in the KDE Itinerary statistics page.

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.

KDE Itinerary hotel location editor.
Basic location editor for a hotel in KDE Itinerary.
  • And last but not least, KDE Itinerary has a proper icon now, thanks to the work of Mathis Brüchert during the Plasma Mobile Sprint!
New KDE Itinerary icon by Mathis Brüchert.
KDE Itinerary icon.

Infrastructure

Data extraction:

  • We got new extractors for Accor, hotels.com, and Indigo bookings as well as Ouigo tickets, and improved the extractors for Vueling, Thalys, Trenitalia and SNCF.
  • PDFs with rotated pages are now handled better during extraction.
  • We made some progress in decoding the (newer?) QR codes on SBB tickets. There’s still one important open question though, we haven’t figured out how to decode date/time values.
  • For the Plasma Browser Integration the JSON-LD processing can now handle multi-type and @graph structures, as found on some websites.
  • Flights with different but not conflicting IATA BCBP data are now merged correctly, and so are unbound train reservations.
  • The generic Apple Wallet pass extractor doesn’t choke anymore when fed with a file which contains a barcode that isn’t an IATA BCBP code.

Static data:

  • For the upcoming 20.04 release the static airport and train station databases got their routine updates from Wikidata. This time this was a rather big update though, bringing in the result of about 3.5k changes in Wikidata over the past weeks that added missing train station identifiers, particularly improving station lookups for Renfe and Trenitalia tickets.
  • Finnish station codes (which we can decode from VR ticket barcodes now), are included in the train station database as well.
  • We started to investigate how to add line metadata to KPublicTransport. That is, information about the proper names, colors and logos for public transport lines. Those aren’t reliably provided by the online services usually, but the necessary data can be found spread out through OpenStreetMap and Wikidata. This is still work in progress, I’ll write a separate post about that at some point, but the following screenshot shows what this will enable already.
KDE Itinerary timeline showing a transfer element with official subway/rapid-transit line icons.
Transfer element showing official public transport line icons.

Android build infrastructure:

  • A lot of work went into upgrading our Android builds to Qt 5.14, see the separate post about this.
  • With the upgrade to Qt 5.14.0 done we unfortunately hit a severe regression in the timezone handling of Qt 5.14.1, and fixed that for Qt 5.14.2.
  • For KDE Itinerary users all this is visible for example in the now properly styled controls, correctly rendered Unicode emojis, and the app automatically opening when sending itinerary data via KDE Connect.

Fixes & Improvements

As usual, there’s also a number of smaller but still noteworthy changes all over the place.

KDE Frameworks:

  • Kirigami was hitting a race with ECM’s translation catalog loading, this is now handled correctly and even early qsTr calls show up correctly translated now.
  • Barcode scaling on high DPI phone screens has been improved in KF5::Prison.

KPublicTransport:

  • Notes and disruption messages are now retrieved in the current language, if the corresponding backend service supports this.
  • Warning messages that imply service cancellation in Hafas responses are now handled correctly.
  • Disruption messages from Navita backends are now supported as well.
  • If there is no booked seat reservation, coaches with the booked class are highlighted in the vehicle layout view instead.
  • Cached results can now have an explicit validity time, enabling sensible caching of vehicle layout data.
  • New backend service configurations were added for all Delfi state-level services in Germany.

KMail itinerary plugin:

  • Fixed translation of messages from Grantlee templates.

KDE Itinerary:

  • Various translation issues got fixed here as well.
  • There is now a new welcome page when first starting the app, with information how to load data into your timeline.
  • The timeline now groups starting/trailing transfers correctly into the corresponding trip groups.
  • For flights the passenger sequence number is now shown on the details page, which can be useful for manual boarding checks.
  • For train trips, real-time disruption notes are now shown on the details page.
  • Layouting issues in the Apple Wallet pass view and the settings page were fixed.
  • The timeline is position on the current day more reliably.
  • Exporting data no longer crashes the app.

Development Tooling

The main development tool for data extraction, KItinerary Workbench received a number of improvements as well:

  • The result display is now broken down further into post-processed and validated results, allowing you to better inspect how extracted results are augmented or filtered out.
  • The DOM view for HTML input content now has a search line for easier navigation.
  • And most importantly, it’s now also possible to edit extractor meta-data for those extractor meta-data files grouping multiple extractors for different types of input documents.

Contribute

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.

Status of Plasma Mobile

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.

Basic Applications

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:

We also need to install some common chat apps, like Telegram and Spectral.

KWin Wayland compositor

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.

General Plasma shell tasks

Configuration Modules

Currently we have a basic set of system configurations:

  • Date and time configuration
    • NTP based automatic date/time selection
    • Allow to set 24 hour clock
    • Manual datetime and timezone selection
  • Basic Wifi settings
  • Language settings
  • Support for Nextcloud and Google accounts
  • Basic system information

However, we are still missing some configuration needs:

We need your help!

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.

Wednesday

1 April, 2020

I am happy to inform you we have released Qt 5.14.2.

We are happy to announce the release of Qt Creator 4.11.2!

Tuesday

31 March, 2020

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.





I would like to thank everyone for its love concercing Latte and kde community for its big acceptance. It is no secret that for the last two years I am the single and only Latte developer. For me it is just my fun project that I also share to the community. If anyone wants to participate by contributing code and patches for review can do so easily through kde phabricator page. I also want to thank of course the kde translators and its team that contribute translations to Latte weekly.

In previous month users had asked when Latte v0.10.~ will become the stable version. So as it appears I do not have time to make this possible until this summer so as a first step it will be delayed for Christmas 2020 and if it is not ready then it will be delayed even more. Of course and I do not want to burn out and I want to keep other aspects of my life healthy.



Why don't you release Latte new major stable versions more often?

Releasing stable versions it means also that you have to maintain them. When a stable version is released then for the next six months a bug fix release is published almost monthly or earlier. After the first six months then the bug fix releases are not that often and contain only critical and very important fixes.


Why Latte v0.10 is so different?

I have scheduled for v0.10 some major changes and improvements that make too much sense in order to delayed any further. These changes are not too easy to implement because they require updating Latte Layouts foundations so they must be tested properly and must be presented to users in an easy way.


Layouts and Preferences window

It is updated in order to be more stable, consistent and more meaningful for users.

- layouts editor -
- preferences -


Layout Details window

A new window will be introduced that will be accesible from Layouts Editor. You will be able to change all layout settings easily and of course there will be in that window a Docks/Panels list that you could use to update Screen assignment/ Screen Edge placement and access easily the specific Settings window for that dock panel.


Layout Templates

Currently extracted layout files contain also the user specified applet settings, so you must be careful a lot because the layout files can contain also sensitive data such as your google account that you are using in an applet or personal information etc. when you publish them on the Internet. A new concept will be introduced that will be called Layout Templates. You will be able to extract, import and publish your layouts  without containing any user-specified applet settings by default. They will contain only your applets placement and dock/panels placement and settings. You could also use these templates in order to add new Layouts in your Layout editor easily.


Dock/Panel Templates

Like Layout Templates the same thing will be possible with docks and panels. You could have a Template for specific dock and panel and you could use it to add new panels and docks based on that template. That template will not contain of course any user specified applet settings by default.


Layouts and Dock/Panels Interoperability

All Layouts / Layout Templates / Dock,Panel Templates will be able to be exchanged through Copy/Cut Paste paradigm and Latte will give you options for these actions when the Paste action takes place.


Example 1: when you copy a layout into the Layout Templates list, Latte will ask you if you want to keep the user specified applet settings, by default it will choose No.


Example 2: when you copy a dock/panel into a specific Layout Template or Dock/Panel Template, Latte again will ask you if you want to keep the user specified applet settings, by default it will choose No.



Easy to understand UI for all above possibilities

All previous options of course and it is a dream and very important to provide. So it will take as much time is needed in order to be provided correctly to the user. In most cases for user interaction the Copy/Cut Paste paradigm will be used that is well established and educated already to vast majority of the users.







Donations:

You can find Latte at Liberapay if you want to support,     Donate using Liberapay


or you can split your donation between my active projects in kde store.
Konsole Icon

New icon theme

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.

Digikam Icon

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.