I tooted posted on Mastodon about how it would be great if more open source project would adopt REUSE.

Someone pointed out that it would be great to automate the addition of the metadata inside the files based on the git repository.

So here is a small script that does exactly that. It goes over all your .cpp and .h file and will add the header based on the list of authors as well as the first commit on that particular file.

You will want to adapt it to the license you are using for your project as well as change **/*.cpp to **/*.py if you are doing Python development.

#!/usr/bin/env bash
# SPDX-FileCopyrightText: 2023 Carl Schwan <carl@carlschwan.eu>
# SPDX-License-Identifier: MIT

for file in **/*.cpp **/*.h;
do
 year=`git log --format="format:%ci" --reverse $file | head -n1 | cut -d "-" -f 1`
 git shortlog -n -e -s -- $file | cut -f 2 | while IFS= read -r author
 do
 reuse annotate --copyright "$author" --year "$year" --license "GPL-2.0-or-later" $file
 done
done

This is not perfect and you want to run git diff before commiting the result, to check if the change made are fine.

At KDE we make software for many different platforms. One of them is Microsoft Windows. But what if an application crashes on Windows? New tech enables us to track crashes right in Sentry! Time to learn about it.

When an application crashes on Windows the user can submit crash data to Microsoft. Later KDE, as publisher of the app, can retrieve the crashes from there. This is the standard crash handling for the platform and it works incredibly well. What’s more, it means we don’t need to engineer our own custom solution for the entire process. So, that is all lovely.

Alas, since we are rolling out a KDE-wide crash tracking system called Sentry it would be even nicer if we had Windows crashes in there rather than third party service. That is just what I’ve built recently.

Crashes for our Windows applications now get imported into Sentry!

There are two pieces to this puzzle. One is a symstore and one is the actual importer.

Symbol Storage

In the Linux world we not so long ago grew debuginfod, it’s basically a tiny service that lays out debug symbols in a standardized file path so it may be consumed by any number of tools by making HTTP GET requests to well-known URIs.

Windows has something like this called symbol storage. It’s incredibly simple and merely lays out Windows debug information in a well defined path setup for consumption in tools.

To maintain a symstore of our own we use the excellent python module symstore along with some custom rigging to actually retrieve our debug information files.

Import

The second piece is our importer. It’s a trivial program that uses Microsoft’s APIs to retrieve crash data along with the minidump (the dump format used by Windows crashes), converts it into a Sentry payload, and sends it off to our Sentry instance. Sentry then consumes the crash, does symbolication using the debug symbols from our symstore, and generates a crash event.

Support

If you are shipping your application on the Windows Store you should consider publishing your dbg.7z files on download.kde.org (for example here is Okular), simply file a sysadmin ticket same as with any other upload to get this published. Once that is done you can submit a change to our symstore to publish the debug symbols, and our importer to import data into Sentry. If you need help just give me a poke.

If you are publishing builds for Windows but are not yet on the Window Store, you definitely should change that. It increases your application’s reach considerably. Get in touch with sysadmins to get yourself set up.

Importing crashes into Sentry adds another piece towards higher quality, more actionable crash reports. It’s going to be amazing.

Discuss this blog post on KDE Discuss.

(German version of this post: https://wordsmith.social/felixernst/akademy-2023)

37 °C were the average daily temperature heights during the Akademy week in Thessaloniki. When you walk outside at these temperatures, your first thought is that you would rather go back inside. This used to be a temperature that one would hardly ever see there. 38 °C has not been exceeded in Thessaloniki in the 5 year span 1980 to 1984. But actually we were lucky, because the real heat wave only came around when we already left with around 44 °C in Thessaloniki and forest fires everywhere. It is a shame that with the current global political landscape none of this seems likely to become any better (to put it mildly) within our lifetimes. The nature in Greece is very nice aside from that.

But I think I have already exceeded my doom quota for this report, so back to brighter topics like the KDE community!

Meeting Everyone

I usually throw myself into these events, talking to everyone I haven't met yet and doing my part in making sure everyone feels welcome. It was especially interesting to talk to the local Greek students attending the event. One of them is already making attempts at contributing to Dolphin. I don't want to praise and pressure him here by saying his name already, but if you see a new Greek name on “This Week in KDE” in the next few weeks/month, you will know.

Some of the Greeks were part of the key note presentation “Libre Space Foundation – Empowering Open-Source Space Technologies”. Their passion for bringing their open source software to space was contagious.

I, on the other hand, am still stuck on this planet that gets hotter by the day. Did I mention the heat already? Oh right, back to topic…

Since becoming a maintainer of the Dolphin file manager about a year ago, I try to look out for the long-term health of the project. In that regard, I had an idea about how everything could go horribly wrong at this years Akademy:

Meeting the Other Dolphin Maintainer

I had never actually met the Frenchman Méven Car, who I share maintainership of Dolphin with. We hardly sent any direct messages to each other ever and none of them before April this year. All of this might seem strange considering that we have worked on Dophin together for a while now, but it also shows that one doesn't need to work behind closed doors to bring software forward. The most important aspect is having an atmosphere in which the technical and UX merits of work can be discussed honestly and without fear.

So one possible way our first meeting could go was, that we loathe each other. The next logical step would then be that we don't trust each other to be good stewards of the Dolphin project. One of us then creates a competing fork, which follows a different but similar vision, and in the end Dolphin would be stuck in an unpleasant atmosphere of hostile accussations and bad stability, eventually leading to its demise into irrelevance. ?

In actuality, this didn't happen though. Phew!
But the above paragraph was the first story I told him.

We actually get along very well and had much time to talk about matters pertaining to Dolphin. It doesn't really seem like we have different ideas about what work needs to be done for further world domination.

Speaking of which:

Dolphin's Strategic Position

At last year's Dolphin meeting I had already tried to figure out the biggest areas of improvement by making this the headline of the meeting. Read all about it over here.

By this time, it seems like we are aware of most aspects that are still lacking in some regard. I am not really encountering a lot of fundamental criticisms anymore that I am not already aware of or which we don't know a way forward with. Most of the time we are lacking the work force to fix the more long-standing issues soon™.

Some of these were discussed at the Dolphin meeting at Akademy.

Especially Dolphin's search functionality was a big topic. It is kind of sad that people can't always rely on the Dolphin search to quickly find their files. This is partially for technical reasons, but also for user interface design reasons. You can read all about it here: https://invent.kde.org/system/dolphin/-/issues/46 Currently we are looking for a clear direction when it comes to the Dolphin search UI. You can find a mockup I made when you follow the link, but as long as nobody else is commenting on it or bringing their own design, there is no consensus. There are a lot of more technical background topics that need work as well though.

I was also wondering what Dolphin can gain from trying to break out of the Linux/Unix eco-system. Projects like Krita and Kdenlive were successfull in finding a user base outside of Linux. Dolphin is already one of (or even) the most popular file manager(s) on Linux. How much room for growth might there be if Dolphin's Windows version were more polished and visible for Windows users? Currently we don't seem to have people who want to fix bugs for this proprietary platform in their free time. Similar things could be said about a Mac or potential mobile version of Dolphin.

In line with KDE's current goals we also talked about improving testing using Selenium and AT-SPI. There is already some progress on this. Next there is the accessibility goal, for which I can point to a merge request I started creating while in Greece: https://invent.kde.org/system/dolphin/-/merge_requests/577 There is however still a lot of room for improvement when it comes to accessibility in Dolphin. Most annoyingly the “Back” and “Forward” buttons can currently not be focused using the Tab key. More contributions are always welcome in that regard. After attending all the talks about accessiblity I could find at this year's Akademy I feel a lot more confident about being able to review such contributions.

Méven has covered some more Dolphin topics in his article, so I will refer you to it: https://www.bivouak.fr/dolphin-at-akademy-2023/

Aside from Dolphin

…there is a lot more to talk about. So much more actually that it is becoming very apparent to me that I should probably cut it short now. Many of the talks are available on Peertube.

One more talk I want to highlight is “Make it talk: Adding speech to your application” by Jeremy Whiting. That one was about using speech more often in applications. I liked that talk not necessarily because I think there was a good way to add more speech to Dolphin in particular, but because it encourages improvements to tried and old basics of application design. If there was a “Speak” button next to this text you are currently reading, you would be able to transform this reading exercise into a podcast-like experience and a five-year-old kid could have listened along (and be bored about the tech-speak). I think a similar talk could be made about using animations for improved clarity when the state of an application or some data changes.

Thanks to the people who made this possible

Akademy would have been a very lonesome experience if we didn't have donors, sponsors and volunteers allowing everyone to come together. I am not sure if an international community like us could function long-term without such meetings. It gives me hope when people from eight different nations can sit at one table, talk about politics and still have a good time.

After personally meeting the people who manage the donation money, I can say with full confidence that donation to the KDE e.V. are in good hands and spent with diligence and strategy to ensure the long-term existence and growth of the wider KDE community. If you would like to donate to this non-profit entity, visit https://kde.org/community/donations/.

About

What are Input Methods?

Input Methods are a way of allowing third parties programs to manipulate text in text input boxes in applications.

The two traditional uses of this are on-screen keyboards like one has on a mobile phone, and Chinese, Japanese and Korean (CJK) input where a keyboard doesn't map directly to the text we want to see on screen.

It's a lot more than merely injecting keys; the input method needs to have an awareness of the text cursor and the ability to manipulate whole words and sentences at a time. This is extremely important for the CJK way of typing where multiple keyboard keys are used to compose a single character. It's also important for virtual keyboards that have advanced features like auto-completion and spell-checking words.

X vs Wayland

On X11, the standard protocol (XIM) is hardly used, we ended up with every input method creating a plugin for every toolkit. This sufficed, but was not very scalable, doesn't have the best desktop interaction, and is messy to deploy.

The story with wayland is also far from perfect. With the compositor acting as a broker, we have a protocol from the plugins themselves (InputMethod) and protocols to clients (TextInput). Unfortunately there are at least 6 active versions of these protocols, which needs some work.

A recent meeting with other wayland devs has hopefully helped agree on a path forward for the TextInput side, with me taking on a lot of active tasks moving this forward. But we still need to sort out the InputMethod side.

I used Akademy to speak to people using CJK input and got very valuable feedback about the Korean language and some changes needed to make FICTX work properly there.

If you have experience with Chinese or Japanese input on wayland, please do reach out.

A Playground of Input Method Ideas

I don't use CJK keyboard entry nor a virtual keyboard on a daily basis, but there are things I do use that could benefit from the InputMethod tech. Now we have a standard we can look at using this stack for more creative ideas. Doing this now can help work out what the requirements are for the protocols as we stretch it in new directions.

This post describes some ideas of how else we can use Input Methods to improve the Linux desktop experience.

Convenient Clipboard Connections

With a shortcut we can enter clipboard entries, previewing in place. We're able to use the preedit text to display metadata on available entries which won't get committed to provide a streamlined interface, or we could bring up a menu, or both.

Compared to the existing klipper integration we can open at the current carret position, and provide something a bit more streamlined. The preview also helps solve the frustrating problem of pasting only to find you've now got too much or too little whitespace where you hit paste.

Easy Emoji Entry

My attempt at understanding young people. Typing ':' and then a string launches an inbuilt emoji browser based on the typed string.

These days a lot of clients now have in-built support, including all GTK4 text areas, so it might not be needed. Maybe the ship for this has sailed, or there could be still value in centralising it and having a common pattern.

Direct Diacritic Display

Building on an existing merge-request by Janet Blackquill, pressing and holding a key will bring up a prompt with relevant characters based on the held key.

The original version merge request injected itself into the application repurposing a hook meant for themeing, this broke too many clients to be released as part of Plasma and it was unfortunately reverted.

Taking that idea but using input methods should avoid those problems, whilst also solving the issue of key-repeats being sometimes needed.

Timely Translation Tasks

This was solved by having a second text field open when activated where the user can type their native text, so the translations can be shown in the main text area. The current code utilises the command line tool "trans" which in turn makes web requests to proprietory web services, but we could look at other options if we turned this into a product.

Simply Speak

The one I'm most excited about. Working local dictation software that can integrate into every textfield out of the box.

I got best results using whisper-fast with a voice-activity filter on top. This was wrapped into a daemon with a DBus interface we can then use to start and stop on demand. It needs some work to be a shippable product.

Current State

All of the above are fully working examples, but everything was pieced together in a few evenings at Akademy and some time at the airport.

It's not something I would ship to users; the point right now is to be a playground, uncover issues throughout the stack, and try a few different things. That's why we use different techniques for bringing up the input methods and prompts within it rather than trying to be coherent.

That said, I have made an effort to separate the high level application code from the wayland boiler plate so we can quickly iterate to InputMethodV3 to see what's needed, and turn this into a product as we start to come up with a long term direction.

Running it for yourself

The repo exists at https://invent.kde.org/davidedmundson/inputmethod-playground the readme has instructions on how to get set up.

What does it work with?

A form of TextInput is supported in almost all toolkits from Electron, GTK, Qt, SDL and more. This means it's fairly universal across wayland clients.

On the compositor level, InputMethodV1, the only specification in upstream protocols, is supported by only Kwin and Weston, but as noted in the intro this is subject to change in the future.

Future

The playground has exposed several pre-existing deficiencies, especially regarding the placeholder text styling, input panel positioning, key repeats. We can take those forward into fixes that might affect the more important CJK input methods.

As well as being a playground I think there are some ideas worth exploring further, to find a path into the desktop and is yet another reason to be excited about the path to Wayland,

Have more ideas? Let us know in the discussion at http://discuss.kde.org.

Every once in a while I hear developers having trouble staying up to date with KDE Discuss(ions). No great surprise when I then find out they aren’t tracking things (in other words: not subscribed to categories)!

Discourse, the software that powers KDE Discuss, has a number of handy notifications settings that we can use to have the software bring posts to us instead of having to go to the website every once in a while. We can use these options to tailor a good experience for ourselves.

Three setting types are relevant for the notification experience:

Tracking

Tracking preferences control which discussions to track. Settings here range from when automatic tracking happens - such as when you view a topic for a couple minutes it automatically becomes tracked - to ignoring things. You can track categories as well as tags. Say you only care about kdenlive you can simply track the kdenlive tag and you are good to go.

Emails

Emails contain the second most relevant pool of preferences. There are two principal modes of operation:

• Forum mode
• Mailing list mode

The names should be obvious enough, the functionality probably less so. In forum mode tracking preferences apply and you get emails for posts or threads as configured. In mailing list mode only negative tracking preferences apply! You get an email for every post on the entire site unless you’ve opted to mute something. In both modes you can simply reply by email to post a reply.

Notifications

These preferences have to do with live notifications i.e. if you have a browser open it will throw up a system notification when new posts happen. The settings here aren’t terribly interesting unless you always have a browser tab pointing to KDE Discuss. If you do, you can set a time frame for notifications such that you don’t get notifications when you are at work-work for example.

Recommendations

So, what do I recommend you do?

First off, if you want to keep things low-volume make sure you have the email preference Activity Summary enabled. It sends a summary email once a day with tracked topics. You can disable most everything else. You definitely want to set up tracking for what you want to receive in your summary (unless of course you want to see all threads). e.g. if you only care about dev topics then set the Development category to tracking.

One step up from the summary is actually the default mode of KDE Discuss. By default if you simply configure tracking as desired you’ll get a reasonable mix of notifications and a summary if you haven’t been around in a while.

The most intense setup is to activate mailing list mode. This operates like a mailing list and causes the highest volume of emails. You’ll want to set up email filtering to go along with this. I would definitely not recommend this unless you really care about all discussions on the entire site.

You should also note that you can reply by mail to threads, regardless of whether mailing list mode is enabled. It’s amazing!

And lastly: you can configure most anything, so if you find that you are getting too many emails or too few just head to the preferences and play with some of the options. I’m confident everyone is able to find a good mixture that makes the most out of KDE Discuss :)

Discuss this blog post on KDE Discuss.

The month of July is already wrapped up, I can’t believe it! I went to Akademy this year, and it was really great! Between Akademy and the imminent gear release, I didn’t get much work done this month - but oh well.

I also closed the majority of my old MRs, which either aren’t needed anymore or not applicable. Whats left is features that are still on the backburner (like tablet dial support, Kirigami context menus, etc) that I want to finish.

Tokodon

The next release of Tokodon (23.08) is approaching next month, so I’m focusing on small improvements again. A round of bugfixes for accounts, the fullscreen image viewer not closing, improving the conversation page, removing papercuts for statuses, and making the profile page even better landed early this month.

I have a touchscreen laptop now, and I’ve been able to improve the touch experience for interaction buttons. Expect more touch-related improvements in the future, as before I only had a PinePhone and an Android device to test with. Carl did a lot of profiling work, and I specifically updated the blurhash implementation which makes it oh-so slightly faster to generate. This and the other performance improvements makes scrolling the timeline much smoother.

A big feature I’ve personally been waiting for has now landed, an emoji picker for the status composer! I took this from NeoChat (of course) and slightly modified it for our needs. This is something that could use some improvement in the future, but I’m glad we have this now.

Another smaller but great feature is that account mentions now open inside of Tokodon (like hashtags do already) without kicking you back to a web browser.

PlasmaTube

This is something I’ve wanted for a while now, watch indicators now work for logged in Invidious accounts! These are synced to your Invidious account, so they show up on the website and other 3rd party clients. Partial watches are not yet supported, but I do have an idea of how they could work. Eventually, I want to expose a way to mark videos as “unwatched”.

I also added pagination for the subscription feed but the merge request is currently awaiting review.

NeoChat

Three small changes to NeoChat this month, I fixed the emoji popup shadows and added a more obvious upload button for avatars. And finally gave NeoChat the prettier notifications, like I did for Tokodon last month.

Gamepad KCM

The Gamepad KCM is being prepared to enter KDE Review soon! See the current repository and it already runs in Plasma 6. Jeremy Whiting and I have been working to get the KCM in a nicer state, see my merge request overhauling the C++ backend (I still need to finish it…)

While the KCM isn’t perfect yet, I’m hoping to get it in a “good enough” state to attract more help. If you are interested in fixing the design, code, or drawing controller SVGs we welcome your help!

Akademy

Since I arrived late to Akademy, I only attended BoFs and didn’t have the chance to view the talks. I plan on detailing more of my trip in a future post, but I haven’t had the energy to write.

I went to Carl Schawn’s Plasma Mobile BoF, and the “Contributor On-ramping” BoF held by Joseph De Veaugh-Geiss. It was good, but I arrived late and wasn’t able to catch much of it. I also went to the Plasma 6 BoF afterwards, but most of the time was spent talking about the release date schedule. One of my favorite BoFs was probably Joseph’s Wiki BoF. There was a surprising number of people and it was very productive. We decided on a lot of things: getting on the same page about techbase/userbase (and the problems with keeping them around), removing the wiki theme, and more. You have probably noticed some of the changes even now!

On Thursday, I attended Carl’s Accessibility BoF. I learned how to use Accerciser, and I noticed some accessibility issues in Tokodon which are fixed now! I also spent some time on Thursday improving the Matrix page, which I’m very happy with. I also hooked up with Volker Krause to help Tokodon on Android along, which is now fixed. (Thanks so much!) We also discovered an error in the Android build documentation, as it turns out the docker registry version of the images is no longer maintained. That caused a bunch of issues since NDK paths changed since the old Docker image was updated, which Volker fixed.

It was nice meeting everyone at Akademy, I wish I came sooner because I didn’t have the chance to talk to some people. See you next month!

A neat trick to debug the keyboard navigation in your QML application is to put the following code snippet in your main.qml:

Kirigami.ApplicationWindow {
 ...

 title: activeFocusItem + " " + (activeFocusItem ? activeFocusItem.Accessible.name : "")

 ...
}

Afterward, then you open your application, you will see the following in your title bar:

“PrivateActionToolButton_QMLTYPE_XX(0x00000000)” is the type and address of the actively focused item and “Sort” is the accessible name of this item.

If you tab around your application, you will be able to identify multiple issues quickly:

Missing Accessible.name

You might notice that some elements only display their type and address but accessible name. It is an issue because this means the screen reader user won’t have any clues about what the button does.

If this is the case, ensure that your control has a text property set even if the control itself overrides the contentItem or is an icon only button. If you can’t use the text property, try to set the Accessible.Name property instead.

HTML code in your text

If you see some HTML code appear in your toolbar, it is an issue. Screen readers will be confused by the random XML tags in your text, so make sure to remove them from the Accessible.Name. A simple fix which works in some simple cases is to do the following to clean up your text:

QQC2.Label {
 text: "Hello <b>World</b>"
 Accessible.name: text.replace(/<\/?b>/g, '')
}

Not clear Accessible.Name

By default, your Accessible.name of your controls is bound to their text, which is a good default but you shouldn’t hesitate to add some mode details in your Accessible.Name.

One example, I had in Merkuro (formally known as Kalendar) was in the month view. There each day had as text the month number. In this case, it’s better to expose the whole date to the accessibility API, because without, context a number is not that useful.

Focused but not visible

Some items are focused but are not visible on the screen. This often happens when using a PathView/ListView with only one item visible at the time, since the previous and next item are still loaded. If this is the case, ensure that activeFocusOnTab is set to false, when the item is not visible.

Focused but no visual indicator

Some items are focused but they don’t have a focus indicator. This is an issue since the user won’t able to know which item is currently focused and then pressing space they might trigger a random action.

There is an helpful property in QQC2.Control named visualFocus which should be true when the user uses keyboard navigation to focus on a specific item. So make sure to add for example, a special border when QQC2.Control.visualFocus is true to your custom controls.

// MyButton.qml
QQC2.Button {
 id: root

 background: Rectangle {
 border {
 width: root.visualFocus ? 1 : 0
 color: Kirigami.Theme.highlightColor
 }
 }
}

The type information can gives you a valuable information to find which item is currently selected and has the broken focus.

Focus loop

In some cases, when pressing tab multiple times, you will end up in a focus loop with no way to escape it. This might be caused by broken usage of the KeyNavigation.tab property, dynamic reparenting of elements and other creative ways to break the tab navigation. In case, please fix it!

Unfocusable elements

Make sure all your interactable elements in your application are focusable by default. You can enable or disable this behavior, with the activeFocusOnTab property of Ìtem.

The OpenUK Awards are open for nominations for 2023.

Awards timetable

• Nominations open 28th July 2023
• Nominations close midnight UK 19th September 2023 (this will not be extended)
• Shortlist of up to 3 nominees per category announced 18th October 2023
• Winners Announced 20th November 2023: Black Tie Awards Ceremony and dinner at House of Lords sponsored by Lord Vaizey, 6-10.30pm, tickets limited 

Self nominations are very welcome. If you know fit into the categories or have a project or company which does or know anyone else who does then fill in the form and say why it’s deserved. You might get fame and glory or at the least a dinner in the house of lords.

Quick reminder, that you can include a Mastodon or Matrix link to your AppStream file and that the link will then be displayed in your application page at apps.kde.org.

<custom>
 <value key="KDE::matrix">#merkuro:kde.org</value>
 <value key="KDE::mastodon">https://kde.social/@merkuro</value>
</custom>

Last week, I went to Akademy, the yearly KDE conference, in Thessaloniki. This is now my third in-person Akademy and fifth Akademy in total. As always, this is the occasion to meet old and new friends, learn about what others are hacking on and enjoy good food.

Friday

I arrived Friday afternoon, taking my flight from Nuremberg with a few others. Getting out of the airport, we could immediately feel the heat. After leaving our stuff at the hotel, we went to join the rest of the KDE folks at the welcome event in a frindly and cozy bar.

Saturday

On Saturday, I talked about the current state of the Accessibility (a.k.a KDE For All) goal. In short, we are making progress on that and fixing bugs everywhere in the stack, but we desperately need more community involvement as the task is big. Hopefully, the Selemiun AT-SPI bridge can be helpful, as it makes it possible to write integration tests using the accessibility API which require some accessibility support in your application to work. (Slides)

I also presented the Fundraising WG report. We had two successful fundraising campaigns this year: Kdenlive and the end of the year campaign. (Slides)

My highlight for the day was the KDE Embedded talk from Andreas. The talk explained the progress in getting the whole KDE software packaged as Yocto layers, which already allows us to build images for RISC-V and ARM devices with Plasma BigScreen. There is definitively a lot of potential there to get KDE technologies in a wide varieties of devices. A recent example is KWin being integrated inside Mercedes cars’ infotainment system, resulting in various upstream improvements. (Slides)

Sunday

On Sunday, I had a talk with Tobias Fella about Matrix and Mastodon and how we can integrate these protocols inside our applications in various ways. First, by providing clients for these protocols: NeoChat (Matrix) and Tokodon (Mastodon), but also with less oblivious ways like using Mastodon as a comment system on your blog or by using Matrix to share your KDE Itinerary live data end-to-end encrypted with your friend without requiring a centralized server. (Slides)

My highlight for Sunday was the Selenium GUI Testing talk from Harald, which is closely related to my Accessibility goal and Automatisation goal from Nate. (Slides)

The lightning talks were also excellent. Kai showed off his integration of AlphaCloud inside Plasma to get his solar pannel stats. (Slides)

Jean-Baptiste Kempf (from VLC) presented his cross-platform remote control software stack in Rust, which promises very low latency.

Fabian Kosmale from the Qt Company Group presented the qmllint tool, which should really helps improve the quality of our software and reduces the risk to accidentally create regressions in our QML applications. I’m looking forward to using it on my applications and to building custom plugins for it. (Slides)

Finally, Nate presented the new Plasma Welcome wizard, which is great! (Slides)

Bofs

The rest of the week, we had “Birds of a Feather” (or BoF) which were particularly productive. I (co-)hosted multiple BoFs this year: Plasma Mobile, NeoChat, KDE PIM and Accessibility, but I also enjoyed a few other BoFs: the fundraising BoF where Victoria gave us a lot of advice on how to do fundraising for non-profit and the KDE e.V. board office hour or the Selemiun BoFs from Harald and a few others.

Day trip

We went to Mount Olympus, Dion, and a beach for our day trip. As a ancient Greece nerd, I enjoyed it! Here are some photos from the trip:

Trainings

We also had training at Akademy. I participated to the one from Nuno (thanks, KDAB for offering it) about Qt Design Studio, a very powerful QML visual editor and with a bridge to Figma. Unfortunately, I couldn’t attempt this training fully because it conflicted with a BoF I was hosting, but the bit I saw there was very interesting. It would be great if we could integrate Kirigami components inside this tool.