{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifa64wxe5caz4grzgzdxru4ohjvpowaiei475tppwuc4kbu2ymaje",
    "uri": "at://did:plc:6dmfe46c76jjenq3kaxc5eds/app.bsky.feed.post/3mhwa36ururw2"
  },
  "path": "/2026/03/25/season-of-kde-2026-wrapping-up/",
  "publishedAt": "2026-03-25T00:00:00.000Z",
  "site": "https://blogs.kde.org",
  "tags": [
    "previous blog",
    "Carl Schwan"
  ],
  "textContent": "Greetings!\n\nAs we're nearing the end of SoK 2026, I am writing to share my experience and progress since my previous blog.\n\nThe 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.\n\n### Technical update and challenges faced\n\nTill 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.\n\nFirstly, 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.\n\nThe 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.\n\nSimilarly 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.\n\nA 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!\n\nApart from this, I also added a spell-checking capability to the editor, using Sonnet.\n\n### Demo\n\n### Learning and experience\n\nI 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!\n\nI learnt how a professional application is different from a hobby project, and how the quality and rigour of work should reflect that.\n\nIt 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!\n\nSoK 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!",
  "title": "Season of KDE 2026: Wrapping up"
}