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.

Work done so far

Move tracker for PvC game

Implemented the code for tracking the move played by player and computer in bohnenspiel TUI game.

It is achieved using getLastMove method initialized and defined in mankalaengine.h and mankalaengine.cpp. This method returns a pair containing the last moved as int played and the player as Player who made it.

During each iteration of the game loop, the above method is called for both player and computer to retrieve their respective last moves.

The above code in TUI file of bohnenspiel game variant is used to display the move played in the terminal.

The player move is tracked using user.getLastMove() and the computer move is tracked using opponent.getLastMove(). The game loop alternates between the player and the computer, updating the board and tracking moves after each turn. The last moves are printed after each turn. The computer’s move are adjusted by adding 6 to align it’s side of board(move 6-11).

How it works?

1. Player’s Turn:
   • The player select the hole to play.
   • The move is played, and the board is updated.
   • The move is tracked using user.getLastMove().
2. Computer’s Turn:
   • The computer select the hole to play.
   • The move is played, and the board is updated.
   • The move is tracked using opponent.getLastMove().

After each turn the last moves played are displayed.

What’s next

The next goal moving forward is to create a PvP game mode for two different users.

Model/View Drag and Drop in Qt - Part 3

Step 1

Step 2

Step 3

Step 4

class EmailsModel : public QAbstractTableModel
{
    ~~~
    Qt::ItemFlags flags(const QModelIndex &index) const override
    {
        if (!index.isValid())
            return {};
        return Qt::ItemIsEnabled | Qt::ItemIsSelectable | Qt::ItemIsDragEnabled;
    }

    // the default is "copy only", change it
    Qt::DropActions supportedDragActions() const override { return Qt::MoveAction | Qt::CopyAction; }

    QMimeData *mimeData(const QModelIndexList &indexes) const override;

    bool removeRows(int position, int rows, const QModelIndex &parent) override;

bool EmailsModel::removeRows(int position, int rows, const QModelIndex &parent)
{
    beginRemoveRows(parent, position, position + rows - 1);
    for (int row = 0; row < rows; ++row) {
        m_emailFolder->emails.removeAt(position);
    }
    endRemoveRows();
    return true;
}

class FoldersModel : public QAbstractTableModel
{
    ~~~    
    Qt::ItemFlags flags(const QModelIndex &index) const override
    {
        CHECK_flags(index);
        if (!index.isValid())
            return {}; // do not allow dropping between items
        if (index.column() > 0)
            return Qt::ItemIsEnabled | Qt::ItemIsSelectable; // don't drop on other columns
        return Qt::ItemIsEnabled | Qt::ItemIsSelectable | Qt::ItemIsDropEnabled;
    }

    // the default is "copy only", change it
    Qt::DropActions supportedDropActions() const override { return Qt::MoveAction | Qt::CopyAction; }
  
    QStringList mimeTypes() const override { return {QString::fromLatin1(s_emailsMimeType)}; }
  
    bool dropMimeData(const QMimeData *mimeData, Qt::DropAction action, int row, int column, const QModelIndex &parent) override;
};

bool FoldersModel::dropMimeData(const QMimeData *mimeData, Qt::DropAction action, int row, int column, const QModelIndex &parent)
{
    ~~~  // safety checks, see full example code

    EmailFolder *destFolder = folderForIndex(parent);

    const QByteArray encodedData = mimeData->data(s_emailsMimeType);
    QDataStream stream(encodedData);
    ~~~ // code to detect and reject dropping onto the folder currently holding those emails

    while (!stream.atEnd()) {
        QString email;
        stream >> email;
        destFolder->emails.append(email);
    }
    emit dataChanged(parent, parent); // update count

    return true; // let the view handle deletion on the source side by calling removeRows there
}

The post Model/View Drag and Drop in Qt - Part 3 appeared first on KDAB.

In Konsole Layout Automation (part 1), I wrote about how to automate opening Konsole with different tabs that ran different commands. In this post, I'll talk about doing this for layouts.

Inspiration

In the past, I needed to open two connections to the same host over ssh , and change to two different directories. I opened Konsole with a layout that had two panes. Then, Quick Commands allowed me to run a command in each pane to ssh and change to the right directory. This post will outline how to achieve that and more!

Goal: Launch a Konsole window with one tab that has multiple panes which run commands

💡 Note For more detailed instructions on using Konsole, please see the output of konsole --help and take a look at the Command-line Options section of the Konsole Handbook

A layout can save and load a set of panes. Unfortuately, it can't do anything else. We can, however, use profiles and the Quick Commands plugin to make the panes more useful.

Use case: See the output of different commands in the same window. For instance, you could be running htop in one pane and open your favorite editor in another.

Here's an overview of the steps:

• Set up a layout
• Use QuickCommands to run things in the panes

Set up a layout

Unfortunately, the online documentation for Konsole command line options doesn't say much about how to create a layout, or the format of its JSON file. It only mentions the command line flag --layout. Also make a note of -e which allows you to execute a command.

Fortunately, creating the layout is pretty easy. Note that a layout is limited to one tab. It will only save the window splits, nothing else. No profiles, directories, etc.

1. Set up a tab in Konsole with the splits you want it to have
2. Use View -> Save Tab Layout to save it to a .json file. (I personally recommend keeping these in a specific directory so they're easy to find later, and for scripting. I use ~/konsole-layouts).
3. You can then use konsole --layout ~/layout-name.json to load konsole with a tab that has the splits you saved.

Use Quick Commands to do useful things in your layout

As mentioned above, you can only save splits. you can't associate a profile, or run a command directly like you can with the tilix or kitty terminals. This has been requested. In the meantime, an easy thing you can do is load a layout and then load a profile manually in each pane. This is where Quick Commands come in. These are under Plugins - Quick Commands. (If you don't see this, contact your distro / the place you installed Konsole from).

You can use Quick Commands to run a command in each pane. You can also launch a profile (with different colors etc) that runs a command (part 1 showed how these might be used). Note, however, that running konsole itself from here will launch a new Konsole window.

End each command with || return so that you get to a prompt if the command fails.

Examples

htop || return

So, after you've launched Konsole with your layout as described above, you can do this: Go to Plugins -> Show Quick Commands Add commands you'd like to run in this session. Now, focus the pane and run a command.

Using these steps, I can run htop in one pane and nvtop in the other.

After you've gotten familiar with tabs and layouts, you can make a decently powerful Konsole session. Combine these with a shell function, and you can invoke that session very easily.

This is still too manual!

You're right. This post is about automating Konsole and having to click on things is not exactly that. You can use dbus commands in a script to load your tab layout and then run commands in each pane without using Quick Commands.

As we saw in the last post, you can use profiles to customize color schemes and launch commands. We can call those from a script in a layout. The demo scripts used below use dbus, take a look at the docs on scripting Konsole for details.

I'm using the layout file ~/konsole_layouts/monitoring.json for this example. This layout file represents two panes with one vertical split (horizontal orientation describes the panes being horizontally placed):

{
 "Orientation": "Horizontal",
 "Widgets": [
 {
 "SessionRestoreId": 0
 },
 {
 "SessionRestoreId": 0
 }
 ]
}

Here's an example of a simple script using that layout, which will launch fastfetch in one pane and btm in the other:

#!/usr/bin/env bash

# Define the commands to run
cmd1="fastfetch"
cmd2="btm"

# Opens a konsole tab with a saved layout
# Change the path to point to the layout file on your system
# KPID is used for renaming tabs

konsole --hold --layout $HOME/konsole_layouts/monitoring.json & KPID=$!

# Short sleep to let the tab creation complete
sleep 0.5

# Runs commands in Konsole panes
service="$(qdbus | grep -B1 konsole | grep -v -- -- | sort -t"." -k2 -n | tail -n 1)"

qdbus $service /Sessions/1 org.kde.konsole.Session.runCommand "${cmd1}"
qdbus $service /Sessions/2 org.kde.konsole.Session.runCommand "${cmd2}"

# Renames the tabs - optional
qdbus org.kde.konsole-$KPID /Sessions/1 setTitle 1 'System Info'
qdbus org.kde.konsole-$KPID /Sessions/2 setTitle 1 'System Monitor'

What it does:

• Loads a layout with 2 panes, horizontally arranged
• Runs clear and then fastfetch in the left pane; runs btm in the right pane

Wrap-up

That's how you can accomplish opening a number of panes in konsole which run different commands. Using this kind of shortcut at the start of every work / programming session saved a little time every day which adds up over time. The marketing peeps would call it "maximizing efficiencies" or something. I hope some folks find this useful, and come up with many creative ways of making konsole work harder for them.

Known issues and tips

• Running konsole from a Quick Command will open a new window, even if you want to just open a new tab.
• You may see this warning when using runCommand in your scripts. You can ignore it. I wasn't able to find documentation on what the concern is, exactly.

The D-Bus methods sendText/runCommand were just used. There are security concerns about allowing these methods to be public. If desired, these methods can be changed to internal use only by re-compiling Konsole. This warning will only show once for this Konsole instance.

Credits to inspirational sources

• Thanks to the Cool-Konsole-setup repo, where I found an example script for using commands in a layout via qdbus. Note: The scripts in that repo did not work as-is.
• This answer on Ask Ubuntu for improvements on the example scripts.

Hey everyone!!

Welcome to my blog post. I am Roopa Dharshini, a mentee in Season of KDE 2025 for the KEcoLab project. In this blog, I will explain my work in the SoK mentorship program.

Getting Started With SoK

For my proposal I crafted a detailed timeline for each week. With this detailed plan and with the help of my wonderful fellow contributors and mentors, I was able to complete all the work before the end of the mentorship program.

CC-BY-SA-4.0 license.)" src="https://eco.kde.org/blog/images/2025-03-31-roopa-sok25-proposal.png" style="max-width: 100%; height: auto" />

I started by first week working to understanding the project's codebase, studying KECoLab's handbook and existing documentation, setting up a GitLab wiki in the forked repository, and discussing the GitLab wiki's Merge Request (MR) feature. I explored and discussed various technical documentation tools with the mentors. Initially, we had planned to continue with GitLab, but later due to the flexibility of KDE's community wiki, we proceeded with that as our preferred documentation tool.

CC-BY-SA-4.0 license.)" src="https://eco.kde.org/blog/images/2025-03-31-roopa-sok25-usage-scenario.png" style="max-width: 100%; height: auto" />

I got to work creating an outline for the entire technical documentation. Usage scenarios scripts are essential for executing the automation pipeline in KEcolab. So, my fellow mentees and I started our documentation process with usage scenario scripting: we drafted a short page describing it's importance, provided some scripts, and detailed their structure. This documentation is structured in a way that even non-technical contributors are able to follow the guidelines and create their own scripts.

CC-BY-SA-4.0 license.)" src="https://eco.kde.org/blog/images/2025-03-31-roopa-sok25-ci-cd.png" style="max-width: 100%; height: auto" />

After this, I wrote various texts for the technical documentation (CI/CD pipeline, Home Page) of the KEcoLab project. There was a change in the audience for our documentation: initially we focused on the users of KEcoLab, but later we decided to write documentation for both the people who wish to contribute and provide new changes to KEcoLab as well as those who use KEcoLab for their software measurements. This change had us writing in-depth technical documentation for developers who wish to change the code for better efficiency. The CI/CD pipeline is essential for the energy measurement automation in KEcoLab. Writing detailed CI/CD pipeline documentation that explains its use, structure, and job execution was challenging, yet rewarding.

Final Documentation Links

1. User Guide documentation for KEcoLab Users
2. Usage Scenario Script documentation
3. Accessing result documentation for users
4. CI/CD pipeline documentation for contributors
5. Contribution guidelines

How did I apply to Season of KDE?

CC-BY-SA-4.0 license.)" src="https://eco.kde.org/blog/images/2025-03-24-roopa-sok25-proposal.png" style="max-width: 100%; height: auto" />

Season of KDE is a mentorship program that happens every year between January and March. It is a three-month mentorship where mentees will be guided through a project they propose. You start by writing a proposal and timeline to work on from the projects listed on the KDE Ideas page. You tag the mentors in the issue, and they will review your proposal and check whether you are suitable or not. You can checkout my proposal for the KEcoLab project. After review, mentors will hopefully mark your proposal as accepted. And that’s how I got into it!

Challenges I faced

Applying to SoK was not easy for me. I ran into my first challenge when I tried to create a new KDE Invent account. I thought there were some technical issues with the website, so I tried every day to create an account (you are limited to one account creation chance per 24-hour period). After a long wait, I reached out to SoK admin Johnny for help, and he assisted me in creating an account. I was really scared to submit my proposal because there was only one week before the submission deadline, but I trusted my skills and submitted it. So, keep in mind that “it is never too late to apply."

The second challenge was team collaboration. Similar to me, there were 2 other contributors selected for this project. I was brand new to KDE. At first it was hard to communicate with my other contributors, but later on we started to work really well together. Those are the main challenges I faced during my contributions to SoK. Challenges are never an end point; they are a stepping stone to move further.

Thank You Note!

Challenges make the journey worthwhile. Without any challenges, I wouldn’t have known the perks of contributing to KDE in SoK. I take a moment here to thank my wonderful mentors Kieryn, Aakarsh, Karanjot, and Joseph for guiding me throughout this journey. Also, I want to thank my fellow contributors to the project Shubhanshu and Utkarsh for collaborating with me to achieve what we proposed successfully. Finally, I am thankful to the KDE e.V. and the KDE community for supporting us new contributors to the amazing KDE project.

KEcoLab is hosted on Invent. Are you interested in contributing? You can join the Matrix channels Measurement Lab Development and KDE Eco and introduce yourself.

Thank you!

Introduction -

Over the last 10 weeks, I had the opportunity to contribute to MankalaEngine by exploring and integrating new algorithms for gameplay, as well as working on adding the Pallanguli variant to the engine. My journey involved researching about various algorithms like Monte Carlo Tree Search (MCTS), implementing Q-learning, an ML-based approach, and evaluating their performance against the existing algorithms of MankalaEngine. Also assisted in reviewing the implementation of the Pallanguli variant.

Implementing and Testing MCTS

I first explored Monte Carlo Tree Search (MCTS) and implemented it in MankalaEngine. To assess its effectiveness, I tested it against the existing algorithms, such as Minimax and MTDF, which operate at depth 7 before each move.

MCTS Performance Results -

The results was not good enough. This was expected because existing Minimax and MTDF algorithms are strong and operate at depth 7 before each move.

Moving to Machine Learning: Implementing Q-Learning.

Given MCTS's poor performance against strong agents, I explored Machine Learning (ML) techniques, specifically Q-Learning, a reinforcement learning algorithm. After learning its mechanics, I implemented and trained a Q-learning agent in MankalaEngine, testing it against existing algorithms.

Q-Learning Performance Results -

Q-learning showed significant improvement, defeating existing algorithms in most cases. However, it still had weaknesses.

Techniques Explored to Improve Q-Learning Results:

To improve performance, I experimented with the following techniques:

• Using Epsilon decay to balance exploration (random moves) and exploitation (using learned strategies).

• Increased rewards for wins to reinforce successful strategies.

• Training Q-learning against Minimax and MTDF rather than only against itself.

Despite these improvements, Q-learning still could not consistently outperform all existing algorithms.

After these experiments and research, I believe more advanced algorithms like DQN or Double DQN are needed to outperform all existing algorithms. This would also an exciting project for this summer.

Work related to Integration of Pallanguli Variant

Apart from exploring ML algorithms, I also worked on integrating the Pallanguli variant of the Mancala game into MankalaEngine. My contributions included:

• Reviewing Srisharan’s code, suggesting fixes and discussions.

• Creating Merge Request (MR) that allows users to input custom initial counters for Pallanguli.

Conclusion -

This journey has been an incredible learning experience, and I am grateful for the guidance of my mentors, Benson Muite and João Gouveia, who were always there to help.

I look forward to continuing my contributions to the KDE Community, as I truly love the work being done here.

Thank you to the KDE Community for this amazing opportunity!