Project Description

In SoK 2025, I will be working on adding Pallanguzhi, a traditional Indian Mancala variant, into the Mankala Engine. Collaborating with Srisharan V S, my focus includes two key goals:

1. Developing a computerized opponent to enhance player engagement and ensure a seamless gameplay experience.
2. Creating a Text-Based User Interface (TUI) for gameplay.

What I Did This Week

The first step in my journey was setting up the Mankala Engine repository. I forked the repository to my local system, successfully built it, and resolved some warnings during the build process. Afterward, I delved into the codebase, analyzing the existing algorithms and understanding how they work for other Mancala variants.

Research on Implementing a Computerized Opponent

To create a robust computerized opponent for Pallanguzhi, I began researching potential algorithms that could best fit the game mechanics. Here are the three techniques I explored.

1. Reinforcement Learning

Reinforcement Learning (RL) is an exciting approach where an agent learns optimal strategies by interacting with the environment and improving over time. For Pallanguzhi, RL could enable the computerized opponent to adapt and improve its gameplay dynamically. However, as I am new to RL, implementing and training models for this variant will take some time and effort. Despite its challenges, RL remains a promising option for advanced gameplay enhancement.

2. Monte Carlo Tree Search (MCTS)

MCTS is a powerful algorithm widely used for decision-making in games. It works by simulating potential moves to build a decision tree and then selecting the best move based on statistical evaluation. For Pallanguzhi, MCTS could efficiently explore the vast game state space and make informed decisions. By carefully tuning the number of simulations and exploration parameters, this algorithm can provide a balanced and competitive computerized opponent.

3. Alpha-Beta Pruning with Iterative Deepening

Alpha-Beta Pruning with Iterative Deepening is a highly effective technique for optimizing decision trees by eliminating unnecessary branches. This method is already implemented in the Mancala Engine for other variants and has proven its efficiency. Leveraging this existing implementation for Pallanguzhi will allow us to quickly develop a working version of the game with a competent computerized opponent.

Conclusion for Now

The immediate plan is to integrate the Pallanguzhi variant into the existing Alpha-Beta Pruning implementation. This ensures we have a functional version of the game ready for any further work. Once the TUI implementation is complete, I plan to revisit Reinforcement Learning for Pallanguzhi. Working with RL models and training them is a learning-intensive process, and I am excited to gain experience in this area. Even if RL proves too challenging, we will still have a polished Pallanguzhi variant running on the existing algorithm.

What’s Next

Next week, I will work on adding the longer version of Pallanguzhi, which consists of multiple rounds, while Srisharan V S focuses on completing the shorter version. Together, we aim to make significant progress toward integrating and refining this traditional game within the Mankala Engine.

Stay tuned for updates!

Grab your favorite drink and join us for the first Kdenlive Café of the year! Come hangout with the developer team, share your ideas and feedback, get some scoops on what’s brewing for future releases and connect with fellow editors. Join the community!

📅 Tuesday, January 28th, at 8 PM (UTC)

🌐 https://meet.kde.org/b/far-twm-ebr

What I am working on?

My project focuses on enhancing the GUI and adding Player vs. Player (PvP) multiplayer functionality to a Mancala game.

Mancala is a popular board game played worldwide. The proposed plan is to use Kirigami for improving the GUI and making the application cross-platform. Multiplayer functionality will be integrated using XMPP. The game will operate over a communication channel established by XMPP over UDP. The updated game board will be reflected graphically using data binding. The XMPP server being used is Prosody.

Work done so far

Setting up the prosody locally

Setting up Prosody is fairly straightforward. I installed it from Fedora’s official repository using the command:

sudo dnf install prosody

Alternatively, Prosody can be built and installed from its source code available on GitHub.

Configuring prosody

Prosody’s configuration is contained in a single file: prosody.cfg.lua. On Linux distributions, this file is typically located at /etc/prosody/prosody.cfg.lua..

For now the clients are connected over same LAN using the virtual host @mancala.local as the domain id.

The image above illustrates how to edit your virtual host configuration.

The next step is to configure a chat room, which is done similarly to the virtual host configuration.

Both configurations require an SSL certificate to secure the communication channel.

After completing these steps, we restart and check the status of Prosody using the following commands:

sudo systemctl restart prosody
sudo systemctl status prosody

If everything is configured correctly, the state will be “active.” You can verify this by checking the log file using: sudo tail -f /var/log/prosody/prosody.log we can check the log file. If configured successfully, the output will resemble this:

Adding users and communicating via a XMPP client

The plan is to allow users to either use their existing Jabber ID or create a new one through our server. For testing purposes, I manually added users to the server using the following command:

sudo prosodyctl adduser <username@domain_name>

After executing the command, you will be prompted to set a password for the user.

For communication, I used the Pidgin client.

As shown in the image above, I have added two users, user11 and user12.

To test communication, I sent a message from user11 to user12 by addressing it to user12@mancala.local. Below are the results:

Since I used the Pidgin client on the same device, both user tabs appear in the interface. The screenshots confirm that I successfully established a user-to-user communication channel over LAN.

What’s next

For the next week, I plan to:

• Implement in-band registration.
• Enable communication over the internet.
• Develop the logic for the game invitation system.

Qt in 2024
2024 was another outstanding year for Qt, filled with exciting milestones and achievements! Highlights of the year include the Qt 6.7 and Qt 6.8 releases, Qt Creator 15 release, and the Qt Contributor Summit.

Ruqola 2.4.1 is a feature and bugfix release of the Rocket.chat messenger app.

Ruqola 2.4.1

• Fix typing support (new API)
• Exclude string starting with /* or // as Rocket chat command (avoid error)
• Don't copy text when preview is hidden
• Fix Market apps support
• Fix search user (Allow to use '@') when inviting users in Room
• Inform when we don't have database history for a specific Room
• Fix clicking in url in text in preview url
• Don't allow to create two tokens with same name
• Don't show clear button in lineedit when it's readonly

URL: https://download.kde.org/stable/ruqola/
Source: ruqola-2.4.1.tar.xz
SHA256: e5adb0806e12b4ce44b55434256139656546db9f5b8d78ccafae07db0ce70570
Signed by: E0A3EB202F8E57528E13E72FD7574483BB57B18D Jonathan Riddell jr@jriddell.org
https://jriddell.org/jriddell.pgp

Some of you might have noticed. Updates to Manjaro ARM packages are far between these days. Actually it has been far between updates since I left the project in March 2023.

So this begs the question: Is Manjaro ARM dead?

Lets take a look at the current status.

No new images

The last round of release images for all the major platforms Manjaro ARM supports was done in February 2023, release version 23.02. And I have heard that most of them break the installation after the first update.

The only images I have seen that has had any kind of new release since I left, are the Pinephone based ones. But they are still considered Beta (after 4 years!).

ARM download are no longer prominent on the website

Manjaro.org got a new fancy website a little while ago. This website hides the ARM images, so you have to really look for them to find them. Here's how you find them on the new website:

manjaro.org -> Download button -> Go back a step in the submenu that says Products > Download > x86 by pressing the Download entry -> Press the Download button in the second section called For Phones And Embedded.

Now you can see and download the ARM images.

Very few package updates

The Raspberry Pi specific packages have been updates steadily by Ray Sherman, the maintainer. But all the other Manjaro specific packages are only updated rarely or not at all.

Even the package updates from Arch Linux ARM is not done very often anymore. So the package repository in general is in a very bad out-of-date state.

Is it maintained?

With all these points, I would conclude that it is not really maintained anymore. Ray asked the Manjaro project management about this and was told that the ARM branch no longer has a manager and therefore it was no longer a priority by the Manjaro team.

To me, that sounds like it has died a slow and quiet death.

I would not recommend Manjaro ARM to anyone anymore, because of the state it is in. It's a sad conclusion, as I started the project with Josh Crowder back in 2016 and we loved working on it.

One of my leisure time activities is to develop KMyMoney, a personal finance management application. Most of my time is spent on development, testing, bug reproduction and fixing, user support and sometimes I even write some documentation for this application. And of course, I use it myself on a more or less daily basis.

One of the nice KMyMoney features that helps me a lot is the online transaction download. It’s cool, if you simply fire up your computer in the morning, start KMyMoney, select the “Account/Update all” function, fill in the passwords to your bank and Paypal accounts when asked (though also that is mostly automated using a local GPG protected password store) and see the data coming in. After about a minute I have an overview what happened in the last 24 hours on my accounts. No paper statement needed, so one could say, heavily digitalized. At this point, many thanks go out to the author of AqBanking which does all the heavy work dealing with bank’s protocols under the hood. But a picture is worth a thousand words. See for yourself how this looks like:

The process is working for a long time and I have not touched any of the software parts lately. Today, I noticed a strange thing happening because one of my accounts showed me a difference between the account balance on file and the amount provided by the bank after a download. This may happen, if you enter transactions manually but since I only download them from the bank, there should not be any difference at all. Plus, today is Sunday while on the day before everything was just fine. First thought: which corner case did I hit that KMyMoney is behaving this way and where is the bug?

First thing I usually do in this case is to just close the application and start afresh. No way: same result. Then I remembered, that I added a feature the day before to the QIF importer which also included a small change in the general statement reader code. Of course, I tested things with the QIF importer but not with AqBanking. Maybe, some error creeped into the code and causes this problem. I double checked the code and since it dealt with tags – which are certainly not provided by my bank – it could not be the cause of it.

So I looked at the screen again:

New data must have been received because the date in the left column changed and also the amount of the colored row changed but not the one in the row above which still shows the previous state. The color is determined by comparing the balance information with the one in the row above. So where is/where are the missing transaction(s)?

Long story short: looking at the logs I noticed, that the online balance was transmitted but there was no transaction at all submitted by the bank. And if I simply take the difference between the two balances it comes down to a reimbursement payment which I expect to receive.

Conclusion: no bug in KMyMoney, but the bank simply provided inconsistent data. Arrrrgh.

You might have seen the awesome Klassy theme by Paul McAuley for Qt applications and window decorations for KWin.

It has some issues compiling against the latest Plasma since the KDecoration API break.

Until it is fixed in the main repository, I’ve created a temporary fork that includes the port to KDecoration3 done by Eliza Mason, with a tiny additional fix I added on top of it. The fork is available at github.com/ivan-cukic/wip-klassy

The kdesrc-build recipe for it is:

module klassy
    repository https://github.com/ivan-cukic/wip-klassy
    cmake-options \
        -DBUILD_QT5=OFF \
        -DBUILD_QT6=ON
    branch plasma6.3
end module

Kirigami Addons is a collection of additional components for Kirigami applications. 1.7.0 is a relatively big release bringing a new convergent component for context menus as well as various quality of life APIs to existing components.

ConvergentContextMenu

This release bring a new component which wraps the tradional context menu Controls.Menu provided by Qt and on mobile will instead displays a BottomDrawer with the list of actions.

Using it, is really easy:

import QtQuick.Controls as Controls
import org.kde.kirigami as Kirigami
import org.kde.kirigamiaddons.components as Components
import org.kde.kirigamiaddons.formcard as FormCard

Components.ConvergentContextMenu {
 id: root

 // Only visible on mobile to show a bit of information about the selected element
 headerContentItem: RowLayout {
 spacing: Kirigami.Units.smallSpacing

 Kirigami.Avatar { ... }

 Kirigami.Heading {
 level: 2
 text: "Room Name"
 }
 }

 Controls.Action {
 text: i18nc("@action:inmenu", "Simple Action")
 }

 Kirigami.Action {
 text: i18nc("@action:inmenu", "Nested Action")

 Controls.Action { ... }

 Controls.Action { ... }

 Controls.Action { ... }
 }

 Kirigami.Action {
 text: i18nc("@action:inmenu", "Nested Action with Multiple Choices")

 Kirigami.Action {
 text: i18nc("@action:inmenu", "Follow Global Settings")
 checkable: true
 autoExclusive: true // Since KF 6.10
 }

 Kirigami.Action {
 text: i18nc("@action:inmenu", "Enabled")
 checkable: true
 autoExclusive: true // Since KF 6.10
 }

 Kirigami.Action {
 text: i18nc("@action:inmenu", "Disabled")
 checkable: true
 autoExclusive: true // Since KF 6.10
 }
 }

 // custom FormCard delegate only supported on mobile
 Kirigami.Action {
 visible: Kirigami.Settings.isMobile
 displayComponent: FormCard.FormButtonDelegate { ... }
 }
}

Icons on Android

Kirigami Addons components are using some breeze icons which needs to be packaged manually on android by calling kirigami_package_breeze_icons with the icons used. Now Kirigami Addons, provides a Cmake variable KIRIGAMI_ADDONS_ICONS listing all the icons used by Kirigami Addons, simplifying the maintainance work of applications to keep the list of icons used up-to-date.

kirigami_package_breeze_icons(ICONS
 ${KIRIGAMI_ADDONS_ICONS}

 // own icons
 ...
)

Shortcut Editor

Kirigami Addons’ shortcut editor can now be embedded in normal ConfigurationView via a new ConfigurationModule: ShortcutsConfigurationModule.

import org.kde.kirigamiaddons.settings as KirigamiSettings

KirigamiSettings.ConfigurationView {
 id: root

 required property TokodonApplication application

 modules: [
 ...
 KirigamiSettings.ShortcutsConfigurationModule {
 application: root.application
 },
 ]
}

FormCard

The FormCardPage now uses a slighly less grey to get more contrasts with the sidebar.

We cleaned up FormComboBoxDelegate to not relly on the applicationWindow() hack from Kirigami anymore. This fixes using FormComboBoxDelegate in Plasma Settings. Unfortunately some areas of Kirigami Addons still implicitely rely on applicationWindow() to set the parent of popups (Kirigami has a similar issue). If you are using dialogs or popup in your code, make sure to explicitely pass a valid Controls.Overlay.overlay as parent to them instead of rellying on applicationWindow() being valid all the time.

The FormCard.AboutPage now show the KDE Frameworks version in use rather than the one we built against. We are also using in the AboutKDEPage component, the same bug address as in the AboutPage component. And we fixed various other small issues with the about pages. Thanks Volker and Joshua!

Other

We now use clang-format automatically and various clang-tidy warnings were fixed. Thanks Alex!

Avatar are now loaded asynchronously which should make NeoChat, Tokodon and Merkuro list views smoother. Thank Kai! Addionally the text fallback is now only rendered as plain text, which should also be sligly faster.

The RadioSelector now uses the style from Marknote.

We updated the templates provided by Kirigami Addons to the latest version of the flatpak runtimes and some other minor improvements like using the new KLocalizedQmlContext.

AlbumMaximizeComponent now expose not only the currentItem from the internal view, but also the currentIndex.

The IndicatorItemDelegate and RoundedItemDelegate components are now easier to use with drag and drop interaction. You can see that in effect in last week update of Merkuro Mail.

MessageDialog now behaves better on mobile.

Packager Section

You can find the package on download.kde.org and it has been signed with my GPG key.

I run Home Assistant Core on a Raspberry Pi. I installed it in a Python venv and now and then I feel a need to upgrade. Today was such a day.

So, having backed everything up, I went for the plunge. Let’s install version 2025.1.2.

The usual dance goes a bit like this:

sudo systemctl stop homeassistant
sudo su homeassistant
cd /opt/homeassistant
source bin/activate
pip install --upgrade homeassistant
exit
sudo systemctl start homeassistant

Then all the dependencies are installed, so I usually go for a coffee, and once things have settled down (I use top to check that the system is idle), I usually restart homeassistance, just to make sure that it stops and starts nicely.

This time, I had no such luck. Lots of little issues. The major one seemed to be that import av in one of the core modules suffered from some sort of ValueError exception.

Having duckducked the issue for a while, I realized this meant that I had to do the upgrade from Python 3.12 to 3.13. Upgrading va to version 14.x using pip does not help. Since I always forget how to do this, I’m now writing this blog post.

Recollecting the steps, the moves are, more or less these:

sudo apt-get install python3.13 python3.13-venv python3.13-dev
sudo systemctl stop homeassistant
sudo su homeassistant
cd /opt/homeassistant
mkdir old
mv bin/ cache/ include/ lib/ lib64 LICENSE pyvenv.cfg share/ old
python3.13 -m venv .
source bin/activate
pip install homeassistant
exit
sudo systemctl start homeassistant

Again, restarting Home Assistant takes a while and a bit more since all the dependencies are built. Go grab a snack or just a quiet coffee and, viola, you will end up with a fresh install of Home Assistant version 2025.1.2