1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
|
+++
date = 2024-09-18T21:16:12+02:00
title = "KDE Plasma 6 and two bugs"
[taxonomies]
tags = ["bugs", "plasma"]
[extra]
related = []
+++
For the last couple of months I have been running [sway](https://swaywm.org/) on
my main desktop system after having been forced away from
[hikari](https://hub.darcs.net/raichoo/hikari) because of its practically halted
development and incompatibility with newer
[wlroots](https://gitlab.freedesktop.org/wlroots/wlroots/) versions.
I never felt completely satisfied with it and the whole experience was rather
joyless, so about a week ago I decided to give [KDE Plasma
6](https://kde.org/announcements/megarelease/6/) a try after a surprisingly
decent experience on the [KDE Neon](https://neon.kde.org/) live image.
Whilst undoubtedly greater in its complexity and code size than sway, to me
Plasma 6 seems like one of the last decent desktop environments still remaining.
It's incredibly customisable (but still comes with good defaults), looks nice
out of the box, and most importantly seems to care about providing a nicely
integrated and featureful experience. This even includes a companion app on
Android, [KDE Connect](https://kdeconnect.kde.org/). It remains to be seen
whether it will fully convince me in the long run, but for now I am very
satisfied with it.
{{ img(path="kde-plasma.png", alt="A picture of the KDE Plasma 6 desktop
environment, with a browser window, a terminal, and an instance of Dolphin, a
file manager.", caption="KDE Plasma 6 with a few windows open") }}
This last week was mostly spent learning about the desktop environment and
setting everything up exactly how I want it to be, but there were two notable
bugs to squash as well.
The first one reared its ugly head once I enabled backwards-compatibility with
Qt5-based apps. I have a couple of such apps still, most prominently
[Mumble](https://www.mumble.info/) and [Quassel IRC](https://quassel-irc.org/).
Once the latter was built against the KFramework libraries, no more
notifications were shown...
Fixing this ended up taking about two days, most of which were spent discovering
exactly how
[KNotifications](https://api.kde.org/frameworks/knotifications/html/index.html)
work. KDE provides apps with a tighter integration to the notification service,
allowing users to specify which types of notifications to show, and how.
Applications specify their notifications by shipping an `<app>.notifyrc` file.
KDE ties this file to the application by matching its base name to the name
given to the application (usually through a call to
`QCoreApplication::applicationName` or when creating
[KAboutData](https://api.kde.org/frameworks/kcoreaddons/html/classKAboutData.html)).
It turns out that Quassel had recently been
[patched](https://github.com/quassel/quassel/commit/020c163421691fa37330826df92ac0a248721290)
to fix an issue where desktop environments did not show its icon correctly. This
required a call to `setDesktopFileName` in `KAboutData` to make environments
aware of the connection. However, Quassel's application name was
[changed in the same commit](https://github.com/quassel/quassel/commit/020c163421691fa37330826df92ac0a248721290#diff-c72daad7d2269a2ee21584002ef1f30f4415335358a6c6f7e7296d3290a51a91R117),
severing its link with the name given through its `quassel.notifyrc` file. This
seems to have been done in addition to the `setDesktopFileName` call and was not
necessary to solve the issue the commit was trying to address.
I prepared a [pull request](https://github.com/quassel/quassel/pull/619) fixing
this issue by reverting part of the offending commit.
{{ img(path="notification.png", width=412, format="png", alt="A picture of a
notification from Quassel IRC saying 'yay for notifications'.", caption="Glad to
have these back") }}
The second bug I randomly came across whilst perusing `journalctl` and seeing
the following error from [Dolphin](https://apps.kde.org/dolphin/), KDE's file
manager:
QString(View)::contains(): called on an invalid QRegularExpression object
(pattern is '\A(?:file:///home/wolf/[Z-A]/?)\z')
Seeing this immediately made me wonder whether Dolphin plugs a URL straight into
a regular expression without escaping it, and the answer, of course,
[is yes](https://invent.kde.org/system/dolphin/-/blob/5c069471fccc41051b967be69f95655b3e0b73ef/src/dolphinviewcontainer.cpp#L554-557).
I spent most of today's afternoon hunting this issue down and preparing a [merge
request](https://invent.kde.org/system/dolphin/-/merge_requests/831) that fixes
it in an elegant way.
|
