I've been administering KDE's participation in the Google Summer of Code program for the last few years (and mentoring on some). This post is just some personal thoughts on the differences between what the KDE organization expects and what usually the applicants want (I'm not in everybody heads, it's assumptions from my experience). I don't provide any solution (because I don't have any) and there is no judgment (both point of views are valid), just a personal point of view.

Applicants point of view

GSoC is a individual competitive program which can be a huge boost to start a career. There are usually two major reasons for the applicants to participate in GSoC:

• the money.
• the experience and the line in the CV for real life work.

There is, for a lot of applicants, no genuine interest in the projects (at least at the beginning, the first interaction is often "I want to start contributing to KDE and prepare for GSoC"), and they mostly want a GSoC slot. Small digression, on one of my projects, two people already asked to contribute and if we were doing GSoC, but after telling them that contributions are welcomed and we will only propose a topic if we feel enough confidence that the contributor would stay after, they told us they preferred to choose another project.

Contributors consider GSoC as an end of their studies, not a project they want to contribute after: there is also a change of life to consider between university life and work life and a balance to achieve when starting the latter (which could be in a different town/country) which may be a reason for the drop of interest.

Organization point of view

GSoC is an opportunity to welcome new contributors to our community. The organization usually expects from GSoC:

• contributors willing to contribute regularly to their projects.
• implementation (partial or total) of the proposed ideas.
• having a positive return on investment (is the time spent mentoring worth the result?)

GSoC is mostly a step to have contributors learning about the projects, and contribute in the long-term. Long-term is purposely vague; what we expected for the GCompris project was the contributor would contribute at least one year and mentor for the next GSoC (so a loop was present, and applicants would also gain an experience on mentoring, while giving some relief to the other experienced mentors) but it can vary depending on the project.

For the return on investment, mentors do not consider it good having spent more than three months mentoring for projects they could have done in less time they spent to mentor the contributor. Helping someone grow is always personally rewarding but we still hope this person will also show us the results of the teaching by improving our projects in the future.

Impacts of the differences

There is a huge difference on the expectations. What can we do to reach a common ground where everyone is happy?

• Organizations cannot force anyone to contribute after the GSoC end.
• If money is the main motivation to stay, most organizations will not have money to hire applicants to work after (and do we want to hire someone only motivated by money? No, it's not OSS values, we love passion).
• Find ways to create a real interest for the organization. In KDE, we have the chance to have tons of projects with different topics (astronomy, education, digital painting, video editing, scientific plotting, games, desktop environment, system administration, internationalization, ...) where it is easy to participate to other projects from time to time and learn new things if we are curious enough.
• Be stricter on the entry point for organizations: explicitly say in the beginning that we expect a long-term relationship not just the equivalent of an internship. It should reduce the number of applicants and only keep the ones with a genuine interest (if applicants are honest of course).
• Organizations/Mentors could reduce their objectives of GSoC and consider that contributors are here to produce and spend less time on training/mentoring, expecting contributors already know the basics, but this would totally spoil the nature of the program.

Another track is to find the projects where contributors stay / don't stay and understand the difference. Most of the big KDE applications don't manage to keep their contributors, while smaller ones do. Maybe as a contributor, it's because it's more difficult to take decisions, feel included/listened on large projects because they have a high maturity level/long-term contributors and a well-defined vision? Whereas on smaller projects, there are fewer constraints from the existing environment and it feels more rewarding and motivating to contribute there?

To conclude, here are the statistics for KDE retention the last years:

That is, an average of 15 people sign up each year, of which

• an average of 90% finish
• 44% continued contributing 1 year later
• 28% continued contributing 2 years later
• 22% continued contributing 3 years later

We would of course love having more contributors staying at least one year but it's almost half and a quarter that stay active for a few years!

If you use Lokalize, you’ve probably run into this bug: the menubar reshuffles every time you switch tabs. Go from the Editor to the Project Overview, and suddenly the Edit, Go, and Sync menus disappear or swap places. It totally breaks muscle memory. As part of my Season of KDE project, my task was to fix it.

To give you an idea of the chaos, here is how the menus were jumping around before the fix:

My initial thought was that this would be a five-minute fix-just tweak an XML file and move on. I was very wrong. My first instinct was to nuke the cache and blindly shuffle tags around in the .rc files, hoping the UI would magically fix itself. It didn't. After wasting a day treating symptoms and trying to brute-force a solution, I had to admit I was just guessing. I closed my IDE and decided to actually figure out how the UI was being generated.

After diving into the KXMLGUI documentation, I realized I wasn’t fighting a single XML file. I was fighting a dynamic merge of six different files happening in real-time. Whenever you switch tabs, KXMLGUI actively merges and removes XML definitions. The problem was that the main lokalizemainwindowui.rc file used generic tags. These acted like open doors with no assigned seating. Whichever tab loaded last got to decide where its menu items went. Implicit design was giving us random results.

At first, I thought about centralizing all the menu visibility in C++, but that would ruin KXMLGUI's distributed design and require a massive refactor. Instead, I decided to enforce a strict "Global Skeleton" in the main XML file. By hardcoding the menu structure using index="N" attributes, I could create a reservation system.

<MenuBar>
  <Menu name="file" index="1"><text>&amp;File</text>...
  <Menu name="project" index="4"><text>&amp;Project</text>...
  <Menu name="tools" index="6">...
  <Menu name="settings" index="7">...
  
  <Menu name="edit" index="2"><text>&amp;Edit</text><MergeLocal/></Menu>
  <Menu name="go" index="3"><text>&amp;Go</text><MergeLocal/></Menu>
  <Menu name="merge" index="5"><text>S&amp;ync</text><MergeLocal/></Menu>
</MenuBar>

With the skeleton in place, I went through the child files (projectmanagerui.rc, translationmemoryrui.rc, filesearchtabui.rc) and updated them to respect these exact indices. The real trick here was giving tabs empty menus for sections they didn't even use.

<MenuBar>
  <Menu name="tools" index="6">...
  
  <Menu name="edit" index="2"><text>&amp;Edit</text></Menu>
  <Menu name="go" index="3"><text>&amp;Go</text></Menu>
  <Menu name="merge" index="5"><text>S&amp;ync</text></Menu>
</MenuBar>

By defining an empty menu with the correct index, KXMLGUI is forced to keep that menu on the menubar. Even if there are no actions inside it, the menu header holds its ground. This preserves the layout and stops the adjacent menus from sliding left and right when you switch contexts.

After updating the .rc files, adding one missing action (edit_approve_go_fuzzyUntr), and recompiling, the UI was rock solid. No more jumping menus, and all the keyboard shortcuts remained fully intact.

Lokalize Menubar Fix - Merge Request

Nicolas Fella wrote a bit about enabling memory leak detection in KDE CI, and I thought I’d add some comments from a different software engineering environment (e.g. my work-work).

Guidelines for Memory Management

At work-work, we have a slightly peculiar software environment:

• Bleeding edge C++ use – C++23 if possible, 26 features being experimented-with – and a strong reliance on C++ language and library features. Use C++ containers, std::string (with an *implicit “here be UTF-8-encoded strings”), std::jthread, business-logic in standard C++ wherever possible.
• Qt 5.6.3, from 2017, for UI code. That’s pre-C++17.

This leads to two guidelines about memory-management in our application:

• Use Qt’s memory model and ownership only for QWidget’s inheritance tree,
• .. well, ok, incidentally for things inheriting from QObject.
• Use C++ resource management for all other memory-management.

This does mean that depending on where in the codebase you’re working, you either have to be a “C++ purist” (as Nico puts it) or a “Qt pragmatist” (as I’ll phrase it). Note that the guideline is not “use smart pointers”, because that last guideline can deconstructed a little (it wouldn’t surprise me if this was inspired by Klaus Iglberger):

• If a class manages a resource, then that resource-management should be the only thing it does,
• If an object needs resources, then those resources should be members (sub-objects) of a class as above.

Often that means that memory-management is in the hands of std::unique_ptr, but std::vector does the job also. We have a handful of other classes for resource-management as well, like a wrapper for FILE * for those places where we need to interact with C’s stdio library. Granted, FILE * is probably not a source of memory-leaks, but it is a managed resource, and forgetting one will lead to leaking file-descriptors in the long run.

Leaky Libraries

Dealing with memory leaks can be difficult particularly when they happen in libraries not under your control. As an example, I wrote this program ( headers elided for brevity) which is a Qt5 program:

int main(int argc, char **argv)
{
  QApplication a(argc, argv);
  QTimer::singleShot(5000, qApp, &QApplication::quit);
  return a.exec();
}

This is, like, the simplest Qt5 program. It sits there for five seconds and then quits. It also leaks 1662 bytes of memory, in 19 allocations, according to my ASAN output. They leak from allocations done in libQt5Core. Adding a QLabel and displaying some text adds leaks in libfontconfig, and the leaks keep accumulating as more libraries enter the mix.

Granted, none of these leaks are large. I’m not even sure that they are impolite, but they’re there and it makes tracking down leaks in my code harder, because there’s some baseline of leakage that I need to ignore. Filtering out the noise becomes a serious undertaking.

Takeaway

Chasing all the memory-leaks is hard. Chasing any leaks in KDE Frameworks is something I can only applaud.

Leaking memory is impolite. It’s messy, it can suggest logic bugs, and thanks to AI grifters RAM is expensive.

Unfortunately C++ makes it rather easy to leak memory. Fortunately we have tools to find such leaks. One such tool is Leak Sanitizer (LSAN) from the Address Sanitizer (ASAN) family. It’s using compiler-based instrumentation for the code to reports any leaks after the program terminates.

KDE’s CI infrastructed has ASAN enabled for a while. However the leak sanitizer part was explicitly disabled, so no leaks were reported as part of the CI build and test run. This is because a number of projects have pre-exisiting memory leaks that would cause the C build to fail. Of course those should be fixed eventually, but in order to do that we need to know where they are. Also, for projects that currently don’t have any leaks we want to enforce keeping it that way.

A few lines of Python later KDE’s CI system now allows to enable LSAN on a per-project basis. The .kde-ci.yml file that governs CI builds in KDE gained a new option enable-lsan. It is off by default for now for compatibility, but we may consider enabling it by default eventually.

If enabled and any memory leak in a test is detected, that test and therefore the whole CI pipeline will fail.

Now once we found a leak, what can we do about it? There’s several options:

• Use good old delete/free(). Works, but is often rather error-prone.
• Use QObject’s parent mechanism. Works, but often frowned upon by C++ purists. Mostly makes sense for widget hierarchies.
• Smart pointers like std::unique_ptr/std::shared_ptr. These are great because they allow to express the ownership on an API level and make ownership transfers explicit. Often the best choice for business logic code.

LSAN is now enabled for some Frameworks CI builds, but ideally it would be enabled for all KDE projects. And of course any leaks found along the way should be fixed.

Happy leak-fixing!

Tellico 4.1.5 is available, with a couple of updates. This will be the last release that retains compatibility with Qt5.

Improvements

• Fixed Arxiv ID search to return correct results.
• Updated the Data Crow importer for its new XML format.
• Updated the IGDB source.
• Corrected XML usage for arch with unsigned char, like ARM.

I’ll have the next release out soon, v4.2, with several more updates, and requiring Qt6.

While the official coding period for SoK starts on January 23rd, my mentor, Finley Watson, kicked off a "preparation phase" this week to ensure we are ready to hit the ground running. I'm calling this "Week 0."

The goal was simple: set up kde-builder on my Fedora and compile Lokalize before the real work begins.

The Setup Struggle

I initially planned to use a manual build, but the Week 1 preparation guide provided by Finley explicitly recommended setting up kde-builder.

Of course, it didn't work on the first try. I kept hitting a Python error about a missing setproctitle module even though I had installed it.

After some digging, I realized my terminal path was missing ~/.local/bin, so the helper scripts weren't actually running. A quick fix to my .bashrc and a manual run of initial_setup.sh, and the build finally started.

Twenty minutes of compiling later, I had a working Lokalize built from source!

Since the build was working, I decided to take a peek at the bug I'm supposed to fix next week: the "Jumping Project Menu."

Basically, when you open a file, the Project menu physically shifts to the right. It's super annoying for muscle memory.

I dug into the .rc files (the XML that defines the UI) and found the culprit in lokalizemainwindowui.rc.

<MenuBar>
  <Menu name="file"><text>&amp;File</text>
    ...
  </Menu>

  <Merge/>  
  <Menu name="project"><text>&amp;Project</text>
    ...
  </Menu>

That tag tells KDE: "If a child window has extra menus, put them HERE."

When the Editor loads, it creates its own menus (like "Go" and "Edit"). Because of that tag, they get inserted right before the Project menu, pushing it down the line.

The Fix? I think I just need to "reserve the seats" in the main XML file. If I add placeholders for Edit, View, and Go in the main window, the Editor should merge into them instead of pushing everything else around.

I'll test that theory properly next week. For now, the environment is ready.

Every year the KDE Community actively helps people to become active community members and contributors to Free Software through our Season of KDE mentorship programs.

We would like to warmly welcome this year's mentees Aviral Singh, Keshav Nanda, Vishesh Srivastava, Varun Sajith Dass, Aditya Sarna, Jaimukund Bhan, Navya Sai Sadu, Kumud Sagar, Arun Rawat, Tanish Kumar, Ajay Singh, Mohit Mishra, Rohith Vinod, Shivang K Raghuvanshi, Onat Ribar, Hrishikesh Gohain, Aryan Rai, Advaith SK, CJ Nguyen, Siddharth Chopra, Nitin Pandey, Pavan Kumar S G, Sayandeep Dutta, Sairam Bisoyi, and J Shiva Shankar. They will be working on 21 projects covering a wide range of apps, frameworks, utilities and software in general to improve KDE.

Sok 2026 Projects

Standardise translation reference paths across all KDE projects

Translators work on PO files that contain the translation data, including the file path to the file that the specific translation comes from. To understand the purpose of a particular string, sometimes the translators need to view the translatable strings in the code itself. To allow KDE to build tooling around the paths, the PO files must be standardised so that all contain file path references relative to the project root rather than from an arbitrary directory.

This work has been started already but will be finished during this SOK project. Aviral Singh and Keshav Nanda will work under the guidance of Finley Watson on edge cases, testing and cleaning up the merge requests ready for merging. They will also improve the test script.

Lokalize tasks

All Lokalize projects will be mentored by Finley Watson.

Introduce Appium testing

Vishesh Srivastava will be integrating Appium testing in Lokalize. Appium is already used by other KDE software, and could be very helpful for testing UI changes, including keyboard shortcuts. This task will include coordinating with other mentees as they modify parts of the UI, as well as writing other general tests.

Improving logic consistency and MacOS platform stability

Varun Sajith Dass will work on fixing reported bugs, and improving string processing in many parts of Lokalize. Varun's aim is to increase the robustness of Lokalize's existing features, improve the quality of the output, and make following the Human Interface Guidelines easier for translators. This work will require coordination with other mentees e.g. for writing tests. Varun also aims to make it possible to build Lokalize on MacOS by fixing bugs related to this.

Fix the glossary

The glossary tab in Lokalize is unintuitive and hard to use, and currently crashes Lokalize unless you manually add the file that saves the glossary data to disk. Aditya Sarna and Jaimukund Bhan will update the UI so that it is easier to use, improve the glossary's behaviour, fix bugs and better follow the Human Interface Guidelines. They will work with the translators and visual designers to ensure their work follow KDE best practices and creates meaningful improvements.

Jump to next translation unit when sort filters are applied

The editor tab contains a dock widget called "Translation Units" which has the ability to filter and sort entries in translation files with the search bar. Moving between entries while approving them by using the shortcut jumps about in the list, rather than working down the sorted list correctly, one after another. Navya Sai Sadu and Kumud Sagar will be working together to fix this so the keyboard shortcut behaves as expected.

Redesign translation memory tab

The translation memory tab allows you to pick a TM (saved translation pairs from previous translation jobs / files) to search through, and shows the results in the list below. Arun Rawat will be redesigning the UI to enable searching multiple memories at once, with these settings saved per-project. Additionally, the Translation memories manager will be merged into the tab instead of existing separately e.g. by moving TM-specific entries into the right-click menu, and adding more general buttons into the TM tab page, or the toolbar that is specific to the TM tab.

Standardise menubar

Lokalize uses a KDE framework, KXMLGUI, to manage its menubar and status bar. In Lokalize, KXMLGUI allows you to define the contents of the menubar for each tab. Right now the tabs have different ordering of menus with some menus missing in certain tabs.

Tanish Kumar will re-design the menubar so all tabs to offer the same menubar. Where a tab does not use a menu, the menu will be added, with menu options disabled.

All Lokalize projects will be mentored by Finley Watson.

Investigate alternatives to dblatex to convert docbook to pdf

KDE’s documentation build pipeline currently relies on a legacy, copy-pasted fork of dblatex embedded inside the docs-kde-org repository. While functional, this setup obscures Git history, complicates upgrades, and makes KDE-specific customizations such as kdestyle difficult to understand and maintain.

Ajay Singh, under Johnny Jazeix guidance, will investigate the possibility of using other tools than dblatex (such as pandoc) to create the pdf from docbook. The aim is to see if it fixes the current issues we have with non-supported non-ascii languages. And if there is a working alternative, he will work on trying to have a similar style to what we currently have in the kdestyle.

Extract dblatex fork from docs-kde-org repo and improve non ascii languages support

we are currently reworking the documentation website. The first task was to generate the documentation of each repo in a specific job.

Mohit Mishra will work on extracting the dblatex from the code into its own repo (keeping the history) and finding out if we can directly clone the original repository instead of having a fork.

Mentored by Johnny Jazeix, the overall goal is to try to use the upstream dblatex (shipped in distributions) to generate the pdf, experiment with XeTeX PDF generation engine instead of pdfTeX to create PDF for non supported non-ascii languages (Arabic, Chinese, Japanese, Korean...). If we can't improve it, extract dblatex fork on a specific repo to ease the maintenance`

Implement font subsetting when saving files in Okular

Okular supports PDF annotations and form-filling. When a user adds text to a document, Okular must ensure that the text remains readable on any system irrespective of whether the font is installed locally or not. Hence the font data is directly embedded into the document using the PDF rendering library Poppler.

The problem arises due to the lack of proper font subsetting (as Poppler does not support this). Modern OpenType and TrueType fonts contain thousands of glyphs for various languages and symbols.

Okular approaches this by embedding the entire font file into the document. This causes an undesirably large file size due to all the extra unused glyphs/symbols being embedded.

Rohith Vinod and Shivang K. Raghuvanshi, under Albert Astals' supervision, will work on solving this problem using the hb-subset-input-glyph-set API.

Plasma Setup: mobile support

Plasma Setup is KDE's first run setup wizard, providing a friendly way to create the first user account and configure basic system settings. Unfortunately it only works on desktop form factors

Under Kristen McWilliam's guidance,Onat Ribar will work on supporting Plasma Setup for Plasma Mobile as well.

KEcoLab

Recent updates in the lab mean that X11-based emulation tools like xdotool are obsolete. Guided by Joseph P. De Veaugh-Geiss, Karanjot Singh, and Aakarsh MJ, Hrishikesh Gohain will be tasked with porting existing scripts to a Wayland-based tool. Once Wayland support is ready, Hrishikesh will prepare test scripts to measure the KDE Plasma Desktop Environment itself.

Turning mentorship.kde.org into a proper onboarding platform

mentorship.kde.org currently looks like a website, but does not behave like an onboarding system. Aryan Rai and Advaith SK will be required to convert the site into a guided entry point for KDE mentorship.

Anish Tak and Paul Brown will be guiding Aryan and Advaith throughout the project.

Automate Promo data collection

Promo collects data from different sources that measure how our followship grows, how many outlets are talking about us, what is our level engagement, etc. This information is currently collected by hand and is a massive time drain. CJ Nguyen, mentored by Paul Brown, will create systems to automate the collection, storage and analysis of this data.

Markdown and plain text editors for Marknote

Siddharth Chopra will be adding two editors to MarkNote, an app that lets you create rich text notes and easily organise them into notebooks. The first editor is a raw markdown editor for .md files and a plain text editor for .txt files.

Siddharth also plans to work on making some improvements to the current markdown editor.

Carl Schwan will be Siddharth's mentor in this project.

Making Cantor’s existing tests visible, reproducible, and actionable in CI

In this project, Avyakt Jain aims to activate Cantor’s existing testing infrastructure in a low-risk, incremental, maintainer-friendly way by (1) producing a clear, factual overview of current test coverage and gaps, (2) enabling a minimal, MR-scoped CI test job that provides visible JUnit-based feedback, and (3) improving reproducibility and documentation for running tests locally. The expected outcome is faster, more reliable feedback for maintainers and contributors, without enforcing new quality gates or changing Cantor’s runtime behavior.

Alexander Semke and Stefan Gerlach will be supervising Avyakt's work.

Call log synchronization and backup in KDE Connect

Nitin Pandey will be working on improving telephony integration in KDE Connect by implementing call log synchronization and backup from Android devices to the desktop. Instead of creating a separate desktop client for call history, the project will integrate call logs directly into the existing KDE Connect SMS client on the desktop, providing a unified communication view.

Albert Vaca will be mentoring this project.

Enhancement of KDE Mancala: Engine Parallelization and Digital Asset Creation

Pavan Kumar S G will speed up MankalaEngine by enabling it to use threads, Pavan Kumar SG will also create artwork to be used in the Mankala NextGen GUI.

This project will receive guidance from Benson Muite and Srisharan VS.

Improve Mankala GUI and add translations for Game variants

Sayandeep Dutta will improve the visual appeal of Mankala NextGen GUI and contribute towards it going through KDE Review. In addition, Tamil translations will be created for MankalaEngine and Mankala NextGen.

Srisharan VS and Benson Muite will support this project.

XMPP Support in Falkon through WebXDC

Sairam Bisoyi will create a Falkon extension to allow it to be used for chat using the XMPP protocol and its WebXDC extension..

The project advisors are Schimon Jehudah, Juraj Oravec and Benson Muite.

Adding Vamana Guntalu to Mankala Engine and a WebXDC bookmarking system in Falkon

J Shiva Shankar will add the Vamana Guntalu mancala game to MankalaEngine. J Shiva Shankar will also create a Falkon extension to allow synchronization of website bookmarks across different devices using the XMPP protocol in a WebXDC application.

The project advisors are Schimon Jehudah, Juraj Oravec and Benson Muite.

Stay in the loop!

You will be able to follow the progress of all mentees through their blog posts on KDE's planet, and by joining the relevant project communication channels.

Changelog

• Correction bug 512770: some accounts doubled in "amount" vs "today amount"
• Correction bug 513589: QIF import errors
• Correction bug 513016: skrooge-boursorama.py don't work
• Correction bug 514649: Performance issue
• Correction bug 514649: "Open transaction with..." and some other are empty