Call to Action – Page 2 – Adventures in Linux and KDE

I often encourage people to submit bug reports when they complain about this or that on Reddit or comments here or wherever. This works as long as their problem is actually a bug.

But many problems are not bugs. They could be user error, a misunderstanding of the software’s scope or capabilities, a request for something impossible, a long rant about how the software sucks, or a request for help recovering the picture of their kawaii catgirl waifu that they just lost in Krita.

I’ve noticed that the more popular a product is, the worse the bug reports it tends to get. This makes sense, right? A niche product is used only by experts; a popular product gets used by 0-dots-in-computers users to whom bug trackers are weird and unfamiliar. It’s common for normal people to have difficulty describing a discrete technical problem in precise terms, or to bury the useful information in a description of their distant end goal or how the problem made them feel. Hard and jaded software developers who read such bug reports roll their eyes and cruelly wonder how their hapless users manage to plug in their coffee makers without electrocuting themselves.

But non-experts who are having problems with our software need help too! It’s just that the bug tracker isn’t the right place for it. What they need is user support.

This is where https://discuss.kde.org comes in. Discuss is full of magical people who are not only good at talking to other people, but also at understanding machines! These magicians can be the bridge between regular folks and software developers, providing technical support and filtering out problems that aren’t bugs so they never make it onto the bug tracker. They can also evaluate whether a problem is a bug and ought to be reported there.

So if you’re a happy KDE user, you can become a superhero by answering questions at https://discuss.kde.org/c/help/6! Help regular people recover their misplaced files. Explain to them that update errors in Discover are caused by their distro. If their issues seem to be real bugs, direct them to the bug tracker.

And if you’re having a problem with KDE software, and you don’t know whether it’s a bug or not, ask for help at https://discuss.kde.org/c/help/6. You’ll probably get a better response!

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!