A while ago a colleague of mine asked about our crash infrastructure in Plasma
and whether I could give some overview on it. This seems very useful to
others as well, I thought. Here I am, telling you all about it!
Our crash infrastructure is comprised of a number of different components.
KCrash: a KDE Framework performing crash interception and prepartion for handover to…
coredumpd: a systemd component performing process core collection and handover to…
Sentry: a web service and UI for tracing and presenting crashes for developers
We already looked at KCrash, coredumpd, and DrKonqi. This week it’s time to look at the final piece of the puzzle — Sentry.
Sentry
Sentry is the service we have on the developer side of a crash to manage incoming reports.
As we’ve learned in the DrKonqi post, a Sentry-specific trace created by the preamble is eventually sent off to our Sentry server. In Sentry, yet more processing happens!
Symbolication
If the user hasn’t explicitly opted into it, there usually aren’t debug symbols available on the user system. This would ordinarily render backtraces useless since they are just a bunch of memory addresses without names or references to our source code.
One of the reasons we adopted Sentry is because it can
fill in the gaps through a process called symbolication. For symbolication it essentially needs to know all the loaded libraries and can then fetch the relevant debug symbols via the various debuginfod instances out there. Once it has the debug symbols it can resolve that the address 0x2343244 is really the function int main(int argc, char **argv)
Fingerprinting
When a trace has been symbolicated it’s ready for fingerprinting. This tries to merge together the same
crash appearing in different submission into one single sentry event. Generally speaking if two submissions have the same trace frames, they are considered the same crash and merged into one event (in practice the rules are a bit more complicated).
Result
Eventually the crash event appears for us to fix.
In a future blog post, I’ll also give a more detailed guide on how to use Sentry to its full potential.
I shared this post across 7 different social media platforms, here’s how their engagement stacked up
Tags: tech, social-media, politics, fediverse
Interesting little study of engagement on various platforms. Clearly the Fediverse could do better in terms of avoiding “friendly fire”, I suspect it’s the top reason limiting its growth.
Very interesting research. Property-Based Testing made quite some progress the past few years but indeed it still needs to improve in term of usability. Looking forward to some of that research to get available in existing testing tools.
I’m not a huge fan microservice based architectures. That said the parallel done there is interesting and a good reminder that the “write programs that do one thing and do it well” quote is incomplete.
Interesting exploration on the difficulties to switch a team to XP. I’m not fully aligned with some of the fine details pointed there… That said there is a core truth that “XP is about social change” so if you mandate it as a managerial decision it can’t be XP anymore.
Bad idea: Developer experience is equivalent to productivity
Tags: tech, productivity, developer-experience
It’s indeed tempting to conflate the two (at least for marketing purposes apparently, I see you LLM vendors…). Even if tempting, developer experience is definitely not equivalent to productivity.
Most operating systems nowadays provide a feature like night light: Colors are adjusted over the course of the day to remove blue light in the evening, to potentially help you sleep1 and make your eyes more comfortable.
Linux is no different; there’s Redshift to apply this on X11 desktops, and since many years ago desktop environments also ship it built in. However, there’s always been a rather annoying problem with these implementations: None of them were color managed!
What does it actually do
On a low level, these implementations set the video cards gamma curves to multiply the red, green and blue channels of the image that’s sent to the screen.
The actual intention behind the feature though is to change the white point of the image. The white point is, as the name implies, the color that we consider to be “white”. With displays, this usually means that red, green and blue are all at full intensity. By reducing the intensity of green and blue we can change that white point to some other color.
What’s wrong then?
The scenario I described only concerns itself with white, but there are more colors on the screen… If you multiply the color channels with some factors, then they get changed as well. To show how much and why it matters, I measured how this naive implementation behaves on my laptop.
These plots are using the ICtCp color space - the white point they’re relative to is in the center of the other points, the distance to it describes saturation, and the direction compared to the center the color.
Without night light, relative to 6504K
Plasma 6.2 at 2000K, relative to 6504K
These are both relative to 6504K, but to see the result better, let’s look at it relative to their respective white points:
Without night light, relative to 6504K
Plasma 6.2 at 2000K, relative to 2000K
To put it into words, relative to white, red looks less intense (as white has become more red). Similarly, green becomes less intensely green… but it also moves a lot towards blue! Blue meanwhile is nearly in the same spot as before.
In practice, this is visible as blue staying nearly as intense as it was, and green colors on the screen get a blue tint, which is the opposite of what night light is supposed to achieve.
How to fix it
To correct this issue, we have to adapt colors to the new whitepoint during compositing. You can read up on the math here if you want, but the gist is that it estimates what color we need to show with the new whitepoint for human eyes to perceive it as similar to the original color with the original whitepoint.
If your compositor isn’t color managed, then applying this may be quite the challenge, but as KWin is already fully color managed, this didn’t take a lot of effort - we just change the colorspace of the output to use the new white point, and the renderer takes care of the rest. Let’s take a look at the results.
Without night light, relative to 6504K
Plasma 6.2 at 2000K, relative to 6504K
Plasma 6.3 at 2000K, relative to 6504K
Without night light, relative to 6504K
Plasma 6.2 at 2000K, relative to 2000K
Plasma 6.3 at 2000K, relative to 2000K
Relative to the white point, red, green and blue are now less saturated but not changed as much in color, and everything looks more like expected. To put the result in direct comparison with the naive implementation, I connected desktop PC and laptop to my monitor at the same time. On the left is Plasma 6.2, on the right Plasma 6.3:
This means that in Plasma 6.3 you can use night light without colors being wrongly shifted around, and even without sacrificing too much color accuracy2.
Caveats
Well, there’s only one caveat really: Unless your display’s native white point is 6504K, the color temperature you configure in the night light setting is a lie, even if you have an ICC profile that perfectly describes your display.
This is because instead of actually moving the white point to the configured color temperature, KWin currently offsets the whole calculation by the whitepoint of the display - so that “6500K” in the settings means “no change”, independent of the display.
I intend to fix this in future Plasma versions though, so that you can also set an absolute white point for all connected displays with a convenient setting.
Despite the common claims about it, scientific evidence for night light improving sleep is still lacking afaik ↩
Adapting colors to a different white point always loses some accuracy though; for best color management results you should still configure the whitepoint on your display instead of doing it in software ↩
If you want to keep up with the latest Kwave updates, you can now try out the nightly flatpak. It
gets published each time code is pushed to the master branch, so it may sometimes have bugs, but
also new features. To try it out, add the repository by running flatpak remote-add kwave-nightly https://cdn.kde.org/flatpak/kwave-nightly/kwave-nightly.flatpakrepo and install Kwave with flatpak install kwave-nightly org.kde.kwave. If you use Discover, go to
Settings, click Add Source and paste
https://cdn.kde.org/flatpak/kwave-nightly/kwave-nightly.flatpakrepo in to add the repo, and then
search for Kwave.
The process for publishing stable versions to Flathub has also
started. The current plan is to wait for the next
stable version (25.04) to publish Kwave on Flathub.
This is an extremely important update to our recently released KF6/Qt6 port of KPhotoAlbum!
There’s a bug in version 6.0.0 which, under some circumstances, can lead to data loss! The problem is that, during porting, the algorithm we use to escape category names to be able to use them as XML attributes broke. And we didn’t notice. This can lead to data loss when opening a database and saving it using version 6.0.0, provided the following conditions are met:
The “compressed” or “fast” XML format is used (“Choose speed over readability for the XML database file” is checked in the “Database Backend” settings)
At least one category exists whose name contains characters other than “a-z”, “A-Z”, “0-9”, “:” or “_”
In this case, all tag associations for tags from the affected category can’t be mapped correctly and are discarded when reading the datase – and lost when saving it.
I personally found this after having tagged about 400 photos using my actual photo database and later on having wondered where my “Schlagwörter” tags for the other 15,000 have gone. Happily, we have that XML format. So, with an older backup (of course, I saved the database so often that the automated backups already exceeded the maximum number and the last unaffected database backup was already gone …) and some copying and pasting in KWrite, I could recover the old tags.
Anyway, This is actually the worst case. It can’t be recovered automatically. Big sorry to everybody affected! This should not have happened. And we sincerely hope such a bug doesn’t ever slip through our fingers ever again.
However, the 6.0.1 release fixes this. So: please update right now if you already used version 6.0.0! If not, skip 6.0.0 and go directly to 6.0.1! Dear distributors:
Please remove version 6.0.0 and replace it with 6.0.1!
Other fixes
Some other bugs have also been fixed in this release:
Fix application icon on Wayland
Fix crash when video thumbnail cache contains empty files (fixes Bug #497831)
The "Configure KPhotoAlbum" menu entry is now shown again (not where it was before, but it’s there again – this alone would have justified a bugfix release ;-)
Clicking on a tag in the Viewer’s info box shows the respective tag in the browser again
When the main window is closed and the viewer is opened, it is also closed now automatically. This is what one would expect, and it also fixes crashing e.g. when the user clicks on an info box link with the main window already closed. Additionally, if the annotation dialog is open, we now also try to close it. If this doesn’t succeed (e.g. because there are pending changes and the user didn't agree to discard them) the close query is aborted.
Technically, this is not a pure bugfix release, because support for database file names other than index.xml has also been added (cf. Bug #418647). But this does not interfere with anything and does not change current behavior. So let’s also declare this as a bugfix, for “The XML database name is hard-coded and should not be” ;-)
Sorry again for all inconveniences version 6.0.0 may have caused. We sincerely hope that everybody affected by data loss can restore everything so that none of the hard work put into your photo databases is actually permanently lost.
Welcome to a new issue of "This Week in KDE Apps"! Every week we cover as much as possible of what's happening in the world of KDE apps. This week we cover the two latest weeks as, due to the holidays, there wasn't a post last week.
General changes
The convergent context menu from NeoChat was made more generic and upstreamed to Kirigami Addons. It is now used by Tokodon and Merkuro with work underway to integrate it into more apps. (Carl Schwan and Joshua Goins, Kirigami Addons 1.7.0. Link)
And, don't worry, on desktop platforms, the context menu stays the same.
Help is very much welcome to port more applications to this new component. Here are some merge requests for inspiration:
Arianna allows users to use the wheel to turn pages. (Tomaz Canabrava, 25.04.0. Link), and once again correctly remembers the current reading progress of books. (Ryan Zeigler, 25.04.0. Link)
When using languages which are typically written right-to-left, like Arabic or Hebrew, Dolphin's layout is mirrored to also go from right to left. Type dolphin --reverse in Konsole to try it out! It is an interesting experience. This week, Dolphin's details view mode finally received right-to-left support, which will show file icons on the right and folder names and details on the left. This change also includes some general improvements to resizing of columns in details view mode. (Felix Ernst, 25.04.0. Link 1, Link 2. Thanks to the European Commission and NLnet for funding this work.)
Dolphin's selection mode now also changes keyboard controls to allow easier selecting. Previously there was no reason for keyboard-only users to ever use selection mode because the controls were identical. Now, when you are selecting specific files among a list you will no longer have to fear that accidentally letting go of the Control key while moving will clear your selection! Simply go into selection mode instead, move focus with arrow keys, and press Enter to toggle the selection. (Felix Ernst, 25.04.0. Link)
Finally, Dolphin received a quick accessibility report as part of the NLNet funding, and, while some issues were found, the report noted that "overall the app is very accessible"!
You can now add paths to the PATH environment variable used by Kate, which is useful if you use LSP servers, formatters, or linters not present in your default PATH variable (Waqar Ahmed, 24.05.0. Link)
We fixed opening URLs ending with :x:y cursor information from remote URLs. (Christoph Cullmann, 24.12.1. Link), and added a file template plugin which allows you to generate files from existing templates (Kåre Särs, 25.04.0. Link)
Finally, Joshua posted a blog post on how to use Hugo with Kate on his blog.
It is now possible to manually enable and disable the network or the bluetooth backend for KDE Connect. (Rob Emery, 25.04.0. Link)
We also redesigned the welcome page of the Kirigami version of KDE Connect. (Carl Schwan, 25.04.0. Link)
On iOS, notifications for pairing a new device will be displayed in the app itself as a fallback if the app is not permitted to display notifications. (Ruixuan Tu. Link)
On Android, the application was made compatible with Android 15 (Mash Kyrielight. Link); more code was ported from Java to Kotlin (TPJ Schikhof. Link 1, link 2); we reworked the custom devices lists to show the connection status and display toast messages when trying to add a device that already exists (TPJ Schikhof. Link); and we fixed the icon colors when using a dark theme (Mash Kyrielight. Link).
Jean-Baptiste Mardelle, from the Kdenlive team, posted an update about the much-requested feature of a modern background removal tool. Good news, there are testing binaries available. For more details, consult his blog post.
Kai Uwe Broulik made avatars load asynchronously, which speeds up scrolling through the list of rooms and the timeline. (25.04.0. Link). A similar change was also done to Tokodon.
We fixed fetching some TV channels for the TV Spielfilm backend (Plata Hill, 24.12.1. Link) and it's now possible to see what is hapening on your favorite TV channels for more than the current day. (Plata Hill, 25.04.0. Link)
Plata also made numerous behind the scene changes to Telly Skout.
Third Party Apps
Supersonik
Adam Pigg released the first tagged release of Supersonik, a Subsonic client written using Kirigami for SailfishOS and other mobile Linux operating systems.
For a complete overview of what's going on, visit KDE's Planet, where you can find all KDE news unfiltered directly from our contributors.
Get Involved
The KDE organization has become important in the world, and your time and
contributions have helped us get there. As we grow, we're going to need
your support for KDE to become sustainable.
You can help KDE by becoming an active community member and getting involved.
Each contributor makes a huge difference in KDE — you are not a number or a cog
in a machine! You don’t have to be a programmer either. There are many things
you can do: you can help hunt and confirm bugs, even maybe solve them;
contribute designs for wallpapers, web pages, icons and app interfaces;
translate messages and menu items into your own language; promote KDE in your
local community; and a ton more things.
You can also help us by donating. Any monetary
contribution, however small, will help us cover operational costs, salaries,
travel expenses for contributors and in general just keep KDE bringing Free
Software to the world.
To get your application mentioned here, please ping us in invent or in Matrix.
Uh. Has it really been almost half a year already? Whoops.
Unfortunately even with this many months I didn't get quite as much done in KDE-land as I hoped, for two main reasons:
I've been bouncing back and forth between quite big tasks (for my current level of experience in the KDE stack), leading to a lot of time spent with few results. I've learned a lot, but there's not much to show for it yet.
A good amount of time was taken by preparations for the 2024 European Rocketry Challenge (EuRoC) in Portugal - this was my second time there with the TU Wien Space Team and while it was an absolute blast, prepping a student-build bi-liquid propelled rocket for launch is on the more time consuming side of things. Who'd have thought! Maybe I'll write a dedicated post for this some time in the future, we'll see.
Back to KDE though: It wasn't all just learning - my phone also broke! Well. Kind of. Probably a loose contact in the SIM reader leading to it dropping connection to my SIM card a bit more often than I'd like.
However this did push me to put said SIM into my old OnePlus 6T which just so happened to be running postmarketOS edge making me an official Linux Mobile daily-driver.
And I'm happy to report it mostly just worked. Sure, there's a few apps I'd like to have that aren't available on Linux Mobile (yet?), but what's there works and it's enough for me to use it.
Though there are certainly a number of more-than-a-bit-annoying bugs to be ironed out - so iron them out I will. For now my SIM card is back in my spotty Android phone until I fix a bug which sometimes duplicates incoming calls making them continue ringing while you've already picked up (less than ideal), but after that I think I'll stay on my 6T with Plasma Mobile for a longer while.
Now before I write another novel, let's get to the stuff I did actually finish in the last few months.
Merged Changes
Mobile Taskswitcher
Fixed an issue with the animation opening the taskswitcher from homescreen
Fixed the icon list during task scrub mode sometimes being off center
Reintroduced maximizing the selected window when not in docked mode. Technically it shouldn't be necessary since our KWin configuration should force windows to be fullscreen already, but some apps managed to break out of that (mostly GTK based apps), so back in it goes.
Disable blue border on touch gestures in mobile environment - it's nice as an indicator for mouse based gestures, but unnecessary here.
Add double tap on navbar task switcher button to switch between the 2 most recent apps.
Misc
Disabled session restore on mobile (at least until a bug with dialer launching ontop of login screen soft-locking the phone is fixed)
This is not a change by me, but I wanted to mention it because it's great and I mentioned in my last post that I tried (and failed) working on that before: Micah Stanley did a marvelous job at new mobile friendly notifications!
I've also done my first MR reviews which was exciting and a lot more work than I anticipated. At this point I want to thank all the people who have spent time on my MRs already!
Unfinished
I still haven't managed to get back to my touch corner gesture MR for KWin due to all the stuff that came in between like:
Fixing that the navigation gestures are still active while the navbar is enabled. Unfortunately this requires a change in how our setting system works and... CMake broke me here. I got pretty close to fixing this but had to leave it be for now for my own sanity's sake. I hope to get back to this soon since this is quite annoying.
Improving plasma-dialer's lockscreen behavior. Right now with session restore it restores above the initial login screen on mobile essentially soft-locking the phone if it happened to be running when the phone was shut down. A similar thing happens when a call is received during the lockscreen - I'm currently figuring out how to best fix that.
Well, that's all from me now. Hopefully I manage to do the next post in a more timely manner, but we'll see for how long my current bigger ticket items will keep me occupied for
Happy new year everyone! It’s now 2025, we’ll see what it brings.
Unsurprisingly this week we got a couple of nice “2024 retrospective” articles in this edition, I expect more to show up in the coming weeks. Anyway, let’s go for my web review for the week 2025-01.
Open Source on its own is no alternative to Big Tech - Bert Hubert’s writings
Tags: tech, foss, business
Or why making a dent in the enterprise software space is hard for FOSS… The good news is, it’d require setting up whole ecosystems of services.
The Web standards are indeed too complex. That severely limits the possibility of browser engine incumbents. I agree there’s a deeper lesson here about the scale of technologies.
The results are unsurprising. They definitely confirm what we expected. The models are good at predicting the past, they’re not so great at solving problems.
Very nice piece. This is indeed mostly about building organizational knowledge. If someone leaves a project that person better not be alone to ensure some continuity… lost knowledge is very hard to piece back together.
smankowski
@sitter:kde.org
