<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Siddharth Chopra on KDE Blogs</title><link>https://blogs.kde.org/authors/siddharth/</link><description>Recent content in Siddharth Chopra on KDE Blogs</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Wed, 25 Mar 2026 13:34:08 +0000</lastBuildDate><atom:link href="https://blogs.kde.org/authors/siddharth/index.xml" rel="self" type="application/rss+xml"/><item><title>Season of KDE 2026: Wrapping up</title><link>https://blogs.kde.org/2026/03/25/season-of-kde-2026-wrapping-up/</link><pubDate>Wed, 25 Mar 2026 00:00:00 +0000</pubDate><author>Siddharth Chopra</author><guid>https://blogs.kde.org/2026/03/25/season-of-kde-2026-wrapping-up/</guid><description>&lt;p&gt;Greetings!&lt;/p&gt;
&lt;p&gt;As we're nearing the end of SoK 2026, I am writing to share my experience and progress since my &lt;a href="https://blogs.kde.org/2026/02/14/season-of-kde-2026-my-journey-with-marknote/"&gt;previous blog&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;h3 id="technical-update-and-challenges-faced"&gt;Technical update and challenges faced&lt;/h3&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;The fix for the C++ part seemed to be obvious: to use inheritance. So I decided to make the &lt;code&gt;RichDocumentHandler&lt;/code&gt; and &lt;code&gt;RawDocumentHandler&lt;/code&gt; inherit from a common parent, the &lt;code&gt;DocumentHandler&lt;/code&gt;. &lt;code&gt;DocumentHandler&lt;/code&gt; now contained all the common methods, significantly reducing repeated lines of code.&lt;/p&gt;
&lt;p&gt;Similarly on the QML side, I made a parent component, &lt;code&gt;EditPage&lt;/code&gt;, 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.&lt;/p&gt;
&lt;p&gt;A major issue I faced was caused by the fact that my MR essentially removed the existing &lt;code&gt;EditPage.qml&lt;/code&gt; and &lt;code&gt;documenthandler.cpp&lt;/code&gt; (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!&lt;/p&gt;
&lt;p&gt;Apart from this, I also added a spell-checking capability to the editor, using Sonnet.&lt;/p&gt;
&lt;h3 id="demo"&gt;Demo&lt;/h3&gt;

 


&lt;figure class="text-center ratio ratio-16x9" style=""&gt;
 &lt;video controls&gt;&lt;source src="%25!s%28%3cnil%3e%29vid2.webm" type="video/mp4" /&gt;&lt;/video&gt;&lt;/figure&gt;

&lt;h3 id="learning-and-experience"&gt;Learning and experience&lt;/h3&gt;
&lt;p&gt;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!&lt;/p&gt;
&lt;p&gt;I learnt how a professional application is different from a hobby project, and how the quality and rigour of work should reflect that.&lt;/p&gt;
&lt;p&gt;It was a really fun experience working with the KDE community and I'd like to thank my mentor &lt;a href="https://invent.kde.org/carlschwan"&gt;Carl Schwan&lt;/a&gt; for always being there to help!&lt;/p&gt;
&lt;p&gt;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!&lt;/p&gt;</description></item><item><title>Season of KDE 2026: My journey with Marknote</title><link>https://blogs.kde.org/2026/02/14/season-of-kde-2026-my-journey-with-marknote/</link><pubDate>Sat, 14 Feb 2026 00:00:00 +0000</pubDate><author>Siddharth Chopra</author><guid>https://blogs.kde.org/2026/02/14/season-of-kde-2026-my-journey-with-marknote/</guid><description>&lt;p&gt;Hey everyone!&lt;/p&gt;
&lt;p&gt;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 &lt;a href="https://invent.kde.org/carlschwan"&gt;Carl Schawn&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;h3 id="progress-so-far"&gt;Progress so far&lt;/h3&gt;
&lt;p&gt;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).&lt;/p&gt;
&lt;h3 id="demo-video"&gt;Demo Video&lt;/h3&gt;

 


&lt;figure class="text-center ratio ratio-16x9" style=""&gt;
 &lt;video controls&gt;&lt;source src="%25!s%28%3cnil%3e%29vid.webm" type="video/webm" /&gt;&lt;/video&gt;&lt;/figure&gt;

&lt;h3 id="technical-roadmap--challenges"&gt;Technical Roadmap &amp;amp; Challenges&lt;/h3&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;So, my mentor suggested to move the raw editor into a new file, to keep the code maintainable. This led to the original &lt;code&gt;EditPage&lt;/code&gt; being split into &lt;code&gt;RichEditPage&lt;/code&gt; and &lt;code&gt;RawEditPage&lt;/code&gt;. Similarly, the respective backends were also split in two, as the needs of both the editors are significantly distinct.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;h3 id="future-plans"&gt;Future Plans&lt;/h3&gt;
&lt;p&gt;My &lt;a href="https://invent.kde.org/teams/mentor-programs/2026/-/issues/29"&gt;proposal&lt;/a&gt; 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.&lt;/p&gt;
&lt;h3 id="overall-experience"&gt;Overall experience&lt;/h3&gt;
&lt;p&gt;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!&lt;/p&gt;</description></item></channel></rss>