Hey Qt!

tldr; save the date for our QtCS25, May 7-8 in Munich.
Stay tuned for more information.

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.