For a couple of weeks now I have been using Plasma’s built-in weather report
system. It supports various different sources for weather observations and
forecasts, one of which is my preferred service, Deutscher
Wetterdienst (DWD). Once the report location is set up, Plasma
displays the current conditions in the tray - clicking on it gives you an
overview of the next 7 days.
I’ve been quite pleased with this; a quick glance at the icon tells you
everything you need to know and the forecast is only one click away. It even
supports DWD’s official warning system. There is one small problem with the tray
icon, however. See if you can spot it:
That’s right, I couldn’t have possibly taken this image given this post’s
timestamp is before 23:57! Good catch. More importantly, however, the icon is
showing the sun when realistically it’s going to be dark outside. This has been
annoying me to no end, so a couple of days ago I decided to fix it.
Since Plasma already comes with weather icons suited for night-time use, I
really only needed a reliable way to tell when to switch to those. After some
spelunking in DWD’s twoAPIs, I
found that the latter contains sunrise and sunset times for its forecast
endpoint. The weather report system was already using this endpoint to fetch
forecast data, so it was a rather simple lookup of two values in the API and
then comparing the current observation time to those.
So, after some preparatory work to make date parsing more robust, I sent a
merge
request
upstream which was promptly approved and merged. Finally I could rest easy after
dusk, not having to worry about a sun chasing me around.
There’s some more stuff that could be improved in the DWD backend, like station
availability. As far as I can tell, when using the open API, DWD limits access
to weather data depending on whether or not they have the full rights to it. The
API might therefore simply deny access to a station even though it is listed in
in the official index.
There’s no way to find out which station is accessible except to try them all.
To get around this, the DWD backend uses a very simple
heuristic
based on the first digit of the station ID, since all stations starting with 0
or 1 seem to work. However, this ignores a number of other, still accessible,
stations.
I’m planning to look into this further, hopefully finding a better solution so
that users of the DWD backend have access to as many stations as possible.
Today, prompted by a question on the #kde channel on
libera, I looked into how Plasma handles its registry of
recently used folders and documents. Turns out it’s way more complicated than I
first thought.
The question specifically was whether there was a way to programmatically add
files to Okular’s recently opened documents, so
that’s where I started looking. I was already aware that some apps like Okular
and Gwenview keep their own history
independently from the system, and I quickly found out that Okular simply keeps
a list of recently opened files in its configuration file ~/.config/okularrc
of all places.
This got me thinking. Maybe it would be a decent idea to instead have Okular
interact with the system history directly. For that I first had to understand
how exactly it worked.
The Standard
The way that I thought Plasma’s system history worked was through
freedesktop.org’s Desktop Bookmark
Specification
. The gist of it is that applications read from and write to a well-known file
$XDG_DATA_DIR/recently-used.xbel. Indeed that file existed and it even
contained the relevant entry:
Okular then seemed to write to both recently-used.xbel and okularrc when
instead it could simply access the former directly and keep all history entries
out of its configuration file. What’s more, having Okular forget its history
would only clear the entry in okularrc.
The most prominent place in which system history is displayed is in
Dolphin’s “Recent Files” panel. After clearing
Okular’s history entry I still found the document there, so it seemed obvious to
assume that it uses recently-used.xbel. Dolphin lets you forget specific
entries from history, so I confidently deleted the entry there and re-checked
the file. Weirdly, the entry was still there even though Dolphin didn’t show it
anymore…
It was time to delve into the code. Untangling all the interconnected parts took
a while, but after a good 10 minutes, I finally knew what was going on: There
was another history provider.
The Other “Standard”
This is where I have to mention KDE’s activities. Activities are a
somewhatill-defined
concept but they basically boil down to the idea of providing a different
computing space depending on what you are doing at the moment. In reality the
most obvious user-facing activity feature in Plasma 6 is that you can customize
your task bar and wallpaper per activity so you could consider it an extension
of virtual desktops - applications open on one activity won’t be shown once you
switch to another.
Crucially, however, the activity subsystem
kactivitymanagerd is
also used to manage recently opened files. I imagine the plan is (or was) to
enable tracking file history per activity, but in all my testing I could not get
this to work - history seems to be global. So what this essentially means is
that an application might, and most probably will:
Keep its own history, most of the time through
KRecentFilesAction
and a simplistic history implementation. The data here is exclusively accessed
by the application itself.
Keep its history in the desktop-agnostic recently-used.xbel file. In KDE’s
case this usually does not happen in the application itself but instead through
its KIO framework. Other desktop
systems might read and display this data, but KDE seems to be write-only:
history is appended, but never shown to the user.
Keep its history in an SQLite database under
~/.local/share/kactivitymanagerd, managed by a daemon. This is what you see in
Dolphin and what you can manage under “Recent Files” in the system settings.
It also means that if you want to tweak history management, forget documents or
folders, or turn the thing(s) off, you have to look in a multitude of places:
If the application provides a setting to manage or disable its own history,
use that. If that’s not available (like in Okular) you’re out of luck. Disabling
an application’s own history will not impact the other two history providers -
you will still see recent files in Dolphin and elsewhere in the system.
There’s been
ongoingwork to
streamline management of entries in recently-used.xbel, spurred by this
bug. You may also use the
undocumented UseRecent, MaxEntries, and IgnoreHiddenoptions
read from ~/.config/kdeglobals.
Tweak kactivitymanagerd history in system settings under “Recent Files”.
Forgetting History
With all this in mind my immediate reaction is to shy away from the whole
endeavour to have Okular interface with the system history - there’s too many
moving parts, some of which aren’t even yet well-defined on KDE’s side.
For whatever reason I’ve been uncovering software bugs at an unprecedented rate
in the past 10 days. This is by no means a bad thing, I enjoy hunting down and
fixing bugs, but it does mean that the additional overhead of drafting a post
about each bug becomes a bit too much. So instead here’s a quick overview - the
linked patches and merge requests will have more information, if you are
interested.
Trash size calculation in KIO
I noticed this one pretty much right after starting to use
Dolphin but did not end up looking into it
until quite a bit later: when displaying the size of the items in the trash, the
application would always show 0 bytes. This would also cause the automated
cleanup of items to fail - Dolphin simply believed that the trash was empty.
KDE uses the KIO framework to provide
management of the trash. A recent
commit
had changed the construction of a
QDirIterator in a way that would
make it ignore all items when iterating over the trash directory. Thankfully the
fix was straightforward and it was merged
quickly.
git-shortlog(1) segfaults outside of a git repository
This one I uncovered as I was writing a small script to give me an overview of
commit authors in all the git repositories I had cloned locally. I was happily
scanning through my source directory using the
--author
flag for git-shortlog(1) to generate this, fully expecting git to complain
about the few non-git directories I had. Instead of complaints, however, I got a
segfault.
Turns out that a change back in
May stopped setting SHA1 as the
default object hash. This was done to progress the slow-moving transition to
stronger hash functions but
inadvertently broke git-shortlog(1) whose argument parsing machinery expected
a default hash algorithm to be set. I sent a
patch
upstream.
An infinite loop in plasmashell
I regularly use the
Activities
functionality in Plasma 6 and switch through my activities using Plasma’s
built-in activity manager. A couple of days ago I managed to make plasmashell,
the provider for Plasma’s desktop and task bar, freeze - I had hit the “up
arrow” key in the activity filter text box when there were no results visible.
This was perfectly reproducible, so I went to investigate.
The cause of the issue was a do-while construct not handling a specific sentinel
value, making it loop infinitely. For this one I also opened a merge
request
upstream.
For the last couple of months I have been running sway on
my main desktop system after having been forced away from
hikari because of its practically halted
development and incompatibility with newer
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 a try after a surprisingly
decent experience on the KDE Neon 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. It remains to be seen
whether it will fully convince me in the long run, but for now I am very
satisfied with it.
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 and Quassel IRC.
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
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).
It turns out that Quassel had recently been
patched
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,
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 fixing
this issue by reverting part of the offending commit.
The second bug I randomly came across whilst perusing journalctl and seeing
the following error from 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.
I spent most of today’s afternoon hunting this issue down and preparing a merge
request that fixes
it in an elegant way.