This post is a Call To Action™ for those with the ability to set up a Plasma development environment and an interest in code hygiene. Plasma 6 development is in full swing, and we have an opportunity to make a difference by doing some relatively easy code porting. Read on if this intrigues you!
History
First, some background: For many years, Plasma has maintained forks of various Kirigami bits whose only purpose in life was to get colors from the active Plasma theme, rather than the systemwide color scheme. For example, Heading exists in both Kirigami, and also PlasmaExtras; they both do the same thing and are implemented the same way under the hood, but the PlasmaExtras version gets its colors from the active Plasma theme. If it didn’t, then when you used the Breeze Twilight theme, the text colors on your dark Plasma widgets would come from the systemwide light color scheme, be inappropriately dark, and you wouldn’t be able to see them.
Maintaining forks with minimal differences worked but wasn’t ideal, as they could–and sometimes did–drift subtly out of sync and cause maintenance headaches. It would be better if we could use the Kirigami versions in Plasma and have them substitute Plasma colors automatically. As of today, core Plasma developer Marco Martin has done just that for Plasma 6 with two patches!
Ultimately this will let us get rid of the forks, at least for components that don’t do any SVG styling (that’s planned too, but not ready yet).
How you can help
So with that out of the way, here’s how you can help: throughout Plasma (i.e., all repos in the Plasma group), submit merge requests with the following changes:
| Replace this… | …with this: |
|---|---|
PlasmaExtras.Heading | Kirigami.Heading (Example merge request) |
PlasmaCore.Theme.smallestFont | Kirigami.Theme.smallFont |
PlasmaCore.Theme.NormalColorGroup | Kirigami.Theme.Window |
PlasmaCore.Theme.mSize([default font]).height | Kirigami.Units.gridUnit |
PlasmaCore.Theme.[anything else] | Kirigami.Theme.[the same thing] |
PlasmaCore.ColorScope.colorGroup | Kirigami.Theme.colorSet |
PlasmaCore.ColorScope.inherit | Kirigami.Theme.inherit |
PlasmaCore.Units.largeSpacing | Kirigami.Units.gridUnit (due to a bug where PlasmaCore largeSpacing was too big; we need to change it to a Kirigami gridUnit to keep the expected sizing) |
PlasmaCore.Units.devicePixelRatio | 1 |
PlasmaCore.Units.roundtoIconSize([height of the default font]) | Kirigami.Units.iconSizes.sizeForLabels |
PlasmaCore.Units.roundtoIconSize([some integer value]) | Kirigami.Units.iconSizes.roundedIconSize([the same thing]) |
PlasmaCore.Units.[anything else] | Kirigami.Units.[the same thing] |
Quirks to be aware of
Make sure your master branch is up to date before you start looking at code, and also check to see if anyone else has already submitted a merge request. You don’t want to do work for nothing!
If any file with such changes made to it doesn’t already have a line near the top that says import org.kde.kirigami 2.20 as Kirigami, add it We can’t use Kirigami stuff without importing Kirigami!
If as a result of these changes to any particular file, nothing in it is still using PlasmaExtras or PlasmaCore anymore, you can also remove those import lines at the top.
Testing
Make sure to test your changes! Apply the changes to your Plasma 6 development build and restart. Then use the Breeze Light color scheme and the Breeze Dark Plasma theme and make sure all changed text is still readable, that anything using a small font size is still doing it correctly, that colors in general look correct, and that spacings and units look correct. You want to see no visual changes at all.
In the future
Later, we’ll also be able to port forked components that internally use Plasma-specific SVG theming. For example, PlasmaExtras.PlaceholderMessage is identical to Kirigami.PlaceholderMessage but it internally contains Plasma-specific labels and buttons that use Plasma SVG theming, rather than theming from the app style. We’re planning some more code wizardry so that the Kirigami versions of these components can dynamically substitute the internal Plasma SVG themed variants when run in Plasma. This isn’t ready yet, but when it is, I’ll announce another porting opportunity for folks who enjoyed (or missed out on) this one!
Adventures in Linux and KDE 
Contributing to KDE is kinda PITA if you aren’t already deeply involved in development process.
– Setting up build environment isn’t easy because of all dependencies. It also somewhat requires to have a separate environment in form of VM/container because it would trash your main system with kde-related build stuff.
– Everything takes A LOT of disk space. KDE build folder takes up 11GiB of space and I only needed that for 2 apps.
My experience with MR wasn’t really good either. I did a simple MR that fixes text layout in KScreen 5 month ago. It didn’t get approval or rejection and basically stalling.
If that would happen with more copmplex MRs, there’s a chance someone will rewrite a component significantly so rebase won’t be an option anymore.
It’s not that every MR should be approved, but some clarity would be really appreciated so new contributors won’t feel abandoned or something like that.
LikeLike
Also, testing built apps in already working environment also not for the faint of heart. Again, mostly due to dependencies and because it’s not clear how you should run/install apps. It’s more or less not an issue for KDE Gear but for plasma components, KCM and stuff it gets really complicated.
LikeLike
There are definitely things we can do to make the setup process easier (including automatically installing needed 3rd-party dependencies), but it’s not that bad anymore IMO. And I just rewrote the documentation at https://community.kde.org/Get_Involved/development to make it simpler, too. Also you definitely do not have to use a VM because all the source code, and build products are segregated and not intermixed with your system files. The documentation makes this quite clear. But developing and testing Plasma components is just always going to be harder than testing an app, I’m afraid. Not many ways around that.
I’m sorry you didn’t have a good experience with the merge request. Was it https://invent.kde.org/plasma/kscreen/-/merge_requests/174? If so it looks like there’s an ongoing discussion and it could move forward. I don’t see that it’s waiting on us.
It’s definitely true that there aren’t enough people reviewing merge requests though. This is why I work really hard to go through new ones every day, and keep an eye on old ones that have gotten stalled. Several merge requests for this porting work were submitted in the past 12 hours and I’ve spent almost all of today reviewing them.
But there are a *lot* of open merge requests so reviewing them is practically a full-time job. It’s worth noting that anyone can review a MR, not just core contributors.
LikeLike
Honestly, that little interaction I have within KDE project isn’t bad. I wouldn’t say that I am an avid FOSS contributor, but I had way worse experience before. Bug reports also rarely left behind so that’s pretty good to, I’d say.
All in all, many people also volunteers and it won’t be fair to demand any special attention because they do stuff in their free time. And for project that big more people needed to work on things so I am not trying to be offensive. Work takes time and reviewing isn’t fun part of this. That’s just the way FOSS world is, sadly.
It’s more like these little annoyances make it harder to just spend some time on coding a hour or two in the evening because you need to deal with updating frameworks first, then fix toolchain/environment issues, yada yada yada. Then there’s no time to do actual work and you need to go to bed.
I agree that KDE itself is pretty self contained, but –initial-setup also pulls not insignificant amount of external dependencies that will thrash host system.
There’s no good way to avoid that without using self-contained host unless you build ALL 3rd party software which will take days probably.
Currently I just set up systemd-nspawn container which is basically my system but with only kde-related dependencies installed inside.
Something like that (because you can use it on any system with systemd) or docker container (will cause issues due to base image having different library versions) could make life a lot easier.
LikeLike
Thank you Nate. I will send a link to your post in some Telegram groups of developers.
LikeLike