Part-time KDE sabbatical, feedback or guidance appreciated (but no pressure)

[Jakob Petsovits]

Hi all,

If it helps, think of this email as some sort of bizarro GSoC/SoK application, with less detail perhaps, where you can only comment/advise but not reject. (In return I can't ask for a dedicated mentor, but having a preferred point of contact or two would be really nice! If any of these plans below seem worth supporting to you.)

I last contributed a little bit to KDE prior to the KDE 4.0 release, sometime prior to 2010, renaming icons to conform to the XDG spec. My energy levels were never high enough to make meaningful contributions after that in addition to full-time work. So after a number of years in proprietary software, I'm quitting my job for the time being to focus on some personal goals. This includes helping KDE (on Linux in particular) with world domination as a part-time endeavor. Reserving the right to fail of course, and to pause at any point if self-care asks for it.

In short, I'll have an estimated 6-12 months during which I'm hoping to make some improvements and/or additions to KDE, with notably less intensity than a GSoC project but with a longer time frame instead. I'd like to produce something of value that will outlive my sabbatical. I need to get some practice with modern Qt/QML and get a sense for how to use the different KDE communication channels in order to be more useful than annoying, and in order to actually connect with the community. Thankfully Joseph P.D.V.G. posted a rather neat intro email to kde-soc recently, to which I'm still subscribed (haha), so that helps with not missing the obvious basics.

In particular, I'd like to ask for feedback about how to make my development time count. What to look at, or how to approach it. Here's what I have in mind right now, feel free to steer me into a different direction if it doesn't sound ideal. Thanks in advance for any feedback, or even just taking the time to read through this wall of text.

---

Big picture plan: a two-pronged approach with time split between two separate tracks.

(1) Work on a personal pet project, a stand-alone app or plasmoid to act both as a playground with freedom to learn & experiment, but also with the goal of ending up in official KDE releases (Gear or Plasma) eventually. Safe space to tinker with if I need a break from other hard stuff.

(2) Dive into existing KDE "core" codebases for maximum impact but also to get exposure to a wider subset of the community. I was thinking it'll be a good idea to focus on semi-random bugfixing first and then see where that takes me, it might lead to a spin-off new project or new topics of interest.

I would switch back and forth between both, but within each track focus mostly on one thing at a time.

For (1), I've previously started with some UI ideas for a convergent app with combined scanning and PDF page re-ordering functionality (think PDF Arranger) at https://invent.kde.org/jpetso/marascan-concept. Frankly, Skanpage has improved a whole bunch, after painful introspection I've got to admit that it barely makes sense to start a competing app now. However, what would still make sense (imho) is to work on some of the components I had in mind, make them suitable also for Skanpage and perhaps someday in the future build my alternative mobile-friendly Kirigami app around them. Things I'd like to see are:
  (*) a pinch-zoomable multi-page canvas that allows editing functionality such as drag & drop, page cropping and placing page action buttons smartly around the page in the empty space where they don't get in the way,
  (*) grouping disorganized SANE settings into related groups so one can save and select "quality presets",
  (*) a single sidebar for either scanner options or page previews, and scanner options being close to the "Scan" button,
  (*) being able to load existing PDFs so you can also organize pages after the initial save,
  (*) crop after scan, including with perspective distortion which you get from smartphone pictures. Looks like this isn't quite sticking with "personal pet project" scope here, but also the multi-page canvas is probably the most work and that can be prototyped on its own.

An alternative to the above project might be a game launcher in the style of GNOME's new Cartridge app, but designed as a plasmoid. Cartridge shows that one can list and start games from different game launcher apps without reimplementing their Wine integrations and library management. No reason why I should have to open a separate app just for launching stuff though, when a plasmoid can put the launcher directly into a secondary "start menu" in the panel, or as desktop widget on a dedicated virtual desktop. KDE integration may furthermore provide useful stuff such as switching from regular monitor settings for productive desktop use to temporary high refresh rates, VRR, HDR (in the future), custom key/button mappings, performance overrides, and whatnot.

I'd also be interested in having something like the mouse button mapping UIs that Windows users get from their mouse manufacturer, enabling remapping of mouse buttons not just to keys but also to modify other mouse (or keyboard) behaviors while pressed. With Wayland it can be app-/window-specific too, I think. And of course it would be a good selling point that hey, *any* mouse can have all the features as opposed to being tied to the driver and manufacturer. Some changes to KWin will likely be required to power the configured mapping in practice. Ultimately this kind of configuration UI should be part of in System Settings.

I guess there are tons of options for pet projects, so far these ones seem to strike an emotional chord with me. Important if it's going to be an ongoing project.

For (2), I haven't yet prepared much but it shouldn't be hard to find bugs to fix. Nate always posts links to lists of important bugs, and Bugzilla holds many more. I may end up somewhere in the area between power consumption, window management/composition, krunner and peripherals enablement for bugs and eventually feature work. Or perhaps something less common like SDDM, Baloo or Kate. But feel free to drop a pointer if there's a need for something in Plasma/Frameworks 6 that's suffering from a lack of resources, needs more attention than fly-by contributors can spare, and could make use of a developer with decent C++ knowledge yet less experienced with today's KDE codebases.

---

Thanks for reading this far and sorry if there isn't any real question in here. I mainly wanted to say hi and see if I'm perhaps missing something substantial, in which case feedback may be useful. Or if I should watch out for particular habits/approaches/patterns to adopt or avoid. Or if you have prior art for me to look into. If not, hopefully I'll still turn out as a net benefit and you'll see me around eventually.

Located in Toronto btw and will unfortunately only be able to attend Akademy virtually this year. Is anyone else in the area too? It would be neat to come up with a semi-regular (aspiring and experienced) KDE developers meetup if there's a few people around who are now active in KDE.

Cheers!
- Jakob