Haruna version 1.4.0 is released.

Added support for recursive subtitle search, rotating video and opening youtube playlists from a video url containing a playlist id https://www.youtube.com/watch?v=video_id&list=playlist_id

Fixed issues with tracks menus showing incorrect tracks and changed the behavior of progress/seek slider while pressed to pause the video.

Windows version:

• haruna-1.4.0-windows-gcc-x86_64.exe
• haruna-1.4.0-windows-gcc-x86_64.7z

Availability of other package formats depends on your distro and the people who package Haruna.

If you like Haruna then support its development: GitHub Sponsors | Liberapay | PayPal

Feature requests and bugs should be posted on bugs.kde.org, ignoring the bug report template can result in your report being ignored.

Changelog

1.4.0

Features

• Added setting to search subtitles recursively. Searches folders relative to the parent folder of the playing file and folders defined by the `Load subtitles from` setting
• Added support for opening youtube playlists from urls containing a playlist id
• Added actions to rotate video clockwise (ctrl + r) and counter clockwise (ctrl + e)

Bugfixes

• Fix tracks menus showing tracks from previously opened files
• Fix subtitles added by drag and drop not being added to the subtitles menu
• While the progress/seek slider is pressed the video is paused, fixes continuously opening the next video when dragged and held all the why to the end

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, Looking ahead at 2025 and Fedora Workstation and jobs on offer! and Fedora Workstation 42 is upon us! 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

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.

Work done so far

Implemented the PvP mode by leveraging XMPP for communication, enabling the played to exchange moves. The code for this are implementd in connection.h, connection.cpp and bohnenspieltui.cpp.

Setting up the PvP mode

The player select the game mode they desires to play, for PvP the choice would be option P.

Connecting to XMPP server

To establish the chat room and enable the communication the player must provide their jabber id and password and the opponent’s JID (This should be done from both players side).

The program then establishes a connection to the XMPP server using the entered credentials. The game proceeds only when the credentials are verified.

Host and Turn Order

The program determines who will play first in a simple manner i.e., by comparing the lexicographical order of their jabber IDs.

Sending a move

When it’s player turn, they are prompted to enter their move. The move is validated and sent to opponent via the established chat room.

The board is updated locally and then the turn is passed to the opponent.

Receiving a move

When the move is received from the opponent, the program prompts the player to sync the board manually.

This is to ensure that both the players have their board in sync. Then the program prompts the user to enter their move and it game will be continued.

What’s next

• Automatic move sync
• The man page to explain the working to players.

Some time ago we reached out to Wesley Gardner because, a bit belatedly, we saw he has published a great book on Krita, titled Draw and Paint Better with Krita.

For krita.org, Wesley wrote an introduction to his book!

Teaching art has been a passion of mine for a long time, and seeing students find their “inner voice” and push through barriers they thought insurmountable is one of the coolest things in the world. In 2021, I was approached to write a “how to digital paint” book, geared towards beginners to digital art, but with the goal of also having enough weight to give intermediate and advanced digital artists some fun exercises as well. Without second thought, I agreed, and knew that Krita would be the focal point of the book. Thus, in 2022, ‘Draw and Paint Better with Krita’ was published worldwide, and has become a sort of “guardian angel” guide for artists around the world, which I’m super humbled by and grateful for.

:

Krita’s everything that I believe digital art is about: Open access, customizable to fit your needs, easy to get started, and impossible to master. There’s always something new to learn in art, and likewise, there’s always something fun to learn in Krita. Whether it’s the various effects you can get with the ever-expanding layer management and adjustments, or the near-infinite pool of incredible custom brushes made by the community, there’s ALWAYS a new way to push yourself to that next level in your journey.

I’ve been a Krita user since Krita 3, and seeing how much it has evolved and expanded in the past few years has been unbelievable! It’s always installed on EVERY machine that I make art on, and is one of my “must-download” softwares the moment I get a new machine. It’s one of those programs that grows with you, and can handle absolutely anything you can throw at it. I’ve produced personal work and art prints, as well as professional client work for the likes of Star Wars, Warhammer 40k, and Riot Games, and the program never breaks a sweat. When I’m stumped on what type of video to make for my YouTube channel, I can always fall back on playing around in Krita, as it’s always a treat to poke around and learn new workflows.

Writing the book on Krita was a no-brainer, as I think learning Krita can help you learn ANY digital painting software, as the workflows are so similar. It’s the perfect entry-point for every artist that wants to work digitally, and it’s the perfect ending point for tenured veterans that need a little bit of “extra spice” to finish off their work and build their brand. If there’s one digital art program every single person needs on their machine, it’s Krita.

For real, what CAN’T Krita do? Go join the forums, be part of the community, and (if you’re financially able to, of course) donate somewhat regularly to the Krita Foundation. They do incredible work, and the fact that Krita’s available on Windows, Mac, AND Linux, for FREE, is still some sort of wizardry I can’t wrap my head around. For the Krita Team: Keep knocking it out of the park, it’s an honor to be a part of the Krita legacy, and for the team, and all artists out there:

Go make cool art.