You can contribute to KDE with non-C++ code :: rabbiticTranslator
rabbitictranslator.com
Not everything made by KDE uses C++. This is probably obvious to some people, but it’s worth mentioning nevertheless. And I don’t mean this as just “well duh, KDE uses QtQuick which is written with C++ and QML”. I also don’t mean this as “well duh, Qt has a lot of bindings to other languages”. I mean explicitly “KDE has tools written primarily in certain languages and specialized formats”. Note that I said “specialized formats”.

I always see:

  • people being told they can contribute to KDE with C++/QML
  • people being told they can contribute to KDE without code

But I don’t often see:

  • people being told that they can contribute to KDE with code that is not C++

I like C++, QML, and even CMake, but you might not be interested in them or you might just not be willing to spend time learning another language, and that’s perfectly fine.

In this blog post I list a few KDE projects that you might not know about that might be written in your preferred language or in a specialized format you have expertise or interest in.

By far, the most popular programming language actively used in KDE other than the expected languages is Python.

We also have stuff that would interest sysadmins (containers), packagers (snap/flatpak) and web developers.

  • onlinepersona@programming.devEnglish
    22·
    5 months ago

    Is there documentation on the dbus interfaces that’s easily searchable? For example, I can’t find out something as simple as listing all the windows or even setting a window property. org.kde.KWin doesn’t seem to have it, nor does org.kde.plasmashell. Nor do I know what value to pass when it’s a "QString` but clearly an enum.

    Anti Commercial-AI license

    • felsiq
      2·
      5 months ago

      I remember being able to figure out a solution with the kwin docs and dfeet for introspection, but it was a while ago and my memory is less than stellar lol. I ended up running all my window-related logic in the kwin script (js) and just using python+dbus to see if the script had been injected and do it if not. If you go the same route (though the python is unnecessary this way if you aren’t using it for something else, like running one of the windows you wanna manipulate) the workspace global variable stores all windows in stackingOrder, so looping through that list (for (window of workspace.stackingOrder) {…}) is an easy way to check each window. I definitely remember docs on the workspace/windows part, but tbh I think I just introspected with the jsconsole.log and the log kwin prints it to (journalctl maybe?). Sorry I don’t remember more about the process, I got into the kwin scripting for all of an hour cuz of the Wayland regression of not being able to control your own window’s size/position in qt so it was a bit of a hack fix I haven’t had to think about since.