(German version of this article: https://wordsmith.social/felixernst/mein-anteil-an-der-erstellung-des-hintergrundbildes-von-plasma-6-1-reef)

Plasma 5

A short recap: In Plasma 5 we predominantly had wallpapers with geometric features. They showed digital representations of nature or were completely abstract, which I never really liked. Perhaps that was trendy for a while, or maybe technical Linux users enjoy such wallpapers, which are quite obviously made using a computer. However, these days, we do not only offer the best package of security, privacy, usability, and power for tech enthusiasts, but for everyone. Therefore, it is in my opinion important that our wallpapers represent not just what we stand for but also what we want to enable. In the best case, we enthuse a broad public this way. We should move on from the purely technical towards what is human and incorporate the creative, inventive, or artistic, which will always be absent from machines. A down-to-earth example of this are wallpapers that look like they could be painted on a simple piece of paper.

Plasma 6.0

For the MegaRelease and Plasma 6.0 KDE arranged a competition for the next wallpaper. There was a jury, and even though I had no part in any of this, I was in full agreement with the jury about the winning image “Scarlet Tree”: As far as I know, the winning artist never made a public appearance and the only thing I know of them is their pseudonym “axo1otl”, under which the wallpaper was published. As far as I know, the communication with them was handled by Niccolò Venerandi.

Plasma 6.1

From then on, the release of Plasma 6.1 was inching closer. One could ask: Do we really need a new wallpaper for every new version?

Ask our Promo Team and they will say: Yes, of course!

The reason for this is that we want to show images of the new Plasma version, but not every new Plasma version includes changes to the default user interface. That would be quite annoying if we moved around buttons or changed the design two times a year!

But when we change the wallpaper, it becomes obvious: This is a new version. That wallpaper then moreso represents all the changes that happened below the surface.

Additionally. a new pretty image obviously also brings some colour and variety into the users' lives, if they haven't already switched their wallpaper themselves.

The plan was to keep the wallpaper for Plasma 6.1 in a similar style as the Plasma 6.0 one. The same artist “axo1otl” painted another picture for us. Unfortunately, we only got to see it somewhat late:

The Visual Design Group was not enthralled by it. The image is quite full, and therefore some of us thought that it was not suitable as a wallpaper. This reluctance was strong enough that people started discussing what we could use as a wallpaper instead, even though we did not have much time to make a decision.

I thought the image was good enough, but I was in a minority with that opinion. However, there was no quick way to find a popular replacement either. Some suggestions went back to our old geometric abstract style from Plasma 5 times.

Additionally, the picture was a bit too pretty to simply drop it. So there were attempts to edit the “Reef” wallpaper in a way that might fit our purpose.

Editings

Niccolò used blur: Oliver Beard from Wales moved some of the elements of the painting out of the frame, so the whole wallpaper would become more calm, like a backdrop: This was considered a step in the right direction.

Niccolò then combined both strategies: While watching these experiments, I noticed that the possibilities for adaptations were very restricted because nobody dared to personally add anything to the picture. That is why the reefs only grew in size in the images. Nobody made them smaller because it would mean creating empty space which would then need to be filled e.g. by adding new sand.

I already saw a future before us in which the time constraints would force us to publish such a hastily-constructed adaptation that hides or obscures many nice details of the original artwork. All that because we would not know how to help ourselves.

I did not want that to happen. I felt like I might and should perhaps be able to help here.

The thing is, I tend to work on the Dolphin file manager and regularly dive into the depths of its source code, so I know a thing or two about underwater landscapes. After all, I have been to two Dolphin meetings in the Mediterranean Sea in the last two years: At Barcelona and at Thessaloniki.

So I started editing the painting myself:

My plan was to make room so the image would seem more serene. Viewers should no longer feel like they are in the middle of a lively coral reef and more like they are wandering through the open sea. By moving the right reef to a new middleground and shrinking the castle, the depths and distances in the image grew. After some initial positive feedback, I added more and more of the missing elements.

Some contributors in the Visual Design Group did not like that the path at the bottom of the image did not lead to the castle anymore. To others, the path was generally an undesirable element which should be removed. I bent the visible end of it towards the castle:

The waves in the upper half of the images also needed to be completed. There were big holes where the two castle towers used to be.

The image above was the result of me working until 4 a.m. I only concluded once I considered the image good enough that I could honestly advocate for it to be a Plasma wallpaper. I hoped that my nightly work would ensure that we had a passable wallpaper ready in time for the Plasma 6.1 release.

When I awoke the next “morning,” I addressed feedback from the group. More people had voiced the opinion that they did not like the path. I had originally kept it because I tried my best to preserve as much of the original vision and technique of “axo1otl” as possible given my other changes.

Granted, the goal of this exercise was to make the wallpaper more calming. Removing elements goes hand in hand with that. It turned out that, for some, the path did not look like it was even leading to the castle. Others did not imagine themselves as wanderers on the path when they viewed the image.

So I removed it and also used that opportunity to improve the sand at the bottom edge of the screen so it would be closer in style to the sand I did not paint.

Finally, everyone was somewhat content with this. It might not be one of our best wallpapers of all time, but considering the time constraints it did not make a lot of sense to discuss this further.

However, we wanted to ensure that the original artist “axo1otl” was fine with the changes. The image would be published under their pseudonym after all.

The image was sent to them, and within one or two days they made a few final adjustments:

And what can I say? I like the changes. Better shadows and the drawing style of the water and sand I added were adjusted so one could no longer tell that they were painted by a different person. For this, some gradual colour transitions were replaced by discretely coloured steps.

So everything was fine and well, except the path reappeared. More generally, it seemed to me like the image was not based on my final version but on the one before that.

I might not know what happened there, but for me this was fine. Not everyone liked that the path reappeared, but considering that this is a rather minor detail, there was hardly any criticism.

Release

And then we released Plasma 6.1. However, due to unforeseen circumstances, the new wallpaper did not make it into the release! I will not elaborate on this topic, but I obviously was not happy to read that.

Furthermore, I noticed that the wallpaper that we nevertheless offered as a separate download was not the version “axo1otl” had sent us. It was my latest version. I hope “axo1otl” is not upset about that, but as far as I know, they will not create a new wallpaper for Plasma 6.2.

I have now created another version of the wallpaper based on “axo1otl”'s final version. The picture is identical to their version, aside from me removing the path. If you do not like the path, I would say that this is the best version for you. However, there are slight compression artefacts:

Plasma 6.2

For the next Plasma version our Promo Team wants a new wallpaper. There are already efforts to ensure that we will hopefully do a better job this time around.

I have suggested the creation of a new permanent category in KDE's forum in https://invent.kde.org/teams/vdg/issues/-/issues/52#note_972957 . I would want it to be a place for everyone to upload their self-made wallpapers. Maybe there are hobby artists out there who would enjoy doing that. I hope that some of the images would be great and well-suited as wallpapers for future Plasma versions to the benefit of us and everyone.

Kirigami Addons 1.3.0 is out. Kirigami Addons is a collection of components to enhance your Kirigami/QML application. This release contains many change related to the settings module.

ConfigurationView

The current way to create a settings page in your application is to use CategorizedSettings with some SettingAction for each setting page. This was based on Kirigami.PageRow which was then either pushed on a layer on mobile or to a seperate page on desktop. This turned out to be quite unreliable in practice as Kirigami.PageRow is a visual element.

The new ConfigurationView is based on a plain non-visual QtObject with for the moment two backends:

• One for mobile which looks similar to the Plasma Settings application of Plasma Mobile.
• One for desktop which looks similar to the System Settings application of Plasma Desktop.

The API is almost the same as the previous CategorizedSettings which made porting quite easy. Here is for example a button that open the settings.

import QtQuick.Controls as Controls
import org.kde.kirigamiaddons.settings as KirigamiSettings

Controls.Button {
 id: button

 KirigamiSettings.ConfigurationView {
 id: configuration

 window: button.Controls.ApplicationWindow.window as Kirigami.ApplicationWindow

 modules: [
 KirigamiSettings.ConfigurationModule {
 moduleId: "appearance"
 text: i18nc("@action:button", "Appearance")
 icon.name: "preferences-desktop-theme-global"
 page: () => Qt.createComponent("org.kde.tokodon", "AppearancePage")
 },
 ...
 KirigamiSettings.ConfigurationModule {
 moduleId: "about"
 text: i18nc("@action:button", "About Tokodon")
 icon.name: "help-about"
 page: () => Qt.createComponent("org.kde.kirigamiaddons.formcard", "AboutPage")
 category: i18nc("@title:group", "About")
 }
 ]
 }

 icon.name: 'settings-configure-symbolic'
 text: i18nc("@action:button", "Settings")

 onClicked: configuration.open()
}

With this change, both CategorizedSettings and SettingAction are now deprecated.

SpellcheckingConfigurationModule

With ConfigurationView each page is a ConfigurationModule and Kirigami Addons provides a ConfigurationModule for the spellchecking configuration of your application. This will allow to reduce code duplication between NeoChat, Tokodon, Marknote and more applications which uses Sonnet.

KirigamiSettings.ConfigurationView {
 modules: [
 KirigamiSettings.SpellcheckingConfigurationView {}
 ]
}

FormCard

FormCard design was slighly updated and now uses shadows as you might have already noticed from the previous screenshots.

SearchPopupField

Another component which is getting deprecated in SearchPopupField, there is now a replacement for that in Kirigami with the same behavior and I added an example how to port away to Kirigami.SearchDialog and I also ported all the know usage already.

Maintainance work

Aside from this major changes, there is ongoing maintaince works. This includes:

• Removing the accidental QtWidgets on Android caused by QtLabs.ColorDialog (me: Carl Schwan)
• Ensure all translated strings are loaded from the correct translation domain (me: Carl Schwan)
• The license dialog in the AboutPage is now opened in the correct window (Jack Hill)
• Fix the focus in the FormComboBoxDelegate (Joshua Goins)
• Fix the capitalization in the AboutPage (Joshua Goins)
• Increase the padding in FormCardDialog to match the other FormCard components

Packager Section

You can find the package on download.kde.org and it has been signed with my GPG key.

Hash-o-Matic 1.0.1 is out! Hash-o-Matic is a tool to compare and generate checksum for your files to verify the authenticity of them. It also verify files via their use PGP signatures.

This new release of Hash-o-Matic provides updated translations and some small visual changes. In the background, the application was ported to the new QML type registration, we now support building Hash-o-Matic on Haiku and we now require released version of KDE Frameworks instead of pre-released version.

Packager Section

You can find the package on download.kde.org and it has been signed with my GPG key.

Kommit 1.6.0 is a feature and bugfix release of our Git repo app which now builds with Q 5 or 6.

Improvements:

• build without kdbusaddons on windows
• Add flatpak support
• Fix show date (using QLocale for it)
• Fix mem leak
• Reactivate open file in external apps in qt6
• Add zoom support in Report Chart Widget
• Replace a QTableWidget by QTreeWidget in report page
• Fix crash when we didn't open git repository
• Fix load style/icon on windows (KF >= 6.3)
• Implement a gravatar cache
• Fix i18n

URL: https://download.kde.org/stable/kommit
Source: kommit-1.6.0.tar.xz
SHA256: 4091126316ab0cd2d4a131facd3cd8fc8c659f348103b852db8b6d1fd4f164e2
Signed by: E0A3EB202F8E57528E13E72FD7574483BB57B18D Jonathan Esk-Riddell jr@jriddell.org
https://jriddell.org/esk-riddell.gpg

AI is the current mega trend, and soon our mobiles and laptops will have the functionality integrated, bringing it closer to our daily lives.

While new technology such as AI surely has its use, it can also be healthy to critically have a wider perspective. With AI we can for instance:

• Have emails written for us in a manner we perhaps don’t have the skills to present in person
• Generate texts, such as CVs or cover letters, that we perhaps cannot back up
• Generating texts that we don’t necessarily understand, can fact check or vouch for

My question is:

What do we human beings gain from that computers — on their own — are sophisticated?

It is a shift, where computers have gone from being a tool that assists, to taking a role on its own.

Here are areas where innovation is badly needed:

• Mental health has plummeted seemingly connected with social media and mobiles. Is it VR glasses we need?
• With the Google Effect, also known as digital amnesia, people tend to forget what they searched. Considering the wide spread usage of search engines in our lives, improvement in this area would be massive. (Scientific replication seems questionable and one can problematise)
• The fast food markets managed to dopamine-hack customers with their perfected products, and currently the social media are successful at that as well, again at the cost of customers’ health. A form of “intelligent digital dopamine administration”, as wishful as it is, would mean the technology’s destructive impact is reduced
• Reading comprehension on screens is less efficient, and probably the majority read most of their content on screens. This a big thing. Screens are massively marketed and used, but still they are largely less efficient than books. The causes could be many. Perhaps an invention of e-ink books would be a massive productivity boost.

The young IT entrepreneur is hailed and the markets value as they do. I believe it’s wise to question what directions they take us.

AI and other new technologies are exciting, but ensuring that computers are helpful and constructive for us, is imperative.

In 2021 I decided to take a break from contributing to KDE, since I felt that I’ve been losing motivation and energy to contribute for a while‚Ķ But I’ve been slowly getting back to hacking on KDE stuff for the past year, which ended in me going to Toulouse this year to attend the annual KDE PIM Sprint, my first in 5 years.

I’m very happy to say that we have /a lot/ going on in PIM, and even though not everything is in the best shape and the community is quite small (there were only four of us at the sprint), we have great plans for the future, and I’m happy to be part of it.

Day 0

The sprint was officially supposed to start on Saturday, but everyone arrived already on Friday, so why wait? We wrote down the topics to discuss, put them on a whiteboard and got to it.

We’ve managed to discuss some pretty important topics - how we want to proceed with deprecation and removal of some components, how to improve our test coverage or how to improve indexing and much much more.

I arrived to the sprint with two big topics to discuss: milestones and testing:

Milestones

The idea is to create milestones for all our bigger efforts that we work (or want to work) on. The milestones should be concrete goals that are achievable within a reasonable time frame and have clear definition of done. Each milestones should then be split to smaller tasks that can be tackled by individuals. We hope that this will help to make KDE PIM more attractive to new contributors, who can now clearly see what is being worked on and can find very concrete, bite-sized tasks to work on.

As a result, we took all the ongoing tasks and turned most of them into milestones in Gitlab. It’s still very much work in progress, we still need to break down many milestones to smaller tasks, but the general ideas are out there.

E2E Testing of Resources

Akonadi Resources provide “bridge” between Akonadi Server and individual services, like IMAP servers, DAV servers, Google Calendar etc. But we have no tests to verify that our Resources can talk to the services and vice versa. The plan is to create a testing framework (in Python) so that we can have automated nightly tests to verify that e.g. IMAP resource interfaces properly with common IMAP server implementations, including major proprietary ones like Gmail or Office365. We want to achieve decent coverage for all our resources. This is a big project, but I think it’s a very exciting one as it includes not just programming, but also figuring out and building some infrastructure to run e.g. Dovecot, NextCloud and others in a Docker to test against.

Day 1

On Saturday we started quite early, all the delicious french pastry is not going to eat itself, is it? After breakfast we continued with discussions, we dicussed tags support, how to improve our PR. But we also managed to produce some code. I implemented syncing of iCal categories with Akonadi tags, so the tags are becoming more useful. I also prepared Akonadi to be cleanly handle planned deprecation and retirement of KJots, KNotes and their acompanying resources, as well as planned removal of the Akonadi Kolab Resource (in favor of using IMAP+DAV).

One of the tasks I want to look into is improving how we do database transactions in the Akonadi Server. To get some data out of it, I shoved Prometheus exporter into Akonadi, hooked it up to a local Prometheus service, thrown together a Grafana dashboard, and here we are:

We decided to order some pizzas for dinner and stayed at the venue hacking until nearly 11 o’clock.

Day 2

On the last day of the sprint we wrapped up on the discussions and focused on actually implementing some of the ideas. I spent most of the time extending the Migration agent to extract tags from all existing events and todos already stored in Akonadi and helped to create some of the milestones on the Gitlab board. We also came up with a plan for KDE PIM BoF on this years Akademy, where we want to present out progress on the respective milestones and to give a chance to contributors to learn what are the biggest hurdles they are facing when trying to contribute to KDE PIM and how we can help make it easier for them to get involved.

Conclusion

I think it was a very productive sprint and I am really excited to be involved in PIM again. Can’t wait to meet up with everyone again on Akademy in September.

Go check out Kevin’s and Carl’s reports to see what else have they been up to during the sprint.

Did some of the milestones caught your eye, or do you have have any questions? Come talk to us in our matrix channel.

Finally, many thanks to Kevin for organizing the sprint, Étincelle Coworking for providing us with nice and spacious venue and KDE e.V. for supporting us on travel.

Finally, if you like such meetings to happen in the future so that we can push forward your favorite software, please consider making a tax-deductible donation to the KDE e.V. foundation.

People of the Internet,

While working on keystroke events, I realized my improvements to the event.change property were still inconsistent for certain Unicode characters. This led me to delve into code units, code points, graphemes, and other cool Unicode concepts. I found this blog post to be very enlightening.

Here’s an update on my progress over the past two weeks:

MRs merged:

• event.change : The change property of the event object now correctly handles Unicode, with adjustments to selStart and selEnd calculations. !MR998
• cursor position and undo/redo fix : Fixed cursor position calculations to account for rejected input text and resolved merging issues with undo/redo commands in text fields. !MR1011
• DocOpen Event implementation : Enabled document-level scripts to access the event object by implementing the DocOpen event. !MR1003
• Executing validation events correctly : Fixed a bug where validation scripts wouldn’t run after KeystrokeCommit scripts in Okular. !MR999
• Widget refresh functions for RadioButton, ListEdit and ComboEdit : Added refresh functions as slots for RadioButton, ListEdit, and ComboEdit widgets, aiding in reset functionality and script updates. !MR1012
• Additional document actions in Poppler : Implemented reading additional document actions (CloseDocument, SaveDocumentStart, SaveDocumentFinish, PrintDocumentStart, PrintDocumentFinish) in the qt5 and qt6 frontends for Poppler. !MR1561 (in Poppler)

MRs currently under review:

• Reset form implementation in qt6 frontend for Okular : Working on the reset form functionality in Okular, currently focusing on qt6 frontend details. !MR1564 (in Poppler)
• Reset form in Okular : Using the Poppler API to reset forms within Okular. !MR1007
• Fixing order of execution of events for text form fields : Addressing the incorrect execution order of certain events (e.g., calculation scripts) and ensuring keystroke commit, validation, and format scripts are evaluated correctly when setting fields via JavaScript. !MR1002

For the coming weeks, my focus will be on implementing reset forms, enhancing keystroking and formatting scripts, and possibly starting on submit forms. Let’s see how it goes.

See you next time. Cheers!

This year again I participated to the KDE PIM Sprint in Toulouse. As always it was really great to meet other KDE contributors and to work together for one weekend. And as you might have seen on my Mastodon account, a lot of food was also involved.

Day 1 (Friday Afternoon)

We started our sprint on Thursday with a lunch at the legendary cake place, which I missed last year due to my late arrival.

We then went to the coworking space where we would spend the remaining of this sprint and started working on defining tasks to work on and putting them on real kanban board.

To get a good summary of the specific topics we discussed, I invite you to consult the blog of Kevin.

That day, aside from the high level discussion, I proceeded to port away the IMAP authentification mechanism for Outlook accounts away from the KWallet API to use the more generic QtKeychain API. I also removed a large dependency from libkleo (the KDE library to interact with GPG).

Day 2 (Saturday)

On the second day, we were greated by a wonderful breakfast (thanks Kevin).

I worked on moving EventViews (the library that renders the calendar in KOrganizer) and IncidenceEditor (the library that provides the event/todo editor in KOrganizer) to KOrganizer. This will allow to reduce the number of libraries in PIM.

• Remove KOrganizer plugins from kdepim-addons and move them instead to KOrganizer
• Do not use a complex plugin system for handling calendar invitation and instead provide the incidence editor as a binary and call it instead. (MR 1, MR 2 and MR 3)

For lunch, we ended up eating at the excellent Mexican restaurant next to the location of the previous sprint.

I also worked on removing the “Add note” functionality in KMail. This feature allow to store notes to emails following RFC5257. Unfortunatelty this RFC never left the EXPERIMENTAL state and so these notes were only stored in Akonadi and not synchronized with any services.

This allow to remove the relevant widget from the pimcommon library and the Akonadi attribute.

I also started removing another type of notes: the KNotes app which provided sticky notes. This application was not maintained anymore, didn’t work so well with Wayland. If you were using KNotes, to make sure you don’t loose your notes, I added support in Marknote to import notes from KNotes.

Finally I worked on removing visible Akonadi branding from some KDE PIM applications. The branding was usually only visible when an issue occurred, which didn’t help with Akonadi reputation.

We ended up working quite late and ordering Pizzas. I personally got one with a lot of cheese (but no photo this time).

Day 3 (Sunday)

The final day, we didn’t had any breakfast :( but instead a wonderful brunch.

Aside from eating, I started writing a plugin system for the MimeTreeParser which powers the email viewer in Merkuro and in Kleopatra. In the short term, I want to be able to add Itinerary integration in Merkuro but in the longer term the goal is to bring this email viewer to feature parity with the email viewer from KMail and then replace the KMail email viewer with the one from Merkuro. Aside from removing duplicate code, this will improve the security since the individual email parts are isolated from each other and this will makes it easier for the email view to follow KDE styling as this is just normal QML instead of fake HTML components.

I also merged and rebased some WIP merge requests in Marknote in preparation of a new release soon and reviewed merge requests from the others.

Last but not least

If you want to know more or engage with us, please join the KDE PIM and the Merkuro matrix channels! Let’s chat further.

Also, I’d like to thank again Étincelle Coworking and KDE e.V. to make this event possible. This wouldn’t be possible without a venue and without at least partial support in the travel expenses.

Finally, if you like such meetings to happen in the future so that we can push forward your favorite software, please consider making a tax-deductible donation to the KDE e.V. foundation.