Now it’s full circle, a whole year of KDE has started again! This is a bit of a smaller post, for two reasons. First I have begun stripping out of the less interesting stuff I do - like really boring bugfixes, whoop. Secondly, I’ll be busy at $work for the next few months and I don’t know what my schedule is going to look like yet.

Plasma

[Bugfix] Finished up Aleix’s QML API for Layer Shell Qt, and exposing it via a proper installable QML module. This is only useful for developers. [6.0]

[Feature] Working on adding a simple tablet tester to the Drawing Tablet KCM, modeled after a certain KDE application’s own. [6.1]

[Feature] Also working on adding a configurable pen pressure curve, allowing artists to tweak the pen pressure curve of their pen or eraser. It will have two fully-controllable points of articulation and two partially-fixed points for adjusting the thresholds. [6.1]

[Bugfix] Fix camera-video-symbolic being coloured wrong, when using dark color schemes like Breeze Dark. I also fixed document-send-symbolic using the wrong icon at 16x size. [6.0]

[Bugfix] I added more common keywords for Screen Locking settings. [6.1]

[Bugfix] Removed some Wayland-techno terminology from Drawing Tablet settings, “Pen buttons” should be called that. [6.1]

KWin

[Feature] I opened a merge request for the necessary things on the KWin side needed for configuring pen pressure. [6.1]

Tokodon

The next major release is upon us, so I started doing some last-minute bugfixing. This is also when we branch, so I can start breaking strings again! I hope to start adding new features next month.

[Feature] There has been an excess of bug reports of people using Tokodon without a way to store passwords. And if you use Tokodon on Android, it would be helpful to enable notifications but we have no way to ask you yet. To solve both of these problems (and possibly more in the future) I added a new initial setup flow. Said system will also prevent you from starting Tokodon without a way to save account data, hopefully preventing more of these bug reports in the future! [28.04?]

[Feature] Tokodon now warns you when you’re viewing a private post, noting that this affects replies in an unusual way. I want to add more tips about Mastodon and ActivityPub-isms to work around these issues that are out of our hands. [28.04?]

And now some smaller stuff:

• [Bugfix] The display of the home timeline name now makes more sense on desktop, preventing some duplicate text. [28.04?]
• [Bugfix] Don’t show empty biography cards on profiles. [24.02]
• [Bugfix] Visually separate the active account in the switcher. [24.02]
• [Bugfix] Improve the “login error” message with icons, and better help text. [24.02]
• [Bugfix] Fixed numerous alignment and padding issues everywhere. [24.02]

PlasmaTube

Same as Tokodon, I’ve been doing some more bug-fixing in preparation for the February mega-release and will continue to do so.

• [Bugfix] Added a proper video thumbnail placeholder, instead of loading videos being displayed as empty space. [24.02]

• [Bugfix] Added a way to go directly to the channel page from a video item. This stops having to load the video, wait for it to finish and then navigate to the channel from the player. [24.02]

• [Bugfix] Use the standard ItemDelegate component everywhere now. It should look and feel like expected. And it makes my life as a developer way better! [28.04?]

• [Feature] Added a share button to the video player. [28.04?]

• [Feature] Added a date chip to the video player for checking the published date. [28.04?]

Kongress

[Bugfix] Fixed two instances of broken section headers. [24.02]

NeoChat

[Bugfix] The room list now hides subtitle text when there is none, slightly improving the alignment. [24.02]

[Bugfix] Improved the look of the search message dialog, like I did for the Explore Rooms dialog before. [24.02]

Frameworks

[Bugfix] Fixed symbolic icons being wrongly matched with a non-symbolic fallback, even if a symbolic version of said icon exists. This notably will fix lots of wrongly coloured icons in the system tray. [6.0]

[Bugfix] Small improvements to the Kirigami platform plugin error message. This means that it’s easier to debug this issue when you give us logs. [6.0]

Websites

I spent some time trying to put in some small improvements to our Human Interface Guidelines, many of them are merged now but still need to take care of the rest.

• Don’t mention devicePixelRatio at all, remove mentions of Plasma Units that are no longer relevant in 6..
• Fix capitalization and shorten wording of 3rd-party theme note.
• Remove some lingering mentions of PC2.
• Move the “Generate Media” page underneath the “Contribute” category, since it’s only useful for that.
• Don’t put the mobile bullet point so far down the page.
• Remove the useless and incomplete KCMGrid page.
• Mention the ellipses unicode character in the label writing docs.
• Make a note that disabled context menu items should be avoided in most circumstances.

Smaller stuff

• Updated Konvex to Qt6, I still plan on sitting down with it and getting it ready for review.
• Participated in the AMA today.
• Rebased and integrated lots of fixes that were stalling due to lack of an author around to rebase.

I hope to see you next month with more KDE stuff!

This is the final update on the migration of the Craft jobs from Binary Factory to KDE's GitLab. Since the last blog the last missing pieces have been put in place.

We now build a KF6 runtime which is used for the nightly flatpaks of many of the apps that will be part of KDE's Megarelease 6.

Moreover, additionally to signing the sideload APPX packages (see previous blog) the Windows Craft jobs now also sign the NSIS (.exe) installers and all binaries included in the installers. This completes the port of the Windows Craft jobs from Binary Factory to KDE's GitLab.

Now is the time to add GitLab jobs to your project for builds previously run on Binary Factory. The 24.02 release branch has been cleared for using our signing and publishing services, so that you can prepare builds of AppImages, Flatpaks, Android packages, macOS installers, and Windows installers for the 24.02 release of your project, or any other release if you release independent of KDE Gear. To enable those builds add one or more of the following GitLab templates to your project's .gitlab-ci.yml.

• craft-appimage.yml (Qt 5), craft-appimage-qt6.yml (Qt 6)
• flatpak.yml
• craft-android-apks.yml (Qt 5), craft-android-qt6-apks.yml (Qt 6)
• craft-macos-arm64.yml (Qt 5), craft-macos-arm64-qt6.yml (Qt 6)
• craft-macos-x86-64.yml (Qt 5), craft-macos-x86-64-qt6.yml (Qt 6)
• craft-windows-x86-64.yml (Qt 5), craft-windows-x86-64-qt6.yml (Qt 6)
• craft-windows-mingw64.yml (Qt 5), craft-windows-mingw64-qt6.yml (Qt 6)

What's Next

Next I'll work on making it possible to create and publish Android Application Bundles (AAB) additionally to APKs for your Android apps. Application Bundles contain the binaries for all supported architectures in a single package (instead of multiple different APKs for each architecture). This packaging format is required for new applications published on Google Play.

This a lazy and anti-rant post… I want to shine a light on the fantastic KDE software that I use daily. You can do similar things with GNOME and whatever else, but that’s for someone else to write. I have some bias because I have contributed to several of these applications, but that doesn’t detract from the point that I depend on them daily.

I check my work and personal mail using KMail. I’m one of those lucky few that checks my mail from two IMAP-compliant servers, so I steer clear from Outlook/GMail. I keep track of tasks, events and meetings using Merkuro. I can keep tabs on my calendar since the time applet is synced thanks to Akonadi. I really enjoy and use the integration between these Akonadi applications, such as accepting invitations to meetings which are automatically recorded into my calendar.

My work uses Rocket.Chat, and I use Ruqola for interacting with that:

Even when not working, I still use KDE software! One of them is drawing, and I use Krita for that (which is a great application in general, you should use it!) It’s completely replaced Procreate and Clip Studio Paint which I used before. I really like it’s integrated brush engines and default brush set, along with all of it’s built-in functionality like animation support. I even use Krita when sketching on-the-go or in bed now instead of Procreate, since my Lenovo Yoga runs Linux and KDE Plasma. When I edit videos, my program of choice is Kdenlive (which is a great application in general, you should use it!) It does everything I want it to do, honestly I have very little trouble with it but my needs are minimal.

My primary chat platform is Matrix, so of course I use NeoChat as my preferred client everywhere I can. I chose Mastodon as my Twitter-replacement, and I use Tokodon so much that I don’t even open up their web interface anymore! The less I have to run in the browser the better, in my opinion.

There’s also lots of small utilities that I use, such as Spectacle for screenshots and quick screen recordings. I use Kate for all of my text editing, such as this post right now! Gwenview is my image viewer of choice too. Of course I use Okular for reading the occasional PDF. Can’t forget about Okteta when I’m trying to dissect some binary file.

I even use KDE applications for consuming media, too. I use PlasmaTube to feed my YouTube addiction. I like to put videos in picture-in-picture and even added that to the next release, meaning I can stop using the web interface for Invidious. I have started listening to some podcasts, and have been using Kasts for those. I elarned recently that it even can sync via NextCloud!

Upcoming

Here’s some software I recently learned about, and want to start using soon:

• Accessibility Inspector, which is a KDE-based alternative to GNOME’s Accerciser.
• Codevis, a code visualization program, I used it once before but I need to try it again.
• Fielding, a REST API client. I plan to expand it’s features further so I don’t have to depend on Insomina.
• Powerplant, something to help keep your plants. I only have one plant to keep right now, so this is the perfect time to learn how to use it!

Hope this sheds some light on my favorite applications, and gives you ideas for using them! I enjoy how fast these applications are, and how integrated and nice they all look together. I couldn’t go over every single one, but maybe I can expand in the future.

When running Linux software and encountering a crash, and you make a bug report about it (thank you!), you may be asked for backtraces and debug symbols.

And if you're not developer you may wonder what in the heck are those?

I wanted to open up this topic a bit, but if you want more technical in-depth look into these things, internet is full of info. :)

This is more a guide for any common user who encounters this situation and what they can do to get these mystical backtraces and symbols and magic to the devs.

Backtrace

When developers ask for a backtrace, they're basically asking "what are the steps that caused this crash to happen?" Debugger software can show this really nicely, line by line. However without correct debug symbols, the backtrace can be meaningless.

But first, how do you get a backtrace of something?

On systems with systemd installed, you often have a terminal tool called coredumpctl. This tool can list many crashes you have had with software. When you see something say "segmentation fault, core dumped", this is the tool that can show you those core dumps.

So, here's a few ways to use it!

How to see all my crashes (coredumps)

Just type coredumpctl in terminal and a list opens. It shows you a lot of information and last the app name.

How to open a specific coredump in a debugger

First, check from the plain coredumpctl list the coredump you want to check out. Easiest way to deduce it is to check the date and time. After that, there's something called PID number, for example 12345. You can close the list by pressing q and then type coredumpctl debug 12345.

This will often open GDB, where you can type bt for it to start printing the backtrace. You can then copy that backtrace. But there's IMO easier way.

Can I just get the backtrace automatically in a file..?

If you only want the latest coredump of the app that crashed on you, then print the backtrace in a text file that you can just send to devs, here's a oneliner to run in terminal:

coredumpctl debug APP_NAME_HERE -A "-ex bt -ex quit" |& tee backtrace.txt

You can also use the PID shown earlier in place of the app name, if you want some specific coredump.

The above command will open the coredump in a debugger, then run bt command, then quit, and it will write it all down in a file called backtrace.txt that you can share with developers.

As always when using debugging and logging features, check the file for possible personal data! It's very unlikely to have anything personal data, BUT it's still a good practice to check it!

Here's a small snippet from a backtrace I have for Kate text editor:

#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0)
    at pthread_kill.c:44
...
#18 0x00007f5653fbcdb9 in parse_file
    (table=table@entry=0x19d5a60, file=file@entry=0x19c8590, file_name=file_name@entry=0x7f5618001590 "/usr/share/X11/locale/en_US.UTF-8/Compose") at ../src/compose/parser.c:749
#19 0x00007f5653fc5ce0 in xkb_compose_table_new_from_locale
    (ctx=0x1b0cc80, locale=0x18773d0 "en_IE.UTF-8", flags=<optimized out>) at ../src/compose/table.c:217
#20 0x00007f565138a506 in QtWaylandClient::QWaylandInputContext::ensureInitialized (this=0x36e63c0)
    at /usr/src/debug/qt6-qtwayland-6.6.0-1.fc39.x86_64/src/client/qwaylandinputcontext.cpp:228
#21 QtWaylandClient::QWaylandInputContext::ensureInitialized (this=0x36e63c0)
    at /usr/src/debug/qt6-qtwayland-6.6.0-1.fc39.x86_64/src/client/qwaylandinputcontext.cpp:214
#22 QtWaylandClient::QWaylandInputContext::filterEvent (this=0x36e63c0, event=0x7ffd27940c50)
    at /usr/src/debug/qt6-qtwayland-6.6.0-1.fc39.x86_64/src/client/qwaylandinputcontext.cpp:252
...

The first number is the step where we are. Step #0 is where the app crashes. The last step is where the application starts running. Keep in mind though that even the app crashes at #0 that may be just the computer handling the crash, instead of the actual culprit. The culprit for the crash can be anywhere in the backtrace. So you have to do some detective work if you want to figure it out. Often crashes happen when some code execution path goes in unexpected route, and the program is not prepared for that.

Remember that you will, however, need proper debug symbols for this to be useful! We'll check that out in the next chapter.

Debug symbols

Debug symbols are something that tells the developer using debugger software, like GDB, what is going on and where. Without debugging symbols the debugger can only show the developer more obfuscated data.

I find this easier to show with an example:

Without debug symbols, this is what the developer sees when reading the backtrace:

0x00007f7e9e29d4e8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib64/libQt5Core.so.5

Or even worse case scenario, where the debugger can't read what's going on but only can see the "mangled" names, it can look like this:

_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE

Now, those are not very helpful. At least the first example tells what file the error is happening in, but it doesn't really tell where. And the second example is just very difficult to understand what's going on. You don't even see what file it is.

With correct debug symbols installed however, this is what the developer sees:

QCoreApplication::notifyInternal2(QObject*, QEvent*) (receiver=0x7fe88c001620, event=0x7fe888002c20) at kernel/qcoreapplication.cpp:1064

As you can see, it shows the file and line. This is super helpful since developers can just open the file in this location and start mulling it over. No need to guess what line it may have happened, it's right there!

So, where to get the debug symbols?

Every distro has it's own way, but KDE wiki has an excellent list of most common operating systems and how to get debug symbols for them: https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports

As always, double check with your distros official documentation how to proceed. But the above link is a good starting point!

But basically, your package manager should have them. If not, you will have to build the app yourself with debug symbols enabled, which is definitely not ideal.. If the above list does not have your distro/OS, you may have to ask the maintainers of your distro/OS for help with getting the debug symbols installed.

Wait, which ones do I download?!

Usually the ones for the app that is crashing. Sometimes you may also need include the libraries the app is using.

There is no real direct answer this, but at the very least, get debug symbols for the app. If developers need more, they will ask you to install the other ones too.

You can uninstall the debug symbols after you're done, but that's up to you.

Thanks for reading!

I hope this has been useful! I especially hope the terminal "oneliner" command mentioned above for printing backtraces quickly into a file is useful for you!

Happy backtracing! :)

Why KMines? #

Minesweeper is a tragically underrated puzzle game. While I recall examining the mysterious array of gray squares as a child, it wasn’t until adulthood that I took the time to learn the rules of the game. Despite my late start, however, I still count minesweeper as a classic. These days, good minesweeper clones are hard to come by. I settled on GNOME’s Mines for a while, but as the look of GTK applications on my QT-based KDE Plasma Desktop sets my teeth on edge, I ditched it for KMines in short order. While I enjoyed the game, I found the themes shipped with KMines a bit dated, so I thought I’d make my own.

The Drama #

I didn’t quite know what I was getting into when I started working on my themes. I had expected there’d be a simple way to add themes through the KMines settings menu, or by dropping an SVG somewhere in your file-system. If only it were so simple. Adding a theme to KMines requires setting up a full-on KDE development environment, re-compiling KMines from source each time you want to test it, and then, of course, submitting a merge request to the git repository. Thanks to the help of some very patient souls in various KDE Matrix channels, I was able to work through all of this, but I found the process so tricky that I submited a second merge request, this time to the repository for develop.kde.org, for a page documenting the process. Now I realise that some developers out there are going to read through this and wonder if I was dropped on my head as an infant, but in my defense, when it comes to software development, I’m a humble designer and Jamstack web developer. This is all very new to me, and I was expecting a much more streamlined process for what I saw as simple visual tweaks.

Why High Contrast #

When submitting my initial design, a KDE contributor who had been helping me via Matrix pointed out that they found the theme difficult to parse visually as the contrast was quite low. I hadn’t considered contrast ratios here, my thinking being that I didn’t need to; I was just making one theme among many, after all, and users could choose any theme that worked best for them. After some consideration, however, it dawned on me that my theme would likely be the only modern-looking theme in the release, so it would be ideal if it were as accessible as possible. With this in mind, thanks to the feedback of one helpful individual, instead of one pretty but low contrast theme, I decided to make two modern high contrast themes, one light and one dark, targeting the WCAG AAA standard for contrast.

Coming in Plasma 6! #

With thanks to those KDE contributors who helped make it happen, the merge request containing these two themes scraped by the skin of its teeth past the closing door of a feature-freeze and will be available with Plasma 6 this February!

Improving the qcolor-from-literal Clazy check

For all of you who don’t know, Clazy is a clang compiler plugin that adds checks for Qt semantics. I have it as my default compiler, because it gives me useful hints when writing or working with preexisting code. Recently, I decided to give working on the project a try! One bigger contribution of mine was to the qcolor-from-literal check, which is a performance optimization. A QColor object has different constructors, this check is about the string constructor. It may accept standardized colors like “lightblue”, but also color patterns. Those can have different formats, but all provide an RGB value and optionally transparency. Having Qt parse this as a string causes performance overhead compared to alternatives.

Fixits for RGB/RGBA patterns

When using a color pattern like “#123” or “#112233”, you may simply replace the string parameter with an integer providing the same value. Rather than getting a generic warning about using this other constructor, a more specific warning with a replacement text (called fixit) is emitted.

testf4ile.cpp:92:16: warning: The QColor ctor taking RGB int value is cheaper than one taking string literals [-Wclazy-qcolor-from-literal]
        QColor("#123");
               ^~~~~~
               0x112233
testfile.cpp:93:16: warning: The QColor ctor taking RGB int value is cheaper than one taking string literals [-Wclazy-qcolor-from-lite
        QColor("#112233");
               ^~~~~~~~~
               0x112233

In case a transparency parameter is specified, the fixit and message are adjusted:

testfile.cpp:92:16: warning: The QColor ctor taking ints is cheaper than one taking string literals [-Wclazy-qcolor-from-literal]
        QColor("#9931363b");
               ^~~~~~~~~~~
               0x31, 0x36, 0x3b, 0x99

Warnings for invalid color patterns

Next to providing fixits for more optimized code, the check now verifies that the provided pattern is valid regarding the length and contained characters. Without this addition, an invalid pattern would be silently ignored or cause an improper fixit to be suggested.

.../qcolor-from-literal/main.cpp:21:28: warning: Pattern length does not match any supported one by QColor, check the documentation [-Wclazy-qcolor-from-literal]
    QColor invalidPattern1("#0000011112222");
                           ^
.../qcolor-from-literal/main.cpp:22:28: warning: QColor pattern may only contain hexadecimal digits [-Wclazy-qcolor-from-literal]
    QColor invalidPattern2("#G00011112222");

Fixing a misleading warning for more precise patterns

In case a “#RRRGGGBBB” or “#RRRRGGGGBBBB” pattern is used, the message would previously suggest using the constructor taking ints. This would however result in an invalid QColor, because the range from 0-255 is exceeded. QRgba64 should be used instead, which provides higher precision.

I hope you find this new or rather improved feature of Clazy useful! I utilized the fixits in Kirigami, see https://invent.kde.org/frameworks/kirigami/-/commit/8e4a5fb30cc014cfc7abd9c58bf3b5f27f468168. Doing the change manually in Kirigami would have been way faster, but less fun. Also, we wouldn’t have ended up with better tooling :)

Ruqola 2.1 Beta (2.0.81) is available for packaging and testing.

Ruqola is a chat app for Rocket.chat. This beta release will build with the current release candidate of KDE Frameworks 6 and KTextAddons allowing distros to start to move away from Qt 5.

URL: https://download.kde.org/unstable/ruqola/
SHA256: 2c4135c08acc31f846561b488aa24f1558d7533b502f9ba305be579d43f81b73

Signed by E0A3EB202F8E57528E13E72FD7574483BB57B18D Jonathan Esk-Riddell jr@jriddell.org
https://jriddell.org/esk-riddell.gpg

Disclaimer: I am not one of KDE's masterminds or spokespersons. I am a mere bystander with few unimportant commits. I follow KDE's ecosystem and other developments in the free software world. In the following, I share some thoughts and my personal opinion.

Talks about new programming languages

We already have a new programming language!

Problems with C++ remain

What can be done?

Discuss our future

It’s a pleasure to be on the OpenUK New Year’s Honours list for 2024. There’s some impressive names on there such as Richard Hughes of Packagekit and other projects at Red Hat, Colin Watson who was at Ubuntu with me and I see is now freelance, Mike McQuaid was previously of KDE but is now trying a startup with Mac packager Workbrew for Homebrew.

OpenUK run various activities for open tech in UK countries and KDE currently needs some more helpers for a stall at their State of Open Con in London on Feb 6 and 7 February, if you can help do get in touch.

KDE’s 6th releases will happen next month bringing with it the refresh of code and people that a new major version number can bring, I think KDE’s software in the coming year will continue to impress.

My life fell apart after some family loss last year so I’ve run away to the end of the world at Finesterre in Galicia in Spain for now, let me know if you’re in the area.

Lithuania and Latvia

Caused by a small discussion about how it is difficult to get from Berlin to Riga by train, and in direct consequence a quick look at how the official app for trains in Latvia finds its connections, I added support for it in KDE Itinerary. KDE Itinerary is KDE’s travel planning app.

After I understood how it works, adding support for new data sources seemed pretty doable, so I directly moved on to do the same for trains in Lithuania as well.

As a result of this, it is now possible to travel from Berlin to Riga with Itinerary and continue further with the local trains there:

The connection is still far from good, but fear I can’t fix that in software.

What still does not work, is directly searching from Berlin to Riga, as that depends on having a single data source that has data on the entire route to find it. So it is necessary to split the route and search for the parts yourself.

Why you can’t always find a route even though there is one

The main data source for Itinerary in Europe is the API of the “Deutsche Bahn”, the main railway operator in Germany. Its API also has data for neighbouring countries, and even beyond that. According to Jon Worth their data comes from UIC Merits, which is a common system that railway operators can submit their routes to. However that probably comes with high costs, so many smaller operators like the ones in Latvia and Lithuania don’t do that. For that reason there is no such single data source that can route for example from Berlin to Riga.

What most of the operators in Europe do however, is publish schedule data in a common format (GTFS). What is missing so far, is a single service that can route on all of the available data and has an API that we can use. Setting something like this up would require a bit of community and hosting resources, but I am hopeful that we can have something like this in the future.

In the meantime, it already helps to fill in the missing countries one by one, so at least local users can already find their routes in Itinerary, and for Interrail and other cross border travel, people can at least patch routes together.

More countries

The next country I worked on was Montenegro. The reason for that is that it is close to the area that the DB API can still give results for, and also still has useful train services. Getting their API to work well was a bit more difficult though, as it doesn’t provide some of the information that Itinerary usually depends on. For example coordinates for stations. Those are needed to select where to search for trains going from a station. Luckily, exporting the list of stations and their coordinates from OpenStreetMap was relatively easy and provided me with all the data I needed.

Thanks to that Itinerary can now even show the route on a map properly.

Now only the API for Serbia is missing to actually connect to the part of the network DB knows about.

The new backends are not yet included in any release, but you can already find them in the nightly builds. Be aware that the nightly builds have switched to Qt6 and KF6 faily recently, which means there are still a few rough edges and small bugs in the UI.

On Linux, you can use the nightly flatpak:

flatpak install https://cdn.kde.org/flatpak/itinerary-nightly/org.kde.itinerary.flatpakref

On Android, the usual KDE Nightly F-Droid repository has up to date builds.