If you’re old enough, you probably remember that there was a meme from the 4.x days is that Plasma is all about clocks.
I’ve started working on some new artwork, and ended up sidetracked spending more time designing fun clocks for Plasma than on what I planned to work on, proving there’s some truth to the meme.
These are based on one of the coolest watch designs I’ve seen in recent years – a Raketa Avant Garde:
In the latest Plasma 6.3 Beta, you will find a new executable named kcursorgen in /usr/bin. It can convert an SVG cursor theme to the XCursor format, in any sizes you like. Although this tool is intended for internal use in future Plasma versions, there are a few tricks you can play now with it and an SVG cursor theme.
(Unfortunately, the only theme with the support that I know, besides Breeze, is Catppuccin. I have this little script that might help you convert more cursor themes.)
@ivan:kde.org
qt6-svg library.xcursorgen command, usually found in xorg-xcursorgen package.You should be able to set any cursor size with SVG cursors, right? Well, not at the moment, because:
But we can do it manually with kcursorgen. Take Breeze for example:
First, copy the cursor theme to your home directory. And let's change the directory name, so the original one is not overriden:
mkdir -p ~/.local/share/icons
cp -r /usr/share/icons/breeze_cursors ~/.local/share/icons/breeze_cursors.my
Then open ~/.local/share/icons/breeze_cursors.my/index.theme in the editor. Change the name in Name[_insert your locale_]= so you can tell it from the original in the cursor settings.
For example, if we want a size 36 cursor, and the display scale is 250%:
cd ~/.local/share/icons/breeze_cursors.my
rm -r cursors/
kcursorgen --svg-theme-to-xcursor --svg-dir=cursors_scalable --xcursor-dir=cursors --sizes=36 --scales=1,2.5,3
Some Wayland apps don't support fractional scaling, so they will round the scale up. So we need to include both 2.5 and 3 in the scale list.
The above command generates XCursor at size 36, 90 and 108. Note that the max size of the original Breeze theme is 72, so this is something not possible with the original theme.
(kcursorgen also adds paddings when necessary, to satisfy alignment requirements of some apps / toolkits. E.g., GTK3 requires cursor image sizes to be multiple of 3 when the display scale is 3. So please use --sizes=36 --scales=1,2.5,3, not --sizes=36,90,108 --scales=1, because only the former would consider alignments.)
Then you can go to systemsettings - cursor themes, select your new theme, and choose size 36 in the dropdown.
(Yes, you can have HUGE cursors without shaking. Size 240.)
As explained before, Breeze theme triggers a bug in GTK4 when global scaling is used, resulting in huge cursors. It's because Breeze's "nominal size" (24) is different from the image size (32).
We can work around this problem by changing the nominal size to 32.
Step 1 is same as above. Then we modify the metadata:
cd ~/.local/share/icons/breeze_cursors.my
find cursors_scalable/ -name 'metadata.json' -exec sed -i 's/"nominal_size": 24/"nominal_size": 32/g' '{}' \;
rm -r cursors/
kcursorgen --svg-theme-to-xcursor --svg-dir=cursors_scalable --xcursor-dir=cursors --sizes=32 --scales=1,1.5,2,2.5,3
Then you can go to systemsettings - cursor themes, select your new theme, and choose size 32 in the dropdown. Cursors in GTK4 apps should be fixed now.
It might be possible to only package the index.theme file and cursors_scalable directory for the Breeze cursor theme (and other SVG cursors themes), then in an postinstall script, use kcursorgen to generate the cursors directory on the user's machine.
This would greatly reduce the package size. And also you can generate more sizes without worrying about blown package size.
But the fact that kcursorgen is in the breeze package might make some dependency problems. I have an standalone Python script that does the same. (But it requires Python and PySide6.)
The Amarok Development Squad is happy to announce the immediate availability of Amarok 3.2.1, the first bugfix release for Amarok 3.2 "Punkadiddle"!
3.2.1 features fixes for some small UI bugs, improvements for file transfers to MTP devices, and some compilation fixes for different combinations of Qt6 versions and compilers, enabling easier testing of Qt6 builds. Additionally, it is now theoretically possible to enable last.fm and gpodder.net support in a Qt6 build. However, this requires Qt6 support in liblastfm and libmygpo-qt; a functionality that is not yet included in the most recent released versions of the libraries.
In addition to source code, Amarok is available for installation from many distributions' package repositories, which are likely to get updated to 3.2.1 soon, as well as the flatpak available on flathub.
You can find the tarball package on download.kde.org and it has been signed with Tuomas Nurmi's GPG key.
This is the first version for Kf6/Qt6.
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.
We already looked at KCrash, coredumpd, and DrKonqi. This week it’s time to look at the final piece of the puzzle — 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!
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)
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).
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.
Plasma Wayland Protocols 1.16.0 is now available for packaging. It is needed for the forthcoming Plasma 6.3.
URL: https://download.kde.org/stable/plasma-wayland-protocols/
SHA256: da3fbbe3fa5603f9dc9aabe948a6fc8c3b451edd1958138628e96c83649c1f16
Signed by: E0A3EB202F8E57528E13E72FD7574483BB57B18D Jonathan Riddell jr@jriddell.org
Full changelog:
The advantages of Python are well known and it is a language that still remains hyped — but let’s look at some of its other sides.
Line Count
One positive side of many solutions is by stressing how few lines something requires. That’s especially the case with Python, but it doesn’t take into account the whole Software Development Life Cycle (SDLC).
One does not only want to churn out some idiomatic example code. Instead one has a large, complex software project that needs to be robust and withheld quality assurance during a long product lifetime. Hence one looks after other qualities other than whether the very initial effort requires little code.
Contracts Matter
Python’s typing system is so-called duck typing: ”If it walks like a duck and it quacks like a duck, then it must be a duck”. First of all, it means that if a caller doesn’t live up to the contract of the API, it will result in an obscure crash somewhere far down in the called code. The caller have to figure out what went wrong. This is a problem because in QA there’s the mantra that exhaustive testing is impossible, which is one reason to why we have to rely on code robustness.
I also think types is natural documentation. “What does this function do? What does it expect?” Types document that. Hence I argue conceptually for abstract base types such as Swift’s protocols, Java’s interfaces and so forth.
Versus MatLab
I replace MatLab with Python for quantitative finance, but what I miss in commercially backed projects such as first-mentioned, is good documentation. For instance NumPy and Pandas lack a consumer/user/customer-centric perspective, as opposed to what perhaps (we) programmers enjoy to do. For some reason open-source perhaps doesn’t attract for writing documentation. While it could make use of systematic addressing of this problem, it is low hanging fruit for Google Summer of Code, for instance.
Python is slow and I see the solution in the computation area as a hack: the code path jumps into C/C++ land using NumPy and Pandas. This is fine, but the code becomes convoluted and I associate to Perl’s “write once, understand never.” It feels like Python attempts to be taken to an area which results in an ill design.
Conclusion
What is Python useful for? I believe light, small tasks, such as doing something computationally advanced that isn’t a complex software project. The lack of typing means you cannot (or perhaps shouldn’t) write large applications, and perhaps performance is relevant.
However, for the more short computation and script tasks it is excellent, and it is indeed in that area it receives publicity.
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!
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.
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.
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.
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:
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!
Some other bugs have also been fixed in this release:
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.
smankowski
