We’re already in November, but I managed to do a lot of work this month which I’m really happy about.

Quickly something that’s not strictly programming: I was accepted as a member of KDE e.V. early this month, thank you all very much! I was also given moderation powers on Discuss so maybe it will stop rate limiting me when moving posts around.

I also went on a crusade of merging and triaging merge requests on Invent, which some of you might’ve seen. Notably I was able to take care one or two pages worth of open MRs, which I’m really happy about.

Without further ado, let’s begin.

Plasma

[Feature] Merged the Game Controller KCM into Plasma, starting with a simple rewrite in QML. I’m aiming to add back the visual representation in 6.1 (which still exists in the standalone repository if you want to take a shot at it.) At least for right now the code is much better and it supports more devices than the 5.X Joystick KCM ever could. [6.0]

My hope is that since it’s much cleaner and easier to work with, it would invite more contributors… and it’s already doing that as we speak! :-)

NeoChat

[Feature] Blockquotes now look more like quotes, and no longer just somewhat indented blocks of text. [24.02]

[Bugfix] You can now right-click (or long tap) on rooms to access the context menu without switching to it. I gave the treatment for spaces a while back. [24.02]

[Feature] Added UnifiedPush support! It’s functional already and I have used it to receive push notifications even when NeoChat is closed. [24.02]

Tokodon

[Feature] I merged the post redesign I was teasing on Mastodon, which includes better margins and standalone tags. [24.02]

[Feature] The language selector is now a regular dialog and not the buggy custom combo box we had before. It now displays the native language name, if available. [24.02]

[Feature] Muting and blocking users has been accessible through profile pages, and now those actions are present in the post menu like on Mastodon Web. Useful for taking action against harmful users without navigating to a cesspool of a profile too. [24.02]

[Feature] Added a report dialog. It’s a little basic right now, which I want to improve before release. [24.02]

[Feature] Rebased and merged Rishi’s Moderation Tool, which works fantastic and I used this to test my reporting feature! [24.02]

[Feature] Added a way to filter out boosts and replies from timeline pages. [24.02]

[Feature] Added supports for lists. You can’t add people to lists (you must use another client to do that) but you can at least view and manage them. [24.02]

Kiten

[Bugfix] Marked the X11 socket as fallback. This removes a warning on the Flathub page about the deprecated windowing system. [23.08]

[Bugfix] Numerous UI improvements, such as improving the margins of configuration dialogs. I also redid the toolbar layout. [24.02]

[Feature] Added a search function to the Kanji browser. [24.02]

Kirigami

[Bugfix] Fixed an edge cases of ToolBar incubation, which liked to spam logs. I squashed some other log spam, so Kirigami applications should be less noisy. [6.0]

[Feature] Added a property to FlexColumn that allows you to read the inner column’s width. We use this in Tokodon to set the width of the separator between posts. [6.0]

Craft

I’m getting addicted to fixing Craft recipes, and there’s a lot to fix in the upcoming 6.0 megarelease:

• Preparing Tokodon for Qt6
• Preparing MPV for an eventual Windows build by only requiring Linux-specific video APIs on Linux
• Added a blueprint for MpvQt for future use in Tokodon and PlasmaTube
• Added a KUnifiedPush blueprint for future use in Tokodon and NeoChat
• Preparing KWeatherCore for Qt6
• Preparing KWeather for Qt6

KUnifiedPush

[Feature] Improved the look of it’s KCM. Not only does it look nice, and it’s design is more in line with other list based ones.

PlasmaTube

[Feature] Added better hover effects for video items. I did a bunch of refactoring to unify the two types (list and grid) so they work better in general (especially for keyboard-only navigation.) [24.02]

[Feature] Added a video queue system, which is exactly what you think it is. You can queue up an entire playlist, or add videos manually like on YouTube. [24.02]

[Feature] Different types of search results is supported now, so you can find channels and playlists. [24.02]

[Feature] Public Piped instances are now fetched and displayed on initial setup. [24.02]

[Feature] Features of PlasmaTube that are unsupported by the current video source are now disabled or hidden. This should result in less buggy and broken looking behavior depending on which video source you use. [24.02]

[Feature] Added support for MPRIS, which is used by the Media Player applet, the lockscreen and KDE Connect. [24.02]

Accessibility

[Bugfix] Fixed our spinboxes not being read correctly by screen readers, since they were editable by default. Now the accessible descriptions and other data is passed down to the text field. Fixed in QQC2 Desktop Style (used on Plasma Desktop) and QQC2 Breeze Style (Plasma Mobile and Android.) [6.0]

Documentation

Found lots more missing Bugzilla links in Invent, and did some more README updating!

• Added missing Bugzilla link for Ruqola
• Updated README for Kiten, adding a screenshot
• Added Snap store links for NeoChat and Tokodon
• Added missing Bugzilla product for kdesrc-build
• Expanded plasma-integration’s README
• Wrote the README for our new Accessibility Inspector
• Expanded the README for qqc2-desktop-style, and now contains usage information and why it’s different than qqc2-breeze-style. Did the same for qqc2-breeze-style too

KWeather

[Bugfix] Fixed the setup wizard. [24.02]

Upcoming

[Feature] Not merged yet, but I’m adding a pen calibration tool to the Tablet KCM. If you have the required equipment and can test, please help out! It’s cutting it close to the feature freeze, so this will most likely be pushed off until 6.1.

See you in December!

For some time now, Qt has been internally utilizing RHI (Rendering Hardware Interface), a new cross-platform technology for graphic rendering. Since Qt 6.6, this API has been semi-public, meaning that the API is mature for practical use but may still be subject to potential changes between major Qt versions.

In this blog post, we demonstrate how to to get started with RHI.

Continue reading Hello, RHI – How to get started with Qt RHI at basysKom GmbH.

This weekend Sofia and I celebrated her birthday with her family. Lars Winnerbäck, Wicked at the opera and a wonderful dinner at Natur.

The migration of jobs from Binary Factory to KDE's GitLab continues. Last week almost all jobs that built APKs were migrated to invent.kde.org. The only remaining Android job on Binary Factory doesn't use Craft.

The Android APK jobs running on invent are the first jobs that make use of our CI Notary Services delegating tasks that require sensitive information (e.g. the keys to sign the APKs or the credentials to upload the APKs to our F-Droid repositories) to services running outside of GitLab. Currently, the apksigner service and the fdroidpublisher service are live. The configuration of the services can be found in the sysadmin/ci-utilities repository.

As before, the APKs are published in our F-Droid repositories:

• KDE Android Release Builds provides APKs built from the 23.08 branches.
• KDE Android Nightly Builds provides APKs built from the master branches.

The migration to invent has a few implications. On Binary Factory all APKs (release and nightly) were rebuilt once a day even if nothing changed. On invent the APKs are rebuilt whenever a change is pushed to the release/23.08 branch or the master branch of a project. Another change is that on invent any KDE developer can manually trigger a new pipeline to build the APKs (e.g. if a bug in a dependency was fixed). On Binary Factory you often needed to ask someone to trigger a build for you.

Building APKs If you want to start building APKs for your project then add the craft-android-apks.yml template for Qt 5 or the craft-android-qt6-apks.yml template for Qt 6 to the .gitlab-ci-yml of your project. Note that you must use the include:project format (example).

The jobs will build unsigned APKs. To enable signing your project (more precisely, a branch of your project) needs to be cleared for using the signing service. This is done by adding your project to the project settings of the apksigner. The master branch is cleared by default for all applications listed in the project settings, so that you only need to add two lines: The repo path on invent and the ID of your application. The key used to sign your application will best be created by us directly on the machine that does the signing.

Once you think the APKs are ready for publication you can enable publishing in our F-Droid repositories by adding your project to the project settings of the fdroidpublisher. Because some Qt 6 APKs are not yet ready for publication although their build succeeds, by default the master branch is not cleared for publishing. This means you will have to add five lines to the project settings of fdroidpublisher.

Outlook To complete the Android jobs/services a job/service for submitting APKs to Google Play will go live soon. It's currently only used by Itinerary but, in view of our Make a Living initiative, we hope to publish more apps on Google Play to create some revenue to fund our work. Creating and publishing Android Application Bundles (AAB), the new packaging format required for new applications published on Google Play, will follow soon after.

Then we'll add signing of Windows artifacts and installers and submission to the Microsoft Store, signing and publishing of Flatpaks, and signing and publishing of builds for macOS.

Today, 12 years after the meeting where AppStream was first discussed and 11 years after I released a prototype implementation I am excited to announce AppStream 1.0!

Check it out on GitHub, or get the release tarball or read the documentation or release notes!

Some nostalgic memories

I was not in the original AppStream meeting, since in 2011 I was extremely busy with finals preparations and ball organization in high school, but I still vividly remember sitting at school in the students’ lounge during a break and trying to catch the really choppy live stream from the meeting on my borrowed laptop (a futile exercise, I watched parts of the blurry recording later).

I was extremely passionate about getting software deployment to work better on Linux and to improve the overall user experience, and spent many hours on the PackageKit IRC channel discussing things with many amazing people like Richard Hughes, Daniel Nicoletti, Sebastian Heinlein and others.

At the time I was writing a software deployment tool called Listaller – this was before Linux containers were a thing, and building it was very tough due to technical and personal limitations (I had just learned C!). Then in university, when I intended to recreate this tool, but for real and better this time as a new project called Limba, I needed a way to provide metadata for it, and AppStream fit right in! Meanwhile, Richard Hughes was tackling the UI side of things while creating GNOME Software and needed a solution as well. So I implemented a prototype and together we pretty much reshaped the early specification from the original meeting into what would become modern AppStream.

Back then I saw AppStream as a necessary side-project for my actual project, and didn’t even consider me as the maintainer of it for quite a while (I hadn’t been at the meeting afterall). All those years ago I had no idea that ultimately I was developing AppStream not for Limba, but for a new thing that would show up later, with an even more modern design called Flatpak. I also had no idea how incredibly complex AppStream would become and how many features it would have and how much more maintenance work it would be – and also not how ubiquitous it would become.

The modern Linux desktop uses AppStream everywhere now, it is supported by all major distributions, used by Flatpak for metadata, used for firmware metadata via Richard’s fwupd/LVFS, runs on every Steam Deck, can be found in cars and possibly many places I do not know yet.

What is new in 1.0?

API breaks

The most important thing that’s new with the 1.0 release is a bunch of incompatible changes. For the shared libraries, all deprecated API elements have been removed and a bunch of other changes have been made to improve the overall API and especially make it more binding-friendly. That doesn’t mean that the API is completely new and nothing looks like before though, when possible the previous API design was kept and some changes that would have been too disruptive have not been made. Regardless of that, you will have to port your AppStream-using applications. For some larger ones I already submitted patches to build with both AppStream versions, the 0.16.x stable series as well as 1.0+.

For the XML specification, some older compatibility for XML that had no or very few users has been removed as well. This affects for example release elements that reference downloadable data without an artifact block, which has not been supported for a while. For all of these, I checked to remove only things that had close to no users and that were a significant maintenance burden. So as a rule of thumb: If your XML validated with no warnings with the 0.16.x branch of AppStream, it will still be 100% valid with the 1.0 release.

Another notable change is that the generated output of AppStream 1.0 will always be 1.0 compliant, you can not make it generate data for versions below that (this greatly reduced the maintenance cost of the project).

Developer element

For a long time, you could set the developer name using the top-level developer_name tag. With AppStream 1.0, this is changed a bit. There is now a developer tag with a name child (that can be translated unless the translate="no" attribute is set on it). This allows future extensibility, and also allows to set a machine-readable id attribute in the developer element. This permits software centers to group software by developer easier, without having to use heuristics. If we decide to extend the developer information per-app in future, this is also now possible. Do not worry though the developer_name tag is also still read, so there is no high pressure to update. The old 0.16.x stable series also has this feature backported, so it can be available everywhere. Check out the developer tag specification for more details.

Scale factor for screenshots

Screenshot images can now have a scale attribute, to indicate an (integer) scaling factor to apply. This feature was a breaking change and therefore we could not have it for the longest time, but it is now available. Please wait a bit for AppStream 1.0 to become deployed more widespread though, as using it with older AppStream versions may lead to issues in some cases. Check out the screenshots tag specification for more details.

Screenshot environments

It is now possible to indicate the environment a screenshot was recorded in (GNOME, GNOME Dark, KDE Plasma, Windows, etc.) via an environment attribute on the respective screenshot tag. This was also a breaking change, so use it carefully for now! If projects want to, they can use this feature to supply dedicated screenshots depending on the environment the application page is displayed in. Check out the screenshots tag specification for more details.

References tag

This is a feature more important for the scientific community and scientific applications. Using the references tag, you can associate the AppStream component with a DOI (Digital object identifier) or provide a link to a CFF file to provide citation information. It also allows to link to other scientific registries. Check out the references tag specification for more details.

Release tags

Releases can have tags now, just like components. This is generally not a feature that I expect to be used much, but in certain instances it can become useful with a cooperating software center, for example to tag certain releases as long-term supported versions.

Multi-platform support

Thanks to the interest and work of many volunteers, AppStream (mostly) runs on FreeBSD now, a NetBSD port exists, support for macOS was written and a Windows port is on its way! Thank you to everyone working on this

Better compatibility checks

For a long time I thought that the AppStream library should just be a thin layer above the XML and that software centers should just implement a lot of the actual logic. This has not been the case for a while, but there was still a lot of complex AppStream features that were hard for software centers to implement and where it makes sense to have one implementation that projects can just use.

The validation of component relations is one such thing. This was implemented in 0.16.x as well, but 1.0 vastly improves upon the compatibility checks, so you can now just run as_component_check_relations and retrieve a detailed list of whether the current component will run well on the system. Besides better API for software developers, the appstreamcli utility also has much improved support for relation checks, and I wrote about these changes in a previous post. Check it out!

With these changes, I hope this feature will be used much more, and beyond just drivers and firmware.

So much more!

The changelog for the 1.0 release is huge, and there are many papercuts resolved and changes made that I did not talk about here, like us using gi-docgen (instead of gtkdoc) now for nice API documentation, or the many improvements that went into better binding support, or better search, or just plain bugfixes.

Outlook

I expect the transition to 1.0 to take a bit of time. AppStream has not broken its API for many, many years (since 2016), so a bunch of places need to be touched even if the changes themselves are minor in many cases. In hindsight, I should have also released 1.0 much sooner and it should not have become such a mega-release, but that was mainly due to time constraints.

So, what’s in it for the future? Contrary to what I thought, AppStream does not really seem to be “done” and fetature complete at a point, there is always something to improve, and people come up with new usecases all the time. So, expect more of the same in future: Bugfixes, validator improvements, documentation improvements, better tools and the occasional new feature.

Onwards to 1.0.1!

Seems getting laid off was pretty good for me after all. Funny how things go sometimes.

A company that works on KDE stuff (and other Linuxy things), interviewed me for a fun job: "Wanna help us work on KDE Plasma?"

You bet I said YES!

So now I work daily 8 hours a day, 5 days a week, to improve KDE Plasma! It's contract work, but I hope people there like me a lot to keep me around. :) At least I am planning to be around for the long haul!

Anyway, this was my first week doing this job!

Everyone I work with is really nice and most of them I have already met during my contribution adventures.

The job itself for now has been about helping finding and fixing bugs in KDE Plasma. I've mostly concentrated on bugs that can appear when moving from 5 to 6, like migrating configs, etc.

There's some other stuff I'm doing as well, but they're not that visible to end user, necessarily. Like fixing warnings.

I am also focusing on learning the stack and hopefully eventually get to work more on Flatpak related things and Kwin related things, since those interest me. I am also hoping to help with accessibility, like high-contrast color schemes and such. And who knows what else I will work on in future!

Also due to my experience in test automation, I have taken on the sidequest to help with that part as well. I have been quite interested how test automation of Linux desktop apps works, and there's quite cool stuff going on there.

In my personal KDE plans, I want to add color customization options for separators, since those can be used in high contrast themes. But since it would be any custom color the user wants, well, they can set it to anything. Anyhow, I will first prioritize fixing bugs and learning more.

Thank you so much for the company who took me under their wing. And thanks to my colleagues for helping me get into this and teaching me things, even when my questions can be a bit dumb at times.. :'D You know who you are!

Expect more posts in future about what I learn during this job! :)

Thanks for reading!

The RiveQtQuickPlugin has now integrated the latest rivecpp version. We've implemented rendering support for rive text elements. We ensured seamless text rendering compatibility across both software and hardware-backed renderers. Explore our latest blog post for a demonstration video and to learn about more rendering enhancements.

Continue reading RiveQtQuickPlugin now with Text Support at basysKom GmbH.

What the Alpha means

The alpha release primarily focuses on preparing our software for a future release. It involves handling unreleased dependencies, version numbers, co-installation conflicts, and all the relevant bookkeeping work.

This release has been somewhat manic, with issues surfacing up to the last minute. However, that's precisely what this early release is for: resolving these issues now and gathering feedback on packaging to ensure a smoother transition to the beta phase.

Feature Freezes

The complete feature freeze for Plasma is scheduled for the day of the first beta, which is on November 29th. After that, bug fixing will be the sole focus for a period of three months leading up to the final release.

A soft freeze is set for the week before, on the 22nd, to accommodate any significant changes and ensure a seamless beta release.
This is mostly a case of doing a final round of landing straggling merge requests rather than developers starting anything new.

Should I run it?

Plasma 6 is in a pretty good state; I've been using it as a daily driver without issues for months

The alpha release does have known issues, some already fixed, but unreleased with the pending Qt 6.6.1, some our side fixed since alpha tagging, and some we need to follow up, particularly in the more esoteric areas of Plasma.
If you're the sort of user that wants to help out Plasma and are of a skill level where you're happy to log into another desktop session if things are temporarily down.

I would recommend as a user finding a distribution that covers 'git master' builds rather than any snapshot as it can provide a more dynamic list . A list can be found at https://community.kde.org/Plasma/Plasma_6#How_to_use/test_it

Pre-upgrade steps

Please take a backup of ~/.config/plasma* before upgrading. Just in case you need to file bug reports about config migration from 5.

Can I get involved?

Absolutely! It's an exciting time for Plasma and KDE in general. There are numerous tasks you can dive into. Check out our onboarding wiki here: https://community.kde.org/Get_Involved

qqc2-breeze5-style is a theme used by Plasma Mobile. This alpha release is a re-bundling of the Plasma/5.27 branch of qqc2-breeze-style. It is for use by distros shipping alpha releases of Plasma 6 so that Qt 5 apps continue to be themed appropriately.

URL: https://download.kde.org/unstable/qqc2-breeze5-style/

SHA256: 813f9da4861567e70d1eccf3a3a092d802ac9475a91070fb47fa
8766f3c1e310

Signed by E0A3EB202F8E57528E13E72FD7574483BB57B18D Jonathan Esk-Riddell <jr@jriddell.org>
https://jriddell.org/esk-riddell.gpg