SoK on KDE Blogs

Season of KDE 2026 – Final Blog

Keshav-Nanda — Tue, 07 Apr 2026 00:00:00 +0000

Greetings to everyone in the KDE community!

As SoK '26 comes to a close, this blog post summarizes the work done in the second half. Please refer to my mid-term blog post for further context.

My SoK task was to ensure all the .pot files generated have source references relative to the project root.

Upon discussion with my mentor, Finley Watson, and my teammate Aviral Singh, we decided to create merge requests to a throwaway repo made by our mentor to ensure that all the messy commits are cleaned up and functioning well. This was also done to ensure that the MRs don't create regressions of any kind.

I created an MR that modifies the createdesktopcontext.pl file. Instead of using lazy regex to manipulate the path string and extract a basename, I used Perl's built-in File::Spec->abs2rel to compute the correct project-root-relative path programmatically.

I also created MR !121 which makes use of Aviral's validation script to ensure that the logs generated match the format of Scripty's existing logs. The MR ensures that there is:

One WARNING in <file>: <message> line per bad path
One self-contained summary line per POT, always printed
Zero noise when everything is clean

Conclusion

Looking back, SoK has taught me a lot of things. I've learnt how to navigate complex codebases, read and write Bash and Perl, and deal with complex version control rather than just git add ., git commit -m and git push ;)

I've also realised how important commit history and messages are (which I never paid much attention to while developing personal projects). Overall, this has been an amazing and enjoyable experience for me and I would like to thank my mentor Fin for the guidance, and Aviral for being a great teammate throughout.

Season of KDE 2026 - Fixing the Glossary in Lokalize (Final)

Jaimukund Bhan — Mon, 06 Apr 2026 00:00:00 +0000

Greetings to the KDE community!

This is a blog which follows my previous post and includes the work I did in the second half of Season of KDE.

Improved manual Glossary term addition

There are two methods to add terms to the glossary. The first one is to highlight the source and target terms in the Editor Tab, and then using the context menu in the Glossary View to Define a New Term. The second is to manually add new terms through the Glossary Tab without any prior text selection. Previously, when a term had to be added manually, a blank entry was made first, which the user could then edit. This meant that multiple blank entries could be accidentally accumulated in the Glossary file. Users are now prompted to enter the source and target terms in a dialog box when trying to add terms manually, removing the need of creating blank entries.

Fixed the shortcut key for Previous Active Tab

The shortcut key for switching to the Previously Active Tab was not working properly as the currentChanged signal updated the current index of the m_mainTabs before the previous index could be saved to the previousActiveTabIndex variable. I updated the event filter to catch tab switches made through mouse clicks and replaced the integer variable with a widget pointer, since it would remain valid even if tab positions change, whereas an index-based would require calculations.

Making Plasma Setup More Mobile-Friendly: A SoK'26 Conclusion

Onat Ribar — Tue, 31 Mar 2026 00:00:00 +0000

Hey everyone! SoK '26 is wrapping up, so here's my final post. If you haven't read the midterm update yet, I'd recommend starting there — this post picks up from where that one left off.

Some relevant links:

TLDR: The project

Plasma Setup is KDE's first-run wizard: it greets you on a fresh install and walks you through account creation, keyboard layout, timezone, and basic system config. It was built with desktop screens in mind, and my project was to make it work properly on phones and tablets running Plasma Mobile without breaking the desktop experience.

Where the midterm left things

By the midterm I had worked through most of the UI issues: overlapping components, wallpaper disappearing on portrait layouts, the wizard not filling the screen on mobile, the hostname field overflowing, the timezone page's OpenStreetMap widget being too fiddly for touchscreens. Two MRs were open, one in plasma-setup and one in plasma-workspace for the timezone selector since that component lives there. The plan was to spend the remaining weeks getting them merged.

That's roughly what happened, though it took longer than expected. I requested a two-week extension so we could handle the review process properly rather than rushing it.

What the second half looked like

Mostly review cycles. Writing the MRs was one thing; getting them merge-readywas another. A fair amount of that time was spent in the terminal, checking diffs, rebasing, keeping the history clean, more than it was actually writing new code. Anyone who's worked on a shared codebase knows how that goes.

The MRs were fairly dynamic throughout. Ideas came up during review that hadn't been in the original scope, some made it in, some got tested and scrapped. The final diff looks quite different from what was there at first open, which is usually a sign the review process is doing its job.

What I did recalibrate to was the specific culture of OSS contribution. The conventions are different from a professional codebase: how commits are structured, how feedback is framed, what a well-scoped MR looks like in this context. Not a harder or easier bar, just a different one, and getting fluent in it is part of the work.

The open threads from the midterm

I flagged two things in the midterm that weren't guaranteed to get done: virtual keyboard handling and the kcm_keyboard dependency decoupling.

Neither got done. The virtual keyboard situation is an open design question for the project, not something I could resolve within this scope. The kcm_keyboard decoupling is something I'd still like to take a crack at. The underlying issue is real: a mobile setup wizard probably shouldn't need to pull in plasma-desktop. But testing showed it wasn't causing visible breakage in practice, so it got deprioritised in favour of getting the UI work properly landed. Worth picking up as a future contribution.

See it in action

Wrapping up

I participated in SoK '25 as well but had to drop out partway through, so finishing this one properly feels good. Plasma Setup on mobile is in a noticeably better state than it was ten weeks ago, and the changes are upstream, which is what matters.

I'm planning to keep contributing to KDE and take on more within the ecosystem. There's plenty left to do and I'd like to have a more permanent stake in it.

Thanks to Kristen McWilliam for the mentorship throughout, and to KDE and the SoK programme for running this. It's a genuinely good way to get people into open source contribution.

You can reach me on Matrix at @onatribar:matrix.org.

Until we meet again!

[SoK 2026] Final Update for 'Automating Promo Data Collection' Task

CJ Nguyen — Fri, 27 Mar 2026 00:00:00 +0000

Hi all! Just finished up the last bit of work for my Season of KDE task of automating data collection for the KDE promotional team.

Since the midterm blogpost I've been assigned no new tasks. That means my final deliverables are a follower/post count scraping script for specific social media websites, a Reddit Insights page scraper that totals weekly insight data for a given subreddit, and an article evaluation script that reads articles found by the Google Alerts system and evaluates their sentiment on KDE and its software.

Follower and post counts scraper

Nothing much has changed here outside of some better error handling, consistency in argument help strings, and improved readability of log messages. The script has run well on its weekly timer and seems to show no signs of giving up. I do think I can improve it by making it more extensible to accommodate the scrubbing of new websites and accounts, but as of now it functions well for the links we're most worried about.

Reddit Insights page scraper

In the prior blogpost I mentioned worries about getting the script to run on a headless server. The script has since been made capable of running headlessly through use of a Docker image which wraps the program run with an Xvfb display server. Xvfb enables this by running display requirements in virtual memory, allowing for the use of headful software in a headless environment.

Shoutouts to Sean Pianka's repo containing dockerfiles used to run Xvfb-wrapped Selenium scripts and Selenium's own Docker images used for Selenium Grid server project. Without those resources it would have taken me a lot longer to hack together the requirements for a Docker image that could run Selenium headfully.

Along with the headless runs being solved, I also implemented plenty of bug fixes and improvements to user-facing messages. Many of the bugs came from not properly exiting Selenium during handled errors which I found out from the server having hundreds of open Firefox instances. Hopefully I've cleaned all those up.

Google Alerts evaluator

This task was a fairly large undertaking involving plenty of research and implementation steps. There were three major requirements:

Develop a pipeline to take in Google Alerts emails and pre-process them into articles the model can read.
Evaluate lightweight sentiment analysis models that can run on a server for their ability to analyze articles on KDE products.
Parse model output into a human-readable and easy to work with data format.

The final result is a pipeline that

Reads Google Alerts emails
Pre-processes the articles into Markdown files for model reading
Feeds them to a local LLM configured to provide sentiment analysis output
Takes the LLM output and sends it into a CSV file (if possible)

You can see how this task could take a lot of time out of people, so hopefully this pipeline can significantly alleviate that time spent.

Google Alerts email reading and processing

This was no issue as Google Alerts are all sent through Gmail and Google itself provides a very useable Gmail API for extracting emails from Gmail accounts. After generating the required credentials, fetching emails was as easy as using tools built specifically for this job in a Python package that contained bindings for the Gmail API in Python. The emails were all formatted in XML, so past experience with webscraping from the last two tasks played a part in making fetching article links from the emails painless to implement. After the article links were extracted from the emails, their contents were then fetched in Markdown format for use with the decided model.

Model evaluation

We very quickly looked towards some local large-language models (LLMs) to serve the sentiment analysis task. There were more than a few sentiment analysis fields that would be difficult for more basic models and it simplified implementation greatly. After the evaluation of some small-footprint models, by far the best at both conforming to the desired output format and performing sentiment analysis on the articles was Qwen3 with 4 billion parameters. It is lightweight enough to run on an older CPU in decent time, and while it doesn't agree amazingly with human judgement it more often errs on the side of caution, such as deciding more articles are related to KDE than aren't which wastes time but doesn't exclude relevant articles.

Designing model output and post-processing

It turns out that LLMs come in different flavors, and some, specifically instruct models, are much better at conforming to instructions than others. Many attempts were made to make other types of models provide output in a strict format and, if you need specific output, it's a headache you should definitely consider avoiding by choosing instruct models from the start.

An instruct model coupled with a well-constructed system prompt (the meta prompt that sets initial instructions for the model) and grammar file written in GBNF format can cause model output to be very predictable. The system prompt written for this task is specifically constructed to bound model output by asking it to output sentiment analysis features in a Python formatted array of strings. Even with the above methods, instruct models still do botch output occasionally, so the script contains plenty of post-processing and error handling steps before model output is processed into the output CSV file.

Experience and lessons learned

I've learned a significant amount about web scraping and how to navigate data troubles. I'm definitely a lot more confident about using developer webtools, HTML processing, and browser automation frameworks as a result of my SoK experience. Also after working on the Google Alerts sentiment analysis task, and I certainly feel more educated on AI topics and how they are used and deployed.

My project was a little unusual in that I wasn't working on an existing KDE software but utility scripts that were built from ground-up for KDE community members. This made things fun through the freedom I had with implementing solutions, but I feel the scripts are not fully developed or as problem-free as possible. I'd hate to just leave them as is while feeling that way, so I'll continue working on the already made scripts as well as new ones so long as I can help out.

Huge thanks to Paul Brown for mentoring me through this project and being a pleasure to work with, as well as the KDE community for hosting this great event. I had a lot of fun working on these scripts and am glad I could help out by contributing something to this awesome community.

Season of KDE 2026: Wrapping up

Siddharth Chopra — Wed, 25 Mar 2026 00:00:00 +0000

Greetings!

As we're nearing the end of SoK 2026, I am writing to share my experience and progress since my previous blog.

The second half of my SoK project has been a real learning experience for me, about how contributions to KDE and open-source communities in general work. I also learnt the importance of thorough testing, bug fixing, and polishing that is required before shipping any software.

Technical update and challenges faced

Till the halfway mark, I was able to complete a rough working version of the source mode editor. But after feedback from my mentor, I realized that a lot of work was still left to be done.

Firstly, there were a lot of repeated lines of code in my solution, as I had essentially split the existing editor into two - the rich editor and the raw editor. This meant that a lot of the functionality was common between the two editors, and I had re-used existing code for that. This was true for both the QML pages and the C++ document handlers. As I now realize, that would have been a nightmare for maintainability, as any single fix or change would have to be made in two places.

The fix for the C++ part seemed to be obvious: to use inheritance. So I decided to make the RichDocumentHandler and RawDocumentHandler inherit from a common parent, the DocumentHandler. DocumentHandler now contained all the common methods, significantly reducing repeated lines of code.

Similarly on the QML side, I made a parent component, EditPage, and made the Rich and Raw edit pages inherit from it. This caused some issues (mostly related to property sharing between components) that were eventually fixed.

A major issue I faced was caused by the fact that my MR essentially removed the existing EditPage.qml and documenthandler.cpp (although files with the same name are still present, they serve different purposes). Their contents were divided into two files - the rich and raw versions respectively. But while I was working on my feature, other contributors were still modifying the old files. Git can't handle this automatically, because the old file is in a way completely changed. This meant that I had to manually go through each commit to the old files, and move the changes accordingly to the new files. This proved to be a major headache, and caused me (and even Carl) to spend considerable time manually rebasing. So when finally the feature was merged, it was a sigh of relief, as we wouldn't need to manually maintain it anymore!

Apart from this, I also added a spell-checking capability to the editor, using Sonnet.

Demo

Learning and experience

I was grateful to see my work get published in Marknote 1.5 - and also felt a responsibility at the same time. Source mode is an asset for the app, but at the same time any bugs in my work are also a liability!

I learnt how a professional application is different from a hobby project, and how the quality and rigour of work should reflect that.

It was a really fun experience working with the KDE community and I'd like to thank my mentor Carl Schwan for always being there to help!

SoK has been a great first stepping stone to introduce me to the community, and I'm looking forward to contributing to Marknote and other apps even after the program!

Season of KDE 2026 - Improving mentorship.kde.org for better onboarding of new contributors

Aryan Rai — Sat, 21 Mar 2026 00:00:00 +0000

Greeting everyone! I am Aryan.

I have only just started my open source journey and was glad to be a part of SOK program. I really learned a lot which I think I otherwise would have not. With this blog I will be sharing about the project I worked on and also my learnings and future endeavour.

For the last 2 months me and my fellow partner Advaith SK worked on ways on how to improve the existing mentorship.kde.org so that it is more accessible and user friendly for new contributors as well as we tried to structure the internals of the website for better code readability and resuabililty.

Why was this project relevant

mentorship.kde.org is basically the first page a new contributor visits when exploring about KDE. So it is very important for the website to not overwhelm the new contrbutor but provide all the relevant information and links in a ordered and systematic way.

What problems did I identify

We noticed a gap in the project, KDE organizes many programs throughout the year for mentoring and developing more and more contributors. But we noticed that there was no single page that lists all the relevant programs a candidate might be interested in. Moreover on the developer's side we noticed that the repo of mentorship.kde.org is using many different cards for displaying its data throughout, and each card was schematically different than the others but in the end all of them were pretty much serving the same purpose.

What were the solutions

To solve this, I built a separate /programs page for the website, whose task is to only list all the programs that KDE organizes throughout the year. And to solve the developer's side problem, I standardized the cards. So basically for each component using their own rules for displaying cards, what I changed was I implemented a central card.html and card.scss which governs all cards. In case of some variations required I introduced the $variants feature of Hugo to carefully keep the uniqueness of cards required for each page.

Merge requests

Miscellaneous

I also noticed that in the resoruces page, the resources listed are relatively few, moreover the hyperlinks provided were also not updated. So I added more resources there and also updated the broken links present previously.

Future work

To attract more new contributors, in future we can also extend our project to have a hall of fame section where there is list of blogs of all graduated students of a particular program.

Final thoughts

A big thank you to my mentors, drowsywings and paulb, for thoughtful guidance and constant support throughout the project.

I have grown in this season with more confidence, more curiosity, and even more appreciation for the people behind free software infrastructure. I will be proud even if this work helps just one curious contributor to get onboard with the KDE ecosystem.

[SoK 2026] Appium Testing for Lokalize

Vishesh Srivastava — Fri, 20 Mar 2026 00:00:00 +0000

Hey there! I'm Vishesh Srivastava, and this is the full write-up for my SoK 2026 project: adding Appium-based UI tests to Lokalize.

So what's Lokalize?

It's KDE's translation tool - the app translators use to work with PO files and manage translation projects. It already had unit tests, but no UI tests. So the goal of this project was to setup a UI testing framework using Appium.

The first task: Bug 514468

Before Appium work started, my first task was Bug 514468. The issue was that copyright year strings in PO headers could become very long, like:

2006, 2010, 2011, 2012, 2013, 2014, 2015, 2017, 2018, 2019, 2020, 2021

instead of the shorter:

2006, 2010-2015, 2017-2021

I was asked to write a failing test first, so I added a placeholder simplifyYearString function and wrote a unit test for the expected collapsed output. At first it was pushed with QEXPECT_FAIL, since the actual implementation was meant to be done separately.

This was small compared to the main project, but it helped me get comfortable with setting up KDE's build system and how tests are added to Lokalize.

Building the Appium setup from scratch

Lokalize had no Appium setup at all, so this part started from zero.

The first tests were simple:

simple_open.py just opens Lokalize and closes it
file_open.py opens the File menu and checks that the open dialog path works
workflowtest.py simulates an actual translator workflow

That last one was the main test I was aiming for. It opens a .po file with untranslated entries, types translations into the editor, uses "Approve and Go Next", checks that the UI updates properly, verifies the status bar reaches Not ready: 0, and finally saves the file.

That made it a proper end-to-end test.

Problem encountered in the last test

Appium depends on accessibility information to find and interact with widgets. Lokalize's editor fields did not expose accessibility ids for Appium to call them (found using accessibilityinspector).

So I had to make changes in editorview.cpp to add object names and accessible names to the widgets. Without that, the test scripts could open the app and click menus, but they were basically blind when it came to the translation editor.

Other KDE apps with Appium tests, like Dolphin and KCalc, had tests which used these and were useful references here.

Below is a demo of this working:

Making it run with the rest of the test suite

The next step was integrating the Appium tests into CMake so they could run as part of Lokalize's normal test flow.

I added an appiumtests/CMakeLists.txt and a BUILD_APPIUM_TESTS option, so the tests can be enabled and run through the normal KDE tooling:

kde-builder --run-tests lokalize --no-include-dependencies --no-src --cmake-options="-DBUILD_APPIUM_TESTS=ON"

That was important because UI tests are much less useful if they live outside the project's regular test workflow. The BUILD_APPIUM_TESTS option was kept because it was not advised to run Appium tests in the CI/CD.

Another issue: Making the tests independent of the local user setup

One issue was that on opening, Lokalize asked for a name and email address which I was earlier typing manually. This was undesired since tests had to be run without user intervention.

So I added a file test_support.py, that creates a temporary config directory, writes a minimal lokalizerc, and launches Lokalize with that isolated configuration. That way the tests do not depend on my own existing settings or require any user input.

I also reused that helper across the test files so they stopped repeating the same Appium setup code again and again.

Writing a failing bug test

After the main workflow test, I also added another Appium test for a real UI bug: after closing a project, translational tab menus should become disabled.

This test is in project_close.py. It opens a project, closes it, and then checks that menus like Edit, Go, and Sync are disabled.

Fixing how the tests are executed

At first, the Appium tests were being discovered and registered individually in CMake. The next task was to run them from a single run_all.py runner. Now all the tests use a single KWin instance like they do in other projects like Dolphin.

This also makes writing new tests simpler since adding a test just means adding a new line in the run_all.py. So instead of CMake looping over every Python file, it now calls the runner once.

There was also one annoying issue here: --run-tests was reporting success even when one of the Appium tests had failed when run manually. Because of that, I had to return sys.exit(1) explicitly from the runner when the test result was not successful. Without that, the tests looked successful even after failing.

Below is a demo of this working:

Outcomes achieved

By the end of the project, Lokalize had:

a working Appium test setup
basic tests for startup and opening files
a full workflow test covering translation editing and saving
helper files to make tests cleaner and independent of local user config
integration into the normal test system through CMake
a single test runner file
documentation on how to run/write tests.

Final thoughts

This was a really enjoyable project. I got to work on Appium testing, the KDE build system, and a bit of bug hunting.

Many thanks to Finley Watson for his guidance throughout the project and for helping whenever I got stuck.

The best part for me is that the work is extendible. New Appium tests can be added without rebuilding the whole setup from scratch, which was the main point of the project in the first place.

Season of KDE - Midterm Blog

Keshav-Nanda — Fri, 20 Mar 2026 00:00:00 +0000

Hello world!

My name is Keshav Nanda and I had the opportunity to work with Scripty, a KDE bot that extracts translatable strings from various KDE applications and sends them to KDE translators.

I worked on the issue of standardizing translation reference paths across all KDE projects and this blog summarizes my progress up until the 4 week mark.

Week 1 and Week 2

Couldn't get much work done as I was occupied with university exams.

Week 3

Got my feet wet with the actual source code, went through MR 90 and developed a basic understanding of the problem that needed to be solved, that is to ensure that all .po files generated by Scripty are relative to project root.

Week 4

Helped my partner Aviral in testing his implementation of merge request 116 and added to the KDE projects he validated. This MR added a docker environment to standardize the testing process and made changes in extract_metainfo.sh and extract-messages.sh to enforce relative file paths.

Conclusion

The first 4 weeks have been a great learning experience. I got familiar with Scripty's codebase, understood the core problem of inconsistent translation reference paths, and contributed to validating the fix. The goal going forward is to continue testing and work towards getting the changes merged. I want to thank my partner Aviral Singh and my mentor Finley Watson for the guidance and support throughout!

Onwards and upwards!

Season of KDE 2026 - Task - 3 Lokalize

Kumud — Fri, 20 Mar 2026 00:00:00 +0000

Progress Report — Midterm — SOK 26

Mentor: Finley Watson
Project: Lokalize

Week 1

Week one was basically just ensuring that I have a good understanding of the relevant code in the repository. I suggested a good approach would be to write a summary of the behaviour of the classes and functions involved. This turned out to work really well.

Week 2

Now that I knew how things worked in the codebase and the flow of functions, it was the right time to think about solving the issue. I had intuition about that since the entries did not respect the filtering order. This was largely because they used the wrong layer to fetch entries and if we used the proxy model it should work well. However, now the other condition that we had to respect while moving was to only go to unapproved entries. So I had to merge the filtering and condition checking.

The final approach I thought might work was to add a helper function that just gave the correct index to move to and wow, things started working :smile:

It was time to test it. Finley helped me with that. And I have to admit that once I resolved one edge case, there was another. This continued for a while and it was irritating, thinking that this will fix everything finally and boom another case appeared 😅.

We thought about an upgrade in navigation. This was moving to the next entry in navigation in a cyclic order. Finley and navya had a discussion over it on the mailing list and finally concluded that it was not required at all.

Finally the MR was merged. Nothing felt better than seeing it finally being a part of code that people across the globe are using... so cool 🔥

Results

Final MR.

Week 3

While fixing things up in the previous week, I had already seen many shortcuts that required a fix, and that the behaviour sometimes did not made sense.

I started with testing the shortcuts that are supposed to go to the first and the last entry, but somehow showed different behaviour each time. This was because of the widget currently in focus, so the behaviour of many shortcuts depends upon the widget you are using.

This was new information for me, so I researched how widget focusing actually works. Through this, I learned about the order in which applications process keyboard shortcuts and that some shortcuts are handled internally by Qt itself.

Week 4

I went ahead and checked the behaviour of other navigation shortcuts:

next/previous fuzzy entry
next/previous untranslated
next/previous bookmark

Results

Understanding of similarity in the behaviour of these shortcuts.

Weeks 5 and 6

I extended the work from the previous weeks and had my semester exams.

Week 7

I reported a bug in the behaviour of the next/previous bookmark in navigations.
I implemented next/previous bookmark based on navya’s approach

Season of KDE 2026 - Task - 3 Lokalize

Kumud — Fri, 20 Mar 2026 00:00:00 +0000

Week 0 progress Report — SOK 26

I am Kumud, a third year student at IIT Roorkee, and I am working as a mentee under the guidance of Finley Watson for SOK 26.

Over the past few weeks, I have been contributing to the Lokalize project and gaining familiarity with the codebase and the underlying architecture.

Initial setup

The first major task for me was to get the Lokalize code running on my local PC. There were many crashes that I encountered during the setup process. I initially thought that the issue might be related to my operating system, so I decided to try using a different one.

I installed KDE Neon in a virtual machine on Linux, and finally the code started running. However, I was not very happy with using a VM, since I already had limited storage on my PC and now it was being split with the virtual machine as well.

Later, when I joined the Matrix channel, Finley and Navya helped me with the setup. I realized that the main issue was simply that my Ubuntu installation needed to be updated. After updating Ubuntu, I was able to run Lokalize directly on my system.

Finally, I started working on Linux itself, which I was already more accustomed to using.

Getting familiar with the codebase

Before planning the proposal for Lokalize, I had to gain a good understanding of the code and the tools we were going to use.

To become familiar with a general codebase and to get comfortable using Git / GitLab, my mentor assigned me a task. The task was a basic one: adding a package to the repository metadata required to build Lokalize.

Results

Understanding of the codebase and about using GitLab.
Used repology to map different package names across different OSes.
MR approved.

Season of KDE 2026 - Lokalize Glossary Tab Improvements (Midterm)

Aditya Sarna — Thu, 19 Mar 2026 00:00:00 +0000

My name is Aditya Sarna, and I have been working on Lokalize, a translation software, as part of Season of KDE 2026. Along with my fellow mentee Jaimukund Bhan, I have been assigned to work on improvements to the Glossary tab, including both UI/UX enhancements and addressing a substantial list of bugs.

How I got here

I first came across KDE while exploring organizations that had participated in Google Summer of Code (GSoC) in previous years. During this process, I also discovered Season of KDE (SoK), which felt like a great opportunity to get involved. I joined the KDE Mentorship Matrix chat, where Finley Watson was kind enough to guide us. I then explored the list of tasks under Lokalize for SoK in detail and drafted proposals for the first two tasks.

While researching the first idea, I came across the KDE Human Interface Guidelines, which helped form the foundation for the suggestions I put forward in my next proposal. I was delighted to be selected for the second task.

Setting up

We started a little early, getting everything in order. I spent time familiarising myself with the Lokalize codebase and understanding the platform. I also joined an early discussion on the possible direction for creating and saving the glossary file, and that work was subsequently completed by Jaimukund. In the meantime, I began scoping out the necessary UI/UX improvements.

UI/UX improvements

The task involved replacing plain text labels ("+", "-") with proper icon buttons and adding tooltips to all the add and remove buttons on the page. [MR 273].

I also created a Figma design for a redesign of the deletion workflow, which had been suggested by the KDE Visual Design Group. The goal was to improve the workflow for translators.

Engaging with translators

One of the most valuable steps in this project was reaching out to the translators mailing list. The insights we gathered from that discussion helped us uncover more issues and articulate the problems better. The translator's real-world experience gave us a much clearer picture of the pain points in the current Glossary workflow and we subsequently worked through those issues in the weeks that followed.

A bump in the road

Progress slowed for a while as I got caught up with university exams. Balancing coursework alongside an open-source project was challenging.

Simple yet useful

The first issue I worked on after returning was a simple yet useful change that I had also proposed earlier. This involved moving the add and remove buttons to sit next to the search bar.Grouping them together created a clearer call to action, and the button placement now mirrors the Glossary editor pane, helping standardise the UI and match user expectations.

Acknowledgements

A huge thank you to my mentor, Finley Watson, for his constant guidance, patience, and thoughtful feedback throughout this project. Thanks as well to the Visual Design Group and the translator community for their valuable input, and to the KDE community as a whole for being so welcoming. Contributing to software used by translators all over the world has been an incredibly rewarding experience. I look forward to continuing to give back to KDE long after SoK is complete.

Season of KDE 2026: Transforming mentorship.kde.org into a Complete Onboarding System

Advaith Sathish Kumar — Thu, 19 Mar 2026 00:00:00 +0000

Eight weeks ago I was nervously setting up a Hugo project I'd never touched before, reading through someone else's merge requests trying to understand what I was supposed to build on top of. Today, mentorship.kde.org is a meaningfully better place for anyone trying to find their way into the KDE community. That's a good feeling.

I'm Advaith, a second-year Computer Science student from India. This was my first time contributing to open source and I couldn't have picked a better place to start than KDE.

The project

My task for Season of KDE 2026 was to transform mentorship.kde.org into a proper onboarding system for new contributors. The foundation was already there thanks to @drowsywings's GSoC 2025 work, but several pages had placeholder content, buttons went nowhere, and there was no real sense of flow.

I know this because I was that confused visitor. I found this project by experiencing the problem it was trying to solve, which made working on it feel genuinely worthwhile.

I worked alongside my co-contributor Aryan Rai. Aryan handled the /programs and /resources pages, while I focused on the homepage and the /mentees showcase. Splitting things up early was one of the better decisions we made. It kept us from stepping on each other's work and meant we could move independently for most of the program.

What got built

The homepage work was mostly about making things actually work the way they were supposed to: routing buttons to real pages, filling in content that had been sitting as placeholders, making the news section feel like actual news. A lot of it sounds simple when described but the details add up fast.

The /mentees page was the more interesting challenge. It went from being essentially empty to having real data, pagination, and client-side filtering by year, program, and technology. The filtering was originally a stretch goal but I'm glad it made it in.

One decision that took more thought than I expected was how to store the mentee data. I went back and forth between grouping mentees into cohort files (one file per year/program) versus individual Markdown files per mentee. The grouped approach is simpler to manage at first, but individual files make filtering far more straightforward, as Hugo can use front matter fields like year, program, and technology directly as filter parameters without any external code. That made the choice clear.

My mentors Anish Tak and Paul Brown were genuinely great to work with. Paul introduced us to the project and set the direction early on and Anish carried that through the whole program by hosting bi-weekly meets, reviewing all our MRs, and always being available when we we were stuck. I'm really grateful to both of them for making this such a good first experience in open source.

What I take away

The biggest thing I learned isn't a technical skill, it's how to work inside something that already exists. Reading a codebase you didn't write, making changes that fit the patterns already there, coordinating with someone else so your work doesn't clash with theirs. These things don't come up much when you're building projects on your own, and SoK taught me that in a way no tutorial could. I came in knowing how to write code. I left knowing how to write code that other people have to maintain.

I also just really enjoyed it. The KDE community is welcoming in a way that makes you want to stick around, and I intend to.

What's next

There's still work to be done on mentorship.kde.org. The pathway navigator deserves more attention, not all previous mentee data has been added and there's always more mentee data to add, as new program cycles wrap up. I'd like to be part of it.

If you're a student sitting on the fence about contributing, mentorship.kde.org (and in the future join.kde.org) exists to help you take that step. Hopefully it's a little easier to navigate now :)

Season of KDE 2026 - Untangling Scripty's File Paths

Aviral Singh — Sat, 14 Mar 2026 00:00:00 +0000

Hi everyone, Aviral here :)

I have been a past contributor to the KDE ecosystem for a few projects like Okular and Spectacle. KDE was the first organisation I ever worked with in my open source journey and now I am very excited to share the update of my Season of KDE 2026 project.

Over the past few months, I worked on KDE localization infrastructure with a focus on Scripty along with my partner Keshav Nanda, improving how source file paths are recorded for translators.

Scripty supports translation workflows across the very large KDE ecosystem. During this project, a lot of fixes were shipped to Scripty and validation was run across more than 600 projects, which made it possible to test improvements at real KDE scale and confirm that the results are dependable.

Why paths matter

For those unfamiliar, Scripty is the backbone of KDE's localization pipeline. It handles the extraction of translatable strings from source code into .pot files, which are then translated by our amazing community.

Historically, some extraction scripts generated absolute paths or inconsistent relative paths. My mentor, Finley Watson, originally initiated the effort to fix this in MR 90. Without full project relative paths, we ended up with "ambiguous" references in PO files that didn't clearly point to a single source file within a repository. This makes it harder for translators to find context without confident reliance on these references.

Why this work mattered

We discovered the main issue was not missing files (at least for 99+% of the projects). The real problem was path ambiguity.

In parts of the extraction pipeline, source references were sometimes recorded as file basenames or as paths that were not consistently project relative, which made references ambiguous in repositories with duplicate file names. Loads of modern KDE repositories often contain many files with the same name (T-T).

For translators, this creates friction in daily work:

Source navigation in tools such as Lokalize becomes less reliable
Context gets confusing and unreliable when similar file names exist across multiple components
Name collisions make it harder to trust where a string truly comes from

What was improved

Building on the direction already present in the project, I have focused on making path handling consistent and easier to validate.

Normalization and wrappers

To fix this systematically across l10n-scripty, I implemented a set of sanitization wrappers. These extraction wrappers were added and/or improved so source references are kept in project relative form in generated output:

kde_xgettext
kde_extractrc
kde_extractattr

This helps ensure each reference points to a precise location inside a repository.

Metainfo extraction flow

The metainfo extraction path handling was updated so references are resolved in a project relative way rather than relying on short file name matching. This improves clarity for AppStream and related metadata sources too.

Validation improvements

validate_paths.sh -> the prime path verifier script, was strengthened to check not only missing files but also ambiguous references caused by duplicate file names in different directories. This greatly assisted in debugging and understanding where the issues stem from.

Verification results

A full extraction and validation cycle was run in a controlled Docker environment across 600 plus (all) projects. The latest results showed clean and correct path resolution in most projects with just a dozen edge case ambiguities and missing paths not fixed by current improved wrappers.

Although this might be a good enough fix, it isn't complete - the endgame remains.

Remaining work

There are several key areas on the checklist like:

Completing the coverage for the remaining fixable projects by hardening the metainfo extraction logic for complex projects.
Communicating with the community regarding the fixes done by me. As I have still not made an actual MR, there is a great chance that this fix isn't optimised and might have some oversights.
Finalizing the validate_paths.sh suite along with my mentor for integration into CI to prevent path regressions.
Getting the fix verified locally by both my mentor and my mentee partner.

Final thoughts

This project has been a wonderful learning journey through the infrastructure that quietly powers localization for KDE. It was deeply meaningful to contribute improvements that make translator workflows clearer, faster, and more trustworthy.

A big thank you to my mentor, Finley Watson, for thoughtful guidance and constant support throughout the project. Thank you as well to everyone in the KDE community who reviewed ideas, shared feedback, and helped move this work forward.

I have grown in this season with more confidence, more curiosity, and even more appreciation for the people behind free software infrastructure. I am proud that this work would help translators do their best work with better context and fewer obstacles, and I am genuinely excited to keep contributing to KDE.

Happy translating 💙

Follow progress and contribute on KDE Invent and join us in making software more accessible for people everywhere.

Making Plasma Setup More Mobile-Friendly: A SoK'26 Midterm Update

Onat Ribar — Thu, 12 Mar 2026 00:00:00 +0000

Hey everyone! I'm Onat, and I'm a bit past the halfway mark of my Season of KDE 2026 journey. Here's what I've been working on!

For reference, here are some relevant links:

Project proposal
Status report of progress thus far
Project repositories of plasma-setup and plasma-workspace

The project: Plasma Setup

Plasma Setup is the wizard that greets you on a fresh KDE install and walks you through account creation and basic system configuration. When I started, it was very much built with desktop screens in mind, and this shows when you try to run it on a phone.

The project is about making Plasma Setup work properly across tablets and mobile phones running Plasma Mobile, without breaking the expected behaviour of Plasma on desktop. My work so far has been focused on UI and UX, making it adaptive with Kirigami.

Another area of interest was a dependency issue, in which Plasma Setup currently pulls in kcm_keyboard from plasma-desktop, which was awkward for mobile systems. Due to time constraints and priorities, we haven't pursued this yet, but I will make sure to comment on it in my next blog post!

What I've done so far

The first couple of weeks were mostly about getting ready: setting up VMs running both KDE Desktop and Plasma Mobile spins, reading through the codebases of plasma-setup and plasma-mobile, figuring out just how tightly coupled the kcm_keyboard dependency actually is, as well as refreshing my knowledge of QML/Kirigami and testing the GUI to spot any troublesome areas.

One early relief: Plasma Setup already runs on Plasma Mobile without crashing! But "runs" and "looks good" are very different things, and there were plenty of layout issues to address.

From weeks 3 through 7, the main deliverables were:

General fixes for overlapping, overflowing, and misaligned components.
Fixed wallpapers not showing in narrow layouts.
Expanded the wizard overlay to fill the screen on mobile.
Reworked the Time and Date page. The existing OpenStreetMaps map widget was too fiddly for touchscreens to navigate, so I replaced it with a clean region and timezone dropdown pair. This touched plasma-workspace as well as plasma-setup.
Disabled auto-capitalize and autocorrect on username and hostname fields, which are annoying on a phone keyboard.
Hid the landing screen buttons on mobile during wizard navigation to prevent accidental taps.
Endless rounds of testing and reverting changes that didn't make the cut.

There was also a lot of investigative work early on: checking for tight coupling, testing across virtualized Plasma Desktop and Plasma Mobile environments, and verifying behaviour on different CPU architectures. Not exactly glamorous but it was necessary!

One thing that really improved my productivity later on: I'd been avoiding the nested Wayland compositor for development because of this warning in the plasma-setup readme file:

"It is not recommended to install this on your system — you should use a virtual machine instead. Installing this on real hardware will leave behind files not trivially uninstallable and could leave your system in a non-function state."

That warning genuinely spooked me, and I stayed in VMs longer than I needed to. They're safe, but iterating on UI components in a VM was inconvenient and frustrating. My mentor pointed me toward kde-builder and running the applications on a nested Wayland compositor, which upon adoption really sped things up and built my confidence. I wish I'd made the switch sooner!

What hasn't gone so well

Not everything went to plan, but that's expected in a project like this.

The virtual keyboard situation is still on hold. How Plasma Setup should interact with on-screen keyboards is a bit of an open question, and I've put that aside to focus on the layout work first.

The dependency side of things (decoupling kcm_keyboard) is also not started yet; it's been pushed to the later weeks of the project as a side objective, and not only am I running out of time, but it's the part I'm most uncertain about. Refactoring something that touches both plasma-desktop and plasma-workspace without introducing regressions is going to need careful testing. Whether this module should be separated is a different concern as well. I will have more to say about this in my final post.

What's next

The remaining weeks will focus on final UI polishing based on feedback and getting MRs across the line. A well-polished Plasma Setup on mobile would be a meaningful step for Plasma Mobile as a whole; first impressions matter, and the setup wizard is literally the first thing a new user sees.

Special thanks to my mentor Kristen a.k.a. Merritt for their guidance. The regular check-ins and assistance outside of that have made a real difference for keeping things on track.

Cheers!

[SoK 2026] Halfway update: Appium Testing in Lokalize

Vishesh Srivastava — Sun, 08 Mar 2026 00:00:00 +0000

Hey there! I'm Vishesh Srivastava, and we're at the halfway mark of my SoK 2026 project — writing Appium-based UI tests for Lokalize. I was a bit late for the halfway mark, but we're still on track.

So what's Lokalize?

It's KDE's translation tool — the app that translators use to work with PO files and manage translation. It does its job well but it had zero UI tests. None. My job this SoK is to fix that.

The starting days (January)

My first task was Bug 514468 — where copyright year strings in PO headers would be very long like 2006, 2010, 2011, 2012, 2013, 2014, 2015, 2017, 2018, 2019, 2020, 2021 instead of the more concise 2006, 2010-2015, 2017-2021.

I was asked to write a failing test first. So I added a simplifyYearString placeholder function, wrote a unit test that expects the collapsed range output, and marked it with QEXPECT_FAIL since the actual implementation was going to be done by someone else. It was updated to expect to pass when the bug was fixed.

More importantly, this got me comfortable with KDE's setup, kde-builder, and how the testing framework works.

The main work: Appium tests (February – March)

This is where the real fun began. Lokalize had absolutely no Appium setup, so everything was built from the ground up.

First steps

My first tests were very simple. simple_open.py literally just opens Lokalize and closes it. That's the whole test. file_open.py was the next step: open the app, click File, click Open, and confirm the dialog shows up. Not much but you have to crawl before you can walk.

A bug I encountered

Here's something I found: Appium finds UI elements through accessibility properties, and Lokalize's editor text fields didn't have any (found using accessibilityinspector). So my test scripts were essentially blind — they could see menus and buttons but couldn't interact with the actual editor. I had to edit editorview.cpp to add object names and accessible names to the widgets to actually get Appium to see them.

Other KDE apps with Appium tests (Dolphin, KCalc) already had these, but nobody had needed them in Lokalize before. These were my reference for writing the code.

The workflow test (the one I'm actually proud of)

workflowtest.py is the test that simulates what a translator would actually do:

Open a .po file with two untranslated entries
Type a translation into the target field
Hit "Approve and Go Next"
Do the same for the second entry
Check if the editor tab UI was updated successfully
Check that the status bar says Not ready: 0 — meaning everything's translated
Save the file

Below is a demo of this working:

It's a proper end-to-end test.

Integrating with CMake

To make it so that these tests run along with all other tests with kde-builder --run-tests, I added a CMakeLists.txt for the appiumtests directory and added it into the project's build system behind a BUILD_APPIUM_TESTS option:

kde-builder --run-tests lokalize --no-include-dependencies --no-src --cmake-options="-DBUILD_APPIUM_TESTS=ON"

Now the tests integrate with the Appium tests just like they do in other KDE apps.

Next steps

Writing failing tests for bugs
Edge case tests

Final thoughts (for now)

It's been a enjoyable experience and many thanks to Finley Watson for offering great help along the way.

Halfway there. Let's see what happens next.

Season of KDE 2026 - Fixing the Glossary in Lokalize (Midterm)

Jaimukund Bhan — Sun, 08 Mar 2026 00:00:00 +0000

Greetings to the KDE community!

My name is Jaimukund Bhan and I have been working on Lokalize, the l10n tool used to translate KDE software, for Season of KDE 2026. Specifically, I have been fixing the Glossary - which is a collection of frequently used words linked to keyboard shortcuts for quick access while translating.

The following are the changes I have made during the first half of SoK, while learning a lot about developing with the Qt Framework and on KDE software.

Creating & Saving the Glossary file

First and foremost, the Glossary file had to exist! At the time, I found out that the file would not load or allow entries to the glossary, because it wasn’t opened inside the function. Crisis was averted when the code for opening the files was added, but now came the saving functionality. After a long, long (but fruitful) discussion with my mentor, I finalized the file saving logic to trap the user into setting a valid glossary file path for their project. This meant the user had to ensure that they had permission for the directory in which they meant to save the glossary file and should specify an existing file path. In case the user had entered something invalid, this change would return the dialog box back, pre-filled with a default valid path. I got comfortable with a few Qt features and learned a lot about the user’s workflow through this task.

Autosaving the Glossary File

Now that the glossary file could be saved, a feature request was made for autosaving the glossary file. At the time, the only way to save the glossary file was by the keyboard shortcut (Ctrl+S) or when the glossary tab was closed and the user was prompted to save/discard their changes. To autosave the glossary file, I had to identify when and how the file needed to be saved. This time, I found a relic hiding in the codebase (AuxTextEdit, the KTextEdit I had to override), which was exactly what I needed to catch when the user stopped editing the Definition section of a term in the Glossary tab. Now the file would be saved whenever the user added/deleted terms or stopped editing. I also unearthed another feature which was not working correctly, although this will be covered in the next part.

Removing the Restore function

Less code is good code. This change was just removing a feature not a lot of users had a need for, and clearing that up would make it much easier to maintain the codebase. The Glossary tab had a button to restore the glossary file from disk, which was meant as a way to reset all the unsaved changes made to the glossary file. But with all the new features made for autosaving, it did not make sense to keep it anymore.

Showing the first visible entry in Editor

Two bugs I found were how the Glossary editor would not clear the editor when all the terms were deleted from the file and that the Subject field would be pre-selected with a term from the combo box, when no actual term was selected if the app started on the Glossary tab. I added the clause to clear the editor whenever all the terms were deleted, and selected the first entry whenever the app started on the Glossary tab.

Acknowledgements

A huge thank you to my mentor, Finley Watson, for being super patient with all the discussions and changes I made, and to the KDE Community for being so welcoming! I’d recently switched to using Linux with Plasma and the biggest reason for applying was to learn how to effectively contribute to KDE software. I’ve truly enjoyed this journey so far, and I hope to keep contributing to the KDE community long after this project is complete.

Mid-SoK Blog

Navya Sai Sadu — Wed, 04 Mar 2026 00:00:00 +0000

I'm half-way through the Season of KDE 2026 and wanted to share the journey so far.

I had subscribed to the kde-soc mailing list after I returned from IndiaFOSS'25, where I met KDE contributors who really encouraged me to join the community and told me that one can always learn while building. The first step, always, is to start. Then I got carried away with life until I saw "call to action" in my mailbox in January. It was about SoK'26. I had then recently set up Kubuntu and was in awe about what people can build out of passion and by collaborating with others. I felt mentorship was the way to get started. I explored the projects and found Task-3 under Lokalize as something that I can contribute to while learning new skills- programming in CPP, debugging, and exploring an old repo.

Here's everything i did before the season officialy began.

Before Proposal

I installed ==Lokalize== and reproduced the bug.
Cloned the repo. Used grep to find “Approve and go next” in codebase. Turned out EditorTab::gotoNextFuzzyUntr() is the origin of bug. I thought about "Approve and go prev" and tried that. It was buggy too!
Wrote proposal

After Proposal

kde-builder failed due to missing libraries. So after lot of fixes, i did ubuntu update to 25.10(has qt6). *Created a test branch and added debug log in forementioned method.

Before 23rd

Got myself acquainted with Kate.
Fidgeted around files to understand architecture.

Got to know about

qDebug()
why use .h and .cpp files
LSP

The weekly status reports contain links to supoorting documents, commits and MRs.

Week 1

Spent more time understanding the repo, the files,classes and methods which were involved in the bug using debug logs, grep and manual look-over.
Wrote a few comments to document better.
Had an introductory call, was nice to know the contributors.

Week 2

Researched past commit to understand the intent of navigational shortcuts.
Added SPDX license headers( did not know it was being actively developed in GSOC too). Aided Kumud by sending an email to the KDE i18n mailing list regarding the cyclic traversal on entries for keyboard shortcuts in the Translation Units View. Typically, KDE applications don't use that, as followed from the replies and was not needed.
Had a group call for understanding rebase but i still mess up sometimes.

Week 3

While Kumud's implementation addressed gotoNextFuzzyUntr(), analyzed their approach to generalise it to make it work for gotoPrevFuzzyyUntr() and added a parameter to move in either direction for which a new Enum was used instead of magic numbers(they have a name for it T-T). I could see magic numbers used previously in the code and do get it why it isn't preferred.

Week 4

Continued with the week-3's work

Week 5

Worked on fixing other navigational shortcuts in editortab.cpp which implied generalising the function furthermore to take another parameter for entry state. StackOverflow is a saviour(Of course, after my mentor). Throughtout this time, it felt as if things were unravelling themselves to me. New bugs were found and worked upon. Looking back, I mostly improvised upon Kumud's solution but still got to learn a lot on the way.

Week 6

Will work on other bugs identified on the way or scout for new ones! See if I make past this which was primarily the task for SoK.

[SoK 2026] Midterm update for 'Automating promo data collection' task

CJ Nguyen — Wed, 18 Feb 2026 00:00:00 +0000

Hey all! I'm CJ and I'm checking in with a midterm update on the Season of KDE task of automating data collection for the KDE promotional team.

The first term of the two for this Season of KDE task has mostly been a learning experience of what does and doesn't work when it comes to scraping data from the web, laying down our toolset and approach to data collection.

Three subtasks have resulted:

Create a script that collects follower and post counts from several websites housing KDE's social media accounts
Create a script that processes information from the Reddit Insights page for the KDE subreddit
Create a script automating the evaluation of articles discussing KDE tools

The first two of those are mostly completed while the last one is in its research and planning phase. Both finished subtasks came with their own sets of challenges, techniques and tools that I'll detail separately.

Follower and post counts scraper

This is a script I discussed in my first blog post that scrapes follower and post counts from X (formerly known as Twitter), Mastodon, Bluesky, and Threads. The major updates to this script made since then are that it employs a more user and server-friendly usage method and that we've tackled a few issues that came up outside of the script's scraping. On the usage side I've added command-line arguments and an expectation for a JSON file containing the links to scrub from. This makes swapping out social media links easy as well as adding options for scaling up configuration of the script if any further development is needed.

At the point of writing the logic of the script has held up well but the data format we were outputting to, Open Document Format (ODF), wasn't friendly for our specific usage, which is something I touched on in that first blog post. In the end we decided the tools that interface with ODF were too unwieldy to work with from an automation and programmatic standpoint so we're looking into alternatives at the moment. One promising solution is KDE's LabPlot which has a good looking (but experimental) Python API and is FOSS. For now I've set the script up to output to a user-friendly JSON file until we resolve what tool will be leveraged for data analysis in the end.

Another issue came from the input-side of the script in the X/Twitter scraping portion. Many public Nitter instances implement bot-prevention I was unaware of that triggered on an attempted headless server run of the script. With that making simpler scraping methods difficult and also paying respect to those instances' desire not to be botted, I've decided to spin up our own local Nitter instance on the server which is running the script. Now scraping X/Twitter comes much more easily and with a lot less risk of failure.

KDE subreddit Insights scraper

Since that first week we've added another task, being the creation of a script that can add up the weekly influx of new visitors, unique page views, and members of the KDE subreddit utilizing the subreddit's Insight page. This script mostly challenged our ability to automate the login process for Reddit as the usual methods are prevented by browser verification tools.

Reddit implements some version of reCAPTCHA that utilizes a form of invisible reCAPTCHA on their login page. The method of implementation changes based off which version they use, but in the end a score grading the likelihood of a user being a bot or a human is returned to the website upon login. This means that simple HTTP requests are likely not enough to get the job done and that a level of interaction supplied using a browser automation framework is needed to handle the login process.

To that end, we chose to leverage the long-standing Selenium web browser automation framework. Selenium, and many browser-automation frameworks like it, works by launching a full-featured web browser to run its automated tasks. This introduces problems in running these scripts on a headless server but greatly simplifies bot-prevention thwarting and the loading of any JavaScript-sensitive page elements.

With Selenium automating our login process, the only challenge left was to process the HTML data retrieved. Reddit Insights presents its information in the form of bar charts that visualize the daily page views, unique visitors, and subscribers to a subreddit. Some small analysis of the page source revealed that the daily data populating the bar charts are stored with millisecond UNIX timestamp representations of those days. Using BeautifulSoup, it was very easy for me to grab that daily data using those timestamps and sum up the totals needed for our script.

The main challenge this script presents now is how we can get it running on a weekly basis in a headless server. The UI component is non-negotiable so the solution will very likely come in the form of server configuration.

Smaller updates

Investigated automation of NextCloud data uploads
Researched how to schedule scripts to run on an interval using systemd unit files
Wrote technical documentation on the purpose and usage of both scripts developed at the point of writing
Researched various alternative packages for performing HTTP requests and browser automation tasks

Future

Since the last two subtasks are complete logic-wise outside of any future issues we run into, a new one has been assigned as part of the data collection automation task. The KDE promo team collects various articles about KDE and software related to it and evaluates the contents of those articles as they relate to KDE and how they view whichever KDE tool they discuss. This evaluation process is performed manually which takes up time, so I've been tasked with developing some method of analyzing these articles in an automated fashion.

Along with that new subtask, solving the issues of running browser automation software on a server and what data evaluation software we'll target will greatly benefit us by expanding our options for deploying scripts made in this task and making their data immediately useful for the KDE promo team.

Lessons learned

It's been a lot of fun to tackle the first two tasks. I've had to pull from past experience with APIs, HTML, and HTTP that have been rotting in deeper parts of my brain as well as learn much more about how modern, full-featured websites deploy those tools. I'm a bit anxious about the problem of server deployment since I want these scripts to be as useful and maintainable as possible for the KDE promotion team, but I'm confident we'll find a solution and I'm sure it will feel very rewarding to solve.

Concerning the new subtask, this assignment is a departure from the first two and it's very likely a light and local AI/machine learning method will be looped into this process. That makes it exciting to tackle since it's so different from the last couple of subtasks and incorporates an entirely separate emerging field. I'm very much looking forward to rounding my skills with the new challenges this subtask presents.

Season of KDE 2026: My journey with Marknote

Siddharth Chopra — Sat, 14 Feb 2026 00:00:00 +0000

Hey everyone!

I am Siddharth Chopra, a second year engineering student at the Indian Institute of Technology, Roorkee. I'm really excited to be working on Marknote as a part of the Season of KDE program this year, under the mentorship of Carl Schawn.

Marknote, as it is aptly named, is KDE's own markdown based note taking app. The aim of my project is to improve Marknote by adding the much requested source mode, alongside other enhancements.

Progress so far

3 weeks into the project, I have been successful in adding a working source mode functionality to the editor. When source mode is activated, the contents of the source markdown file are allowed to be edited directly, instead of showing the rendered markdown. This is incredibly useful, in cases where the user needs manual control over the contents of the note, or in case there is some glitch in the rendering (which unfortunately still happens often).

Demo Video

Technical Roadmap & Challenges

The main editor of Marknote comes from the file EditPage.qml. As part of my initial approach, I added a global property here to check if source mode was enabled, and then conditionally changed components of this editor. Although this worked, but it brought along some of its own issues. First of all it made the code unnecessarily complex. It also meant that components like the formatting bar now needed to be repurposed to work with source mode, which is a challenge in itself.

So, my mentor suggested to move the raw editor into a new file, to keep the code maintainable. This led to the original EditPage being split into RichEditPage and RawEditPage. Similarly, the respective backends were also split in two, as the needs of both the editors are significantly distinct.

Additionally, I had to consider specially the source mode for images. Because when loaded, image URL's are not kept intact, instead they are replaced with a hash, that maps to the image in memory. Also, the editor internally uses html for rendering images, which I also had to convert back to markdown for source mode.

And someone who is not a designer by any means, deciding the form and placement of the mode toggle button was in itself a mini lesson in UI design ;) Initially I went with a toggle switch. But when I shared that for feedback, I learnt that a checkable button is the ideal UI element here.

Future Plans

My proposal mentions features apart from the source mode, which I plan to complete. While working on the current feature, I noticed multiple bugs in the app, which I intend to fix as well.

Overall experience

It has been a great experience working with the KDE community, and really exciting to be able to contribute to an app that so many users around the world use every day! I would also like to express my gratitude towards my mentor, for being there for whatever issue I faced!

Season of KDE 2026: Week 1 Progress for Automating Promo Data Collection

CJ Nguyen — Sun, 01 Feb 2026 00:00:00 +0000

Hi all! I'm CJ, and I'm participating in Season of KDE 2026 by automating portions of the data collection for the KDE promo team. This post is an update on the work I've done in the first week of SoK.

My mentor gave me a light task to help me get set up and familiarize myself with the tools I'll be using for the rest of the project. The task was to automate the population of a spreadsheet that tracks follower and post counts for X (formerly known as Twitter), Mastodon, BlueSky, and Threads.

The spreadsheet takes the follower and post counts of some of KDE's social media platforms and makes calculations based off that data. Important things to note:

data from the sites is entered manually
there are a lot of styles and formulas in the sheet

Fetching Account Data

Grabbing data was mostly no trouble. Mastodon and BlueSky were especially easy to work with. They have a public and well documented API that lets people collect all kinds of data in human-readable formats. One particular endpoint from both sources output account information, including follower and post counts, for a given account in neat JSON files (BlueSky, Mastodon). All it took were GET requests to these endpoints and it was smooth sailing.

X and Threads proved a bit more finnicky. Both of their APIs limit access to much of their functionality usually meaning webscraping methods are the most accessible for grabbing public account data. Threads shows users' follower counts out directly on an account's landing page, so processing a GET request to the URL of KDE's Threads account made it easy to grab. The problem is that there seems to be no direct way to grab the post count either through their API or with webscraping methods. For now, we've chosen to leave that be and circle back when I explore Threads more in the future. X presents a similar problem but there is an open-source frontend alternative named Nitter, instances of which lay all the stats information out in the open. The reliability of this method depends on public Nitter instances being available so it may be worth coming back around to this in a later part of the project, but for now it's a viable solution for getting follower and post counts.

Inputting the Data Into the Spreadsheet

With the data all fetched, all that was left is to add that data to the ODF spreadsheet. I had this down as the easy part of the task but in the end it wasn't so simple. The two major Python packages I found that can interpret and write ODF files: Pandas and pyexcel. Both of these have no problem reading data from the files, but when it comes to saving they don't preserve some elements of the spreadsheet. In the end we went the simple route which is to save the data to a separate ODF file using one of the Python-ODF interfaces and import that into the data sheet. This took a little finagling with formulas to get things working without popping errors into cells the sheet, but in the end we have an output ODF spreadsheet file containing the required data and the original spreadsheet with all the calculations pulling that data into its formulas, removing any requirement of a human interfacing with this portion of data collection.

Learned Lessons

I feel like this week's task was a great first step into data collection automation. It was challenging without being too difficult to make progress on and forced me to explore different avenues for gathering data. On the confidence side, getting a (mostly) successful task out the gate helped me feel more comfortable with the tools and processes that will likely appear throughout the entirety of my SoK experience. Things will scale up from here on out though so I'm also keeping myself in check.

From what I understand some of the most difficult parts of automated data collection come through having to interface with Javascript and not getting banned, both of which I've yet to come face-to-face with in any substantial capacity so far. Along with that I've face unexpected problems, such as the issue with modifying ODF files and that some websites don't play as well with certain browsers, which I don't have an easy way to test for yet. With these in mind I'm trying to tread lightly and be diligent with research and good practice as I continue on.