In first of a kind movement to develop free and open source fonts for traditional Malayalam scripts, the Rachana Institute of Technology, KaChaTaThaPa Foundation and Sayahna Foundation had previously announced font design competition in May 2024.

Many participants registered from all over India and shared their initial design of a few selected characters. Ten submissions were shortlisted, and the selected participants were invited for a two-day in person workshop conducted at River Valley campus, Trivandrum. The workshop was lead by the jury members — Dr. KH Hussain who designed notably Rachana and Meera fonts (among many other); eminent calligrapher and designer of Sundar, Ezhuthu, Karuna & Chingam fonts, Narayana Bhattathiri; type designer and multi-scripts expert Vaishnavi Murthy; and yours truly. High quality sessions & feedback from the speakers and lively interactive sessions enlightened both experienced and non-technical designers about the intricacies of typeface design.

Refinement

To manage the glyph submissions for collaborative font projects, a friend of mine and I built a web service. The designers just need to create each character in SVG format and upload into their font project. This helped to abstract away from the designers all the technical complexities, such as assigning correct Unicode codepoint, correct naming convention, OpenType layout & shaping etc.

There was mid-term evaluation of the completed glyph set in October 2024; and a couple of online sessions where the jury pointed out necessary corrections and improvements required for each font.

The final submissions were done near the end of December 2024; and further refinements ensued. All the participants were very receptive to the constructive feedback and enthusiastic to improve the fonts. The technical work for final font production was handled by your humble correspondent.

Results

In March 2024, the jury made a final evaluation and adjudged the winners of the competition. All the six fonts completed are published as open source, and they can be downloaded from Rachana website. See the report for the winning entries, font specimens & posters, prize money, and all other details.

RIT Thaara (താര), calligraphic style, named after Sabdatharavali.

RIT Lekha (ലേഖ), body text font.

RIT Lasya (ലാസ്യ). The Latin glyphs were drawn independently based on Akaya Kannada font, as suggested by a jury member.

RIT Ala (അല).

RIT Keram Bold (കേരം).

RIT Indira Bold (ഇന്ദിര).

I am very happy to have the chance to collaborate over the course of a year with designers from various backgrounds to develop beautiful traditional Malayalam orthography fonts and make them all available under free license. I would like to thank the jury members who did exemplary work in evaluating the designs and providing constructive feedback & guidance multiple times that helped to refine the fonts; CVR for the work to create web pages on Rachana website; and the three Foundations for the initiative and funding to make this all possible. Full disclosure: all the jury members worked in volunteer capacity.

Next competition

RIT-KaChaTaThaPa-Sayahna foundations have already announced plans for next open font design competition! This time the focus is on body text fonts.

• Competition details in English (or https://rachana.org.in/fcomp-2026-ann.html)
• Competition details in Malayalam
• Register here.

We’re excited to announce a major step forward for QML development workflows with the upcoming 1.5.0 pre-release of Qt Qml Extension for Visual Studio Code. As part of this release, we’ve introduced initial support for QML debugging in VS Code – a feature that brings long-requested functionality closer to everyday usage for QML developers using lightweight and cross-platform tooling.

With the 0.9 release, you can unshackle yourself from cloud LLM providers, at least for code completion. We support CodeLlama-7B-QML and DeepSeekCoder v2 Lite now. You can run them with Ollama, the LLM self-hosting technology, on your computer with a few clicks and a single CLI command.

Fedora 42 has been released! 🎉 So let’s see what is included in this new release for the Fedora Atomic Desktops variants (Silverblue, Kinoite, Sway Atomic, Budgie Atomic and COSMIC Atomic).

Note: You can also read this post on the Fedora Magazine.

New COSMIC Atomic variant

The new COSMIC desktop has been packaged for Fedora and a new Atomic variant created for it thanks to Ryan Brue. It is not yet available on the website but should be soon. See fedora-websites#351. Edit: It is now live: Fedora COSMIC Atomic.

See the Fedora change request.

Changes for all variants

composefs enabled by default

Following Fedora CoreOS in Fedora 41, Fedora Atomic Desktops are now using composefs by default. This is an important first step towards better integrity for the system content.

Note: As a side effect of this change, the systemd-remount-fs.service unit may fail to start on your system. Until we find a good way to fix this, you can find a workaround to apply in the atomic-desktops-sig#72 issue or in the common issue thread on the forum.

See the Fedora change request and the tracking issue atomic-desktops-sig#35.

Migration to a static GRUB config

As part of the move to composefs, we had to migrate systems to using a static GRUB config.

This also removes the duplicated entries in the boot menu for installations that pre-dates Fedora 41.

The transition will happen automatically during the first boot on Fedora 42. You can verify that it worked by looking at the status of the bootloader-update service:

$ sudo systemctl status bootloader-update.service

We are still missing documentation on how to change some GRUB settings now that the configuration is static. See the tracking issue atomic-desktops-sig#73.

Custom keyboard layout set on installation (for LUKS unlock)

This fix is important for setups where the root disk is encrypted with LUKS and the user is asked a passphrase on boot. The keyboard layout is now set as a kernel argument during the installation by Anaconda. If you want to later change the keyboard layout used for the LUKS password prompt, you will have to update the kernel argument.

Example to set the keyboard layout to the french keyboard:

$ sudo rpm-ostree kargs --append=vconsole.keymap=fr

Example to replace an existing layout by another:

$ sudo rpm-ostree kargs --replace=vconsole.keymap=de

See atomic-desktops-sig#6.

No longer building for PPC64LE

According to the countme statistics, we did not have users on PPC64LE, so we decided to stop building the Fedora Atomic Desktops for that architecture.

If you relied on those images, you can migrate to Fedora Bootc images (which are available for PPC64LE) or use a conventionnal Fedora package based installation.

See the Fedora change request.

What’s new in Silverblue

GNOME 48

Fedora Silverblue comes with the latest GNOME 48 release.

For more details about the changes that alongside GNOME 48, see What’s new in Fedora Workstation 42 on the Fedora Magazine and Looking ahead at 2025 and Fedora Workstation and jobs on offer! from Christian F.K. Schaller.

What’s new in Kinoite

KDE Plasma 6.3

Fedora Kinoite ships with Plasma 6.3, Frameworks 6.11 and Gear 24.12.

See also What’s New in Fedora KDE Plasma Desktop 42? on the Fedora Magazine.

What’s new in Sway Atomic

Nothing specific this release.

What’s new in Budgie Atomic

The default software center for Budgie Atomic is now Plasma Discover. To rebase from Fedora 41 to 42, you will have to use the command line as rebasing via GNOME Software will move your system to Fedora Silverblue.

See: fedora-budgie/project/issue/5.

Changes in unofficial images

Until we complete the work needed in the Fedora infrastructure to build and push official container images for the Atomic Desktops (see releng#12142 and cloud-image-uploader#37), I am providing unofficial builds of those. They are built on GitLab.com CI runners, use the official Fedora packages and the same sources as the official images.

You can find the configuration and list on gitlab.com/fedora/ostree/ci-test and the container images at quay.io/organization/fedora-ostree-desktops.

Container images signed with cosign (sigstore)

The unofficial container images are now signed with cosign. You can configure your system to verify the signature of the images using the instructions from the project README.

Container images available for aarch64

We are now building all our variants for the aarch64 architecture as well.

Goodbye to Sericea and Onyx (now Sway Atomic & Budgie Atomic)

We have now removed all container images under that name. Use the new names:

• Sericea: sway-atomic
• Onyx: budgie-atomic

Unofficial, experimental Fedora Asahi Remix Atomic Desktops

We are now producing unofficial, experimental bootable container images targeting Apple Silicon, using the packages from the Fedora Asahi Remix project.

Those images are in a working state, but the installation procedure is not ready for general use. We thus only recommend that you give this a try if you are ready to help with the development or are ready to re-install you system and lose data.

See: fedora-asahi-remix-atomic-desktops project on GitHub

See also the Fedora Asahi Remix 42 is now available posts on the Fedora Magazine.

Note that those images currently do not support the x86 emulation detailed in New in Fedora: Running x86 programs on ARM systems.

Universal Blue, Bluefin, Bazzite and Aurora

Our friends in the Universal Blue project (Bazzite, Bluefin, Aurora) have prepared the update to Fedora 42. Look for upcoming announcements in their Discourse.

I heavily recommend checking them out, especially if you feel like some things are missing from the Fedora Atomic Desktops and you depend on them (NVIDIA proprietary drivers, extra media codec, out of tree kernel drivers, etc.).

What’s next

Roadmap to Bootable Containers

The next major evolution for the Atomic Desktops will be to transition to Bootable Containers. See also the Fedora bootc documentation.

We have established a roadmap (atomic-desktops-sig#26) and we need your help to make this a smooth transition for all of our existing users.

Turning the sysext experiment into a good experience

Systemd system extensions (sysexts) are a new option when you need some applications available on your system and can not run them in containers or as Flatpaks for various reasons. They offer an alternative approach to package layering as they do not increase update time and can be enabled or disabled as needed.

Support for sysexts is still in development for the Atomic Desktops but they already provide advantages over package layering for some use cases. See the currently experimental project: github.com/travier/fedora-sysexts.

Unifying the Atomic Desktops documentation

We would like to unify the documentation for the Fedora Atomic Desktops into a single one instead of having per desktop environments docs which are mostly duplicate of one another and need to be constantly synced.

See the tracking issue atomic-desktops-sig#10 if you want to help us do that.

Where to reach us

We are looking for contributors to help us make the Fedora Atomic Desktops the best experience for Fedora users.

• Atomic Desktops SIG: Issue tracker (gitlab.com/fedora/ostree/sig), #atomic-desktops:fedoraproject.org
• Silverblue: Workstation Working Group, #silverblue:fedoraproject.org
• Kinoite: KDE SIG, #kinoite:fedoraproject.org
• Sway Atomic: Sway SIG, #sway:fedoraproject.org
• Budgie Atomic: Budgie SIG, #budgie:fedoraproject.org
• COSMIC Atomic: COSMIC SIG, #cosmic:fedoraproject.org

We're happy to announce the release of version 1.4.0 of the Qt Extension for Visual Studio Code! This release cooked for a bit as pre-release 1.3.0 on the marketplace and has now been promoted to a proper release. Take a look at what's new in this release.

Historically passwords and credentials in all of our apps and services (such as kio and our Network Manager plasmoid), are stored and managed by our KWallet subsystem and API. In a similar way, GNOME had gnome-keyring, and other similar systems were available. A major problem was the mutually incompatible interface between them, making impossible to have a single place where all the passwords go.

For this reason, a standard DBus interface called Secret Service has been developed, and systems like KWallet, gnome-keyring and KeepassXC have adopted the interface as well.

In the future, we want to eventually port our applications to use the Secret Service API directly, preferably via the QtKeychain library (some applications already do), which will use Secret Service natively on Linux. And as a bonus the Windows/Android native systems on those platforms will work too.

This will make our applications work much better, be more integrated in other desktops or platforms, and be less dependent on the KWallet framework which has big legacy code parts at this point.

Right now, KWallet has the option to bring up a Secret Service compatible interface, and this is a valuable first step, but there are still some potential problems in the migration path:

• Applications using Secret Service will store their secret data in different places when running in different environment, including our own that have been migrated. If you login into a different session ,every app will have forgotten its credentials.
• It’s possible to use a different Secret Service provider also in a Plasma session, for instance enabling it in KeepassXC. At that point some apps will save into it, while other ones will keep using KWallet with a different storage backend.
• Applications ported from KWallet to SecretService will lose their credentials, unless some clunky porting code is written for each application.

A KWallet compatibility layer

Enter the recent refactor that happened in KWallet: it has now been split into 2 different system services now: one that exposes only the Secret Service API, and one that exposes only the KWallet API.

The service exposing the KWallet API has been written from scratch and is now just a thin wrapper around the Secret Service API, translating the KWallet DBus calls to Secret Service ones. The old KWallet service is now a pure Secret Service provider that just happens to use the old KWallet backend, exposing to Secret Service all the entries that had already been stored in the past.

This decouples our KWallet compatibility layer for existing or old applications (not only KDE applications, also third party ones like Chromium use it) with our actual secret storage and SecretService implementation, allowing a separate development roadmap, and even potential future transition to a different backend in a completely transparent way to the user.

You can see this decoupling in the same spirit as the recent KWin Wayland/X11 split: being able to develop the new technology without risking breaking compatibility of the legacy system.

What it means for users and developers

For the immediate future, not much really changes: users will still have all their secrets accessible, and every app they use that was using KWallet will keep working without forgetting anything.

In the same way, for developers, the whole KWallet C++ API keeps working exactly as it was (even though we’re discouraging its use in new projects). Also, the KWallet-to-Secret-Service API proxy layer will save data inside Secret Service with the same schema used by QtKeychain, keeping the data accessible if the application gets ported from using the KWallet C++ API to QtKeychain.

An experimental feature

Disclaimer: The following description is of an experimental feature behind a hidden configuration key: it will take a bit before it’s deemed ready for prime time.

One advantage of having 2 independent services to handle the KWallet API and the Secret Service one is that now it’s possible to chose different backends as well, such as KeepassXC, gnome-keyring or oo7.

Setting the following in kwalletrc:

[Migration]
MigrateTo3rdParty=true
[KSecretD]
Enabled=false

With this, the old KWallet backend (now a service called ksecretd) won’t be started anymore, and instead any Secret Service provider that is running or has been configured to be DBus-activatable will be used. The first time this happens, a data migration procedure will be executed, writing the data in KWallet into the new service, keeping all the user-saved secrets accessible.

Welcome to a new issue of "This Week in KDE Apps"! Every week we cover as much as possible of what's happening in the world of KDE apps.

As Carl is still in vacation, this issue is only partially complete.

System Apps

Dolphin Manage your files

The Dolphin search integration has been rewritten from scratch. Notably, users can now switch the search tool between a simple search algorithm and one using file indexing and offering advanced search options. This way users are no longer forced to use the file index whenever it is available and can instead search in a slower but more reliable manner.

The overall user interface design is much improved with better clarity about what is currently being searched and which parameters can be changed. It was designed in a collaborative effort by Kristen McWilliam, Jin Liu, Andy Betts, Tagwerk, Felix Ernst, and a few others. (Felix Ernst, 25.08.0. Link)

The "Show in Groups" action was moved from the "View" menu to the "Sort By" menu. (Nate Graham, 25.08.0. Link)

The "Change View Mode" button which was recently added to Dolphin's default tool bar configuration is now icon-only by default (just like we had intended). (Akseli Lahtinen, 25.08.0. Link)

In the Trash context menu the "Properties" action is now once again in the last position just like in all the other Dolphin view context menus. This now-fixed inconsistency was an unintended side-effect of us moving the "Delete" action last to make it less likely to click it by accident when aiming at "Restore". (Kai Uwe Broulik, 25.08.0. Link)

Dolphin will now hide the background of the navigation bar when it's outside of the toolbar. (Akseli Lahtinen, 25.08.0. Link)

Other

Various improvements were made for the KDE Open and Save dialog:

• People using single-click selection can now click on checkboxes to select individual items in multi-selection dialogs. This works similarly to how it does in Dolphin. (Akseli Lahtinen, KIO 6.14. Link)
• Open and Save dialogs now allow quickly filtering through files by filename when pressing CTRL+I or Backslash key, like in Dolphin. (Akseli Lahtinen, KIO 6.14. Link)

…And Everything Else

This blog only covers the tip of the iceberg! If you’re hungry for more, check out Nate's blog about Plasma and be sure not to miss his This Week in Plasma series, where every Saturday he covers all the work being put into KDE's Plasma desktop environment.

For a complete overview of what's going on, visit KDE's Planet, where you can find all KDE news unfiltered directly from our contributors.

Get Involved

The KDE organization has become important in the world, and your time and contributions have helped us get there. As we grow, we're going to need your support for KDE to become sustainable.

You can help KDE by becoming an active community member and getting involved. Each contributor makes a huge difference in KDE — you are not a number or a cog in a machine! You don’t have to be a programmer either. There are many things you can do: you can help hunt and confirm bugs, even maybe solve them; contribute designs for wallpapers, web pages, icons and app interfaces; translate messages and menu items into your own language; promote KDE in your local community; and a ton more things.

You can also help us by donating. Any monetary contribution, however small, will help us cover operational costs, salaries, travel expenses for contributors and in general just keep KDE bringing Free Software to the world.

To get your application mentioned here, please ping us in invent or in Matrix.

Finishing Up

Hey everyone, It’s me again, back with the final update for this year’s Season of KDE. So, turns out things don’t really go as planned and it took me some extra time to bring it over the line.

Since my last post, I wrote the tests for the Kalah game, the associated TUI, a greedy move selection and benchmarked Oware and Bohnenspiel. My mid-sem exams happened, in between, and delayed me by 2 weeks.

Dear fans of music & open source music players,
in preparation of the upcoming Amarok 3.3 release, a beta release (3.2.81) has been prepared.

As shown in the ChangeLog, the changes are mostly technical: Qt5 support is removed, and Amarok 3.3 beta is compatible with Qt6/KF6 only. Additionally, a database scheme update (first such since 2012) fixes encoding and date related bugs.

Please note that due to the database update, downgrading from 3.3 beta is not directly possible, and returning to pre-3.3 versions requires the database (at ~/.local/share/amarok/mysqle/) to be manually backed up beforehand.

Aligning with current major KDE Frameworks version should simplify various direct and indirect software dependencies. However, phonon-vlc is the only supported backend on Qt6 Phonon, which Amarok 3.3 beta is still using for audio playback. This imposes some constraints e.g. on equalizer and analyzer functionalities. A more comprehensive overview of audio backend status is available on an invent.kde.org issue and a related work-in-progress merge request.

Additionally, there isn't official releases with Qt6 support of liblastfm available yet (needed for last.fm support). To enable the functionality, one needs to use library version built from e.g. sources at https://github.com/Mazhoon/liblastfm/tree/81e8f9dc16a0a18fe9a066d51c2071086326670b .

The Amarok 3.3 beta source tarball is available on download.kde.org and it has been signed with Tuomas Nurmi's GPG key. In addition to the source code, it is likely that some distributions will provide beta packages. The various nightly git builds provided by various splendid packagers should also provide a way of using the beta changes and participating in the testing.

Happy listening!

Final update

So this is my final blog regarding the Season of KDE 2025, I’m feeling happy for what I accomplished. Over the past few weeks, I’ve implemented PvP system for mancala game, this project has been a deep dive into game development, networking and user experience.

Summary of work done so far

1. Move tracking Mechanics

At the heart of this project lies the MankalaEngine, an engine designed to handle rules and gameplay of various mancala variants. I’ve added some more feature in the engine:

• Move tracking: The lastMoveMethod() method allows to retrieve the last move played by the player and computer.

2. PvP Mode

It allows the real-time multiplayer gameplay using XMPP. Following is a brief summary:

• XMPP Integration: Players connect to each other using their jabber IDs and exchange move using the established chat room in real-time.
• Turn Management: The Player 1 always start, and turns alternate between the two players.
• Board Syncing: Players manually update their boards based on the opponent’s move, ensuring both the players have accurate view of the game state.

3. Man Page Documentation

To make the game accesible, I’ve created a man page for bohnenspieltui. This man page provides the information abou the game, including:

• Synopsis and Description: A brief overview and explanation of the game variant.
• Usage: Instructions for running the PvP mode.
• Added a minor improvement of card view in Mancala GUI.

Future Work

While the task for this term is completed, their are several areas for improvement:

• Automated board syncing by replacing the current manual one.
• Integrating the engine to the mancala GUI.
• Extending the PvP to other variants.

Final Words

Thanks to KDE community, XMPP community and Benson Muite and João Gouveia and Blue from Macaw.me for the guidance and support. And I encourage the aspiring contributors to take part in Season of KDE to learn and grow as a developer.