Great news, everyone! We now have all the necessary components to start creating our 16px icon collection. I believe that we can work on the design and creation of these icons simultaneously.
Here are some general guidelines to consider when designing the 16px icons:
I am excited to begin working on this project and would be grateful for any designer assistance that is available. If you need help learning Figma, please don’t hesitate to reach out, and we will gladly provide our support.
If you require edit access to the Figma file for the 16px icon collection, please let me know. I believe that collaboration and teamwork will lead to the creation of an amazing set of 16px icons.
Additionally, I wanted to let you all know that I have made some edits to the color scheme of the graphic. I would appreciate any feedback you may have on the changes, and whether I might have missed anything. Let’s work together to create a cohesive and visually stunning icon collection!
Once our colors are aligned to what we need in the system, we will update the issue recently created for this purpose. This issue is under heavy development and things are changing rapidly. Read with caution and expect updates.
https://invent.kde.org/teams/vdg/issues/-/issues/82
Colors in the design system have changed. I need to correlate the colors to the color labels below. It will look a little off for some time. However, the color variables in Figma are updated to the latest feedback. Just this graphic needs the updates as well. Only the color box is correct, not the color names
This week we took previously-created Ocean window shadows created by Manuel de la Fuente and integrated them in the design system. The shadow variables in Figma now use Ocean-inspired shadow levels to make them more visible. This is to address feedback on shadows previously being too faint. Hopefully these make a difference.
TSDgeos
For some reason that I don't know, the XL shadow looks fainter than the LG shadow, but it seems to be a visual bug in Figma. If you apply the XL shadow, it should appear correctly in your graphics.Transition to PenPot is on hold for now until we have the community instance created and path manipulation updates are applied. This would impede us from recreating icons the same way we have them right now.
Let’s go for my web review for the week 2024-42.
Tags: tech, capitalism, marketing, politics, criticism
People have to realize that tycoons like the ones from big tech companies can both be rich and mediocre. They were smart enough to seize opportunities at the right time but they are not exceptional. In fact, they’re even boring and spineless.
The best quote in this paper I think is: “There is nothing special about Elon Musk, Sam Altman, or Mark Zuckerberg. Accepting that requires you to also accept that the world itself is not one that rewards the remarkable, or the brilliant, or the truly incredible, but those who are able to take advantage of opportunities, which in turn leads to the horrible truth that those who often have the most opportunities are some of the most boring and privileged people alive.”
The real problem is that lots of journalists can’t come to term with the fairy tale and so fall prey to all their publicity stunts as if it had any hidden meaning. This is dangerous because of all the political power they try to seize for their own gains.
Meanwhile, “the most powerful companies enjoy a level of impunity, with their founders asked only the most superficial, softball of questions — and deflecting anything tougher by throwing out dead cats when the situation demands.”
Now you can go and read this long piece.
https://www.wheresyoured.at/rockstars/
Tags: tech, politics
It’s actually unsurprising, all those tech and crypto bros have assets in jeopardy if some regulation is applied to their industry. No wonder they’d support the one with the most libertarian agenda after the current administration which did look into antitrust cases and increased regulation (even though marginally).
Tags: tech, blog, wordpress
Wow, the atmosphere looks fairly toxic at Automattic right now. It felt like it was just about the trademark dispute but clearly the craziness is running much deeper. This is concerning for WordPress future I think.
https://www.404media.co/automattic-buyout-offer-wordpress-matt-mullenweg/
Tags: tech, social-media, rss
Want to put an end to the social media platforms weight on our lives? For once there’s an individual solution which might work. This is a chance because as he rightfully points out individual solutions are generally too complicated to bring systemic change. Here this is actually doable.
Tags: tech, cloudflare, rss
Cloudflare indeed needs to do better to accommodate RSS readers. They’re not malicious bots and shouldn’t be flagged as such.
https://openrss.org/blog/using-cloudflare-on-your-website-could-be-blocking-rss-users
Tags: tech, web, browser, google, privacy, politics
A good reminder that this is not the Google Chrome alternative you’re looking for. It’s the same privacy invading mindset with some bigotry on top.
https://www.spacebar.news/stop-using-brave-browser/
Tags: tech, web, archive, security
It’s a very important project, it’s really concerning that this attack went through. The service is still partly disrupted but they’re showing signs of recovery. Let’s wish them luck and good health. This archival service is essential for knowledge and history preservation on the web.
Tags: tech, ai, machine-learning, gpt, knowledge, criticism, research
Now the impact seems clear and this is mostly bad news. This reduces the production of public knowledge so everyone looses. Ironically it also means less public knowledge available to train new models. At some point their only venue to fine tune their models will be user profiling which will be private… I’ve a hard time seeing how we won’t end up stuck with another surveillance apparatus providing access to models running on outdated knowledge. This will lock so many behaviors and decisions in place.
https://academic.oup.com/pnasnexus/article/3/9/pgae400/7754871#483096365
Tags: tech, ai, machine-learning, neural-networks, gpt, logic, mathematics, research
Of course I recommend reading the actual research paper. This article is a good summary of the consequences though. LLMs definitely can’t be trusted with formal reasoning including basic maths. This is a flaw in the way they are built, the bath forward is likely merging symbolic and sub-symbolic approaches.
https://garymarcus.substack.com/p/llms-dont-do-formal-reasoning-and
Tags: tech, python, security, supply-chain, developer-experience
It’s tempting to use uv. It’s probably fine on the developer workstation at this point. It looks a bit early to use it in production though, it’s a bit young for that and carries questions regarding supply chain security still.
https://pythonspeed.com/articles/uv-python-production/
Tags: tech, raspberry-pi, gpu, gaming
Definitely a funny hack. Not usable for compute workloads though.
https://www.jeffgeerling.com/blog/2024/use-external-gpu-on-raspberry-pi-5-4k-gaming
Tags: tech, rust, embedded
Nice article showing the steps to port Rust code to run on deeply embedded systems. It highlights the difficulties and caveats of such a task.
https://towardsdatascience.com/nine-rules-for-running-rust-on-embedded-systems-b0c247ee877e
Tags: tech, programming, optimization
This is too often overlooked, but table lookups can help with performance if done well.
https://lemire.me/blog/2024/10/14/table-lookups-are-efficient/
Tags: tech, graphics, 2d, hardware
Nice graphic tricks when the hardware was harder to work with. It’s amazing how much we could fit back then out of sheer motivation.
https://arnaud-carre.github.io/2024-09-08-4ktribute/
Tags: tech, web, collaborative, crdt
Excellent introduction to sync engines and how they work. The concept is indeed coming from the gaming industry and we see it more in web applications nowadays due to the user demands for working offline and real time collaboration.
Tags: tech, programming, logic, ai, prolog
Finally a path forward for logic programming? An opportunity to evolve beyond Prolog and its variants? Good food for thought.
https://www-ps.informatik.uni-kiel.de/~mh/papers/WLP24.pdf
Tags: tech, reliability, tests, debugging
This is an important trait to have for a developer. If you’re content of things working without knowing why and how they work, you’re looking for a world of pain later.
https://buttondown.com/hillelwayne/archive/be-suspicious-of-success/
Tags: tech, architecture, complexity, developer-experience, vendor-lockin
I tend to side on the “boring tech” side, but indeed this is a good reminder that what we want is finding the right balance.
https://yonkeltron.com/posts/boring-tech-is-stifling-improvement/
Tags: tech, complexity, cognition, design, architecture
Definitely this. Our cognitive capacity is limited, we’d better not deplete it due to complexity before we even reach the core of the problem at hand.
https://minds.md/zakirullin/cognitive#full
Tags: tech, philosophy
Our craft is based on shifting sands. This brings interesting philosophical questions, like why do it at all? I think the answer proposed in this short article is spot on. It can help bring new ideas on how to be in the world. This is more important than the code itself.
https://sean.voisen.org/blog/why-make-software
Tags: train, ecology, politics
This is definitely a good idea, I wish we had the same in France. This is too bad that they plan to raise the price, it’s going to limit the impact of the measure.
Bye for now!
I saw this question on KDE forum about how to limit memory usage of a specific application in KDE, using systemd specifically. I did some research on that.
man systemd.resource-control lists plenty of options that we can set to a cgroup. E.g., to limit the memory usage of a service, we can add:
@genericity:matrix.orgMemoryAccounting=yes
MemoryHigh=2G
under the [Service] section of its .service file.
The difference between this and ulimit is that ulimit is per process, while systemd resource control is per cgroup. I.e., the MemoryHigh is accounted to the sum of both the service process, and all sub-processes it spawns, and even detached processes, i.e., daemons.
(That's actually the main point of cgroup: a process tree that a process can't escape via double-forking / daemonizing.)
KDE Plasma launches apps as systemd services. (See this doc and this blog for more details.)
We can find the name of the systemd service of an app like this:
$ systemd-cgls|grep konsole
│ │ │ ├─app-org.kde.konsole@0d82cb37fcd64fe4a8b7cf925d86842f.service
│ │ │ │ ├─35275 /usr/bin/konsole
│ │ │ │ └─35471 grep --color=auto konsole
But the problem is:
@ is a random string, changes every time the app is launched.$ systemctl --user cat app-org.kde.konsole@0d82cb37fcd64fe4a8b7cf925d86842f.service
# /run/user/1000/systemd/transient/app-org.kde.konsole@0d82cb37fcd64fe4a8b7cf925d86842f.service
# This is a transient unit file, created programmatically via the systemd API. Do not edit.
[Service]
Type=simple
...
So if we want to limit the memory usage of Konsole, there's no persistent .service file on disk that we can edit.
Luckily, systemd allows us to create drop-in files to partially modify a service. Also, systemd considers app-org.kde.konsole@0d82cb37fcd64fe4a8b7cf925d86842f.service to be instances of a template named app-org.kde.konsole@.service. (This is how things like getty@tty3.service work.) So we can create a drop-in file named ~/.config/systemd/user/app-org.kde.konsole@.service.d/override.conf with the content:
[Service]
MemoryAccounting=yes
MemoryHigh=2G
and it will apply to all instances of app-org.kde.konsole@.service, even if there's no service file with that name.
(The file doesn't have to be named "override.conf". Any name with .conf works.)
Then we need to reload the systemd user manager: systemctl --user daemon-reload.
Now we can launch Konsole, and check if the memory limit works:
$ systemctl --user show 'app-org.kde.konsole@*.service'|grep MemoryHigh=
EffectiveMemoryHigh=2147483648
MemoryHigh=2147483648
StartupMemoryHigh=infinity
Note: as explained above, the limit applies to the sum of Konsole and all processes it spawns. E.g., if we run kwrite in Konsole, the memory usage of kwrite will be accounted to the limit of Konsole, and the limit we set to KWrite won't apply.
We can put defaults in ~/.config/systemd/user/app-.service.d/override.conf, and it will match all services whose name starts with app-.
Alternatively, if we run systemd-cgls, we can see that all apps are under a node named app.slice. So we can also put defaults in ~/.config/systemd/user/app.slice.d/override.conf, and all apps will inherit the settings. However, this is different from the previous method, as user services are also under app.slice by default, so they will also inherit the settings.
A new Craft cache has just been published. The update is already available for KDE's CD, CI (Windows/Android) will follow in the next days.
Please note that this only applies to the Qt6 cache. The Qt5 cache is in LTS mode since April 2024 and does not recieve major updates anymore.
KDE Craft is an open source meta-build system and package manager. It manages dependencies and builds libraries and applications from source on Windows, macOS, Linux, FreeBSD and Android.
Learn more on https://community.kde.org/Craft or join the Matrix room #kde-craft:kde.org
Let’s go for my web review for the week 2024-41.
Tags: tech, kde, foss, ux
Looks like we properly live by the “simple by default, powerful when needed” tagline. Now there are also challenges, this article gives a nice balanced view.
https://www.osnews.com/story/140538/why-i-use-kde/
Tags: tech, programming, performance, energy
Nice paper which debunks the choice of the language as an important factor for energy efficiency. The previous papers had a too simple model, this one puts forth a more complete causal model. There are many factors at play regarding energy efficiency, the programming language itself is not really one of them.
https://arxiv.org/abs/2410.05460
Tags: tech, google, android, surveillance
It’s really time to get as many people as possible out of those toxic ecosystems…
https://pluralistic.net/2024/10/08/water-thats-not-wet/#pixelated
Tags: tech, ai, machine-learning, gpt, business, scam
Indeed, we should stop listening to such people who are basically pushing fantasies in order to raise more money.
https://www.theatlantic.com/technology/archive/2024/10/sam-altman-mythmaking/680152/
Tags: tech, web, self-hosting, complexity
Excellent point, we made the web too complex for regular users. This is actually an issue in term of access and democracy for people to write content there.
https://kristoff.it/blog/static-site-paradox/
Tags: tech, web, html, self-hosting
There is hope! Nice intro for regular people who want to get into publishing a web site. Good way to bring some democracy back to the web.
Tags: tech, web, frontend, htmx
I don’t think I would side with the conclusion. It’s a worthwhile article to get a better idea of the pain points around htmx.
https://chrisdone.com/posts/htmx-critique/
Tags: tech, linux, wayland, foss, governance
Yes, the governance of Open Source projects can be tricky. This is part of the job though, and properly embraced we all go further. An example from the Wayland space.
https://www.supergoodcode.com/My-Wayland-Your-Wayland-Our-Wayland/
Tags: tech, unix, system
Indeed, we should likely revisit what we put in our PATH environment variable. Some of it is old cruft which is now unnecessary.
https://blog.izissise.net/posts/env-path/
Tags: tech, c++, coroutine, performance
Several ways to deal with the task, which are the performance implications? Clearly coroutines aren’t the best tool for the job here.
Tags: tech, multithreading
This is a neat broad introduction about the problems you will encounter when multiple threads are involved and how to approach them.
https://underlap.org/approaches-to-concurrent-programming
Tags: tech, cpu, performance, memory
Data layout is essential for performance reasons. It is too often overlooked. If you want real speed you need to help the memory subsystem.
https://cedardb.com/blog/optimizing_data_layouts/
Tags: tech, gpu, graphics, shader
Another good tutorial about global illumination. Make sure to read part 2 as well.
Tags: tech, colors, shader
Neat little introduction on color manipulation using matrices. Mentions the things to pay attention to.
https://lisyarus.github.io/blog/posts/transforming-colors-with-matrices.html
Tags: tech, data-visualization
Nice catalogue of ideas for data visualisation tasks.
Tags: tech, tech-lead, engineering, decision-making
Nice post, and indeed it’s not about Python if you read until the end. It shows that it’s important to be able to make informed choices and not just pick your tech stack based on knee-jerk reactions.
https://jerf.org/iri/post/2024/not_about_python/
Tags: tech, databases, design, performance
I’m not sure I’m sold on this one. Interesting food for thought but I’ll have to mull it over for a while I think. I’m concerned about the performance implications of querying like this.
Tags: tech, codereview, psychology, cognition, anxiety, research
Still very early days on this topic, clearly more studies are required. Still this one is interesting and indicates are clear link between code review anxiety and code review avoidance. If you’re often procrastinating or rubber stamping code reviews, a workshop to reduce biases and showing you can manage your anxiety could improve things greatly.
https://link.springer.com/article/10.1007/s10664-024-10550-9
Tags: tech, science
The latest Nobel prizes indeed say something about the presence of computer scientists in other fields. Do we risk to delve too much on theoretical model? For sure using computers helps a lot, we have to be careful about not loosing empirical validation in the process.
https://lemire.me/blog/2024/10/09/from-software-to-reality/
Bye for now!
We have just switched on the upgrade for KDE neon to rebase on Ubuntu 24.04 LTS.
We do this every two years and the 22.04 LTS base was getting increasingly crusty with old Pipewire causing problems and packages like Krita not compiling at all.
Follow the Noble Upgrade instructions or just click the notification that should appear soon.
The Kubuntu Team is happy to announce that Kubuntu 24.10 has been released, featuring the new and beautiful KDE Plasma 6.1 simple by default, powerful when needed.
Codenamed “Oracular Oriole”, Kubuntu 24.10 continues our tradition of giving you Friendly Computing by integrating the latest and greatest open source technologies into a high-quality, easy-to-use Linux distribution.
Under the hood, there have been updates to many core packages, including a new 6.11 based kernel, KDE Frameworks 5.116 and 6.6.0, KDE Plasma 6.1 and many updated KDE gear applications.
Kubuntu has seen many updates for other applications, both in our default install, and installable from the Ubuntu archive.
Applications for core day-to-day usage are included and updated, such as Firefox, and LibreOffice.
For a list of other application updates, and known bugs be sure to read our release notes.
The Plasma wayland session is now the default option in sddm (display manager login screen). An X11 session can be selected instead if desired. The last used session type will be remembered, so you do not have to switch type on each login.
Download Kubuntu 24.10, or learn how to upgrade from 24.04 LTS.
Note: For upgrades from 24.04, there may a delay of a few hours to days between the official release announcements and the Ubuntu Release Team enabling upgrades.
Kirigami Addons is out. This releases contains mostly code cleanup and minor improvements. There is netherless a few relevant changes. Thanks to everyone who contributed some code.
A new KAppTemplate is available as a good starting point for application that manage multimedia libraries. It is based on shared design of Peruse, Arianna and the WIP Calligra Launcher.
Hopefully it helps people who want to develop game launchers and other type of specialized multimedia applications.
More templates are planned (e.g. for chat applications), so stay tunned!
FormCard is the part of Kirigami Addons that received the most changes in this release. First of all, FormCard now use more consistent spacing and padding, which slighly less horizontal padding. Descriptions for radio and checkbox delegates are also put underneath the delegate’s main text and checkbox, in an effort to make FormCard a bit more compact.
Additionally FormComboBoxDelegate now lets you display an inline status
similar to that is available in other FormCard’s delegates.
Finally FormCard.AboutKDE was renamed to FormCard.AboutKDEPage. This improve
the naming consistency with other page compoenents. A compatibility wrapper on
top of AboutKDEPage named AboutKDE is still available to not break any
existing applications.
The Banner component is now deprecated. Kirigami.InlineMessage now has a
position parameter which can be set to Header or Footer. Additionally
with KDE Frameworks 6.8 Kirigami.InlineMessage will look exactly the same as
Banner! So there is no more reasons for this component to exists
in Kirigami Addons.
Kirigami Addons supports static builds with a recent enough version of extra-cmake-modules.
You can find the package on download.kde.org and it has been signed with my GPG key.
I've been fixing cursor problems on and off in the last few months. Here's a recap of what I've done, explanation of some cursor size problems you might encounter, and how new developments like Wayland cursor shape protocol and SVG cursors might improve the situation.
(I'm by no means an expert on cursors, X11 or Wayland, so please correct me if I'm wrong.)
My involvement with cursors started back in the end of 2023, when KDE Plasma 6.0 was about to be released. A major change in 6.0 was enabling Wayland by default. And if you enabled global scaling in Wayland, especially with a fractional scale like 2.5x, cursor sizes would be a mess across various apps (the upper row: Breeze cursors in Plasma 6.0 Beta 1, Wayland, 2.5x global scale, the lower row: Same cursors in Plasma 6.0):
So I dug into the code of my favorite terminal emulator, Kitty, which at the time drew the cursor in a slightly smaller size than it should be (similar to vscode in the above image). I gained some understanding of the problem, and eventually fixed it. Let me explain.
In X11, there used to be a standard set of cursors, but nowadays most apps use the XCursor lib to load a (user-specified) cursor theme and draw the cursor themselves. So in order to have cursors in the same theme and size across apps, we need to make sure that:
The transition to Wayland created difficulties in both points:
It used to be simple in X11: we have Xcursor.size and Xcursor.theme in xrdb, also XCURSOR_SIZE and XCURSOR_THEME in environment variables. Setting them to the same value would make sure that all apps get the same cursor theme and size.
But Wayland apps don't use xrdb, and they interpret XCURSOR_SIZE differently: in X11, the size is in physical pixels, but in Wayland it's in logical pixels. E.g., if you have a cursor size 24 and global scale 2x, then in X11, XCURSOR_SIZE should be 48, but in Wayland it should be 24.
The Wayland way is necessary. Imagine you have two monitors with different DPI, e.g. they are both 24" but monitor A is 1920x1080, while monitor B is 3840x2160. You set scale=1 for A and scale=2 for B, so UI elements would be the same size on both monitors. Then you would also want the cursor to be of the same size on both monitors, which requires it to have 2x more physical pixels on B than on A, but it would be the same logical pixels.
So Plasma 6.0 no longer sets the two environment variables, because XCURSOR_SIZE can't be simultaneously correct for both X11 and Wayland apps. But without them and xrdb, Wayland apps no longer have a standard way to get the cursor theme and size. Instead, different frameworks / toolkits have their own ways. In Plasma, KDE / Qt apps get them from the Qt platform integration plugin provided by Plasma, GTK4 apps from ~/.config/gtk-4.0/settings.ini (also set by Plasma), Flatpak GTK apps from the GTK-specific configs in XDG Settings Portal.
The last one is particularly weird, as you need to install xdg-desktop-portal-gtk in order fix Flatpak apps in Plasma, which surprised many. It might seem like a hack, but it's not. Plasma officially recommends installing xdg-desktop-portal-gtk, and this was suggested by GNOME developers.
But what for 3rd-party Wayland apps besides GTK and Qt? The best hope is to read settings in either the GTK or the Qt way, piggy-backing the two major toolkits, assuming that the DE would at least take care of the two.
(IMHO either Wayland or the XDG Settings Portal should provide a standard way for apps to get the cursor theme and size.)
That was part of the problem in Kitty. It used to read settings from the GTK portal, but only under a GNOME session. I changed it to always try to read from the portal, even if under Plasma. But that's not the end of the story...
It's practically a non-issue in X11, as the user usually sets a size that the cursor theme provides, and the app just draws the cursor images as-is. But if you do set a cursor size not available in the theme (you can't do that in the cursor theme settings UI, but you can manually set XCURSOR_SIZE), you'll open a can of worms: various toolkits / apps deal with it differently:
XCursor default size 24, so it's a lot smaller.The situation becomes worse with Wayland, as the user now specifies the size in logical pixels, then apps need to multiply it by the global scale to get the size in physical pixels, and try to load a cursor in that size. (If the app load the cursor in the logical size, then either the app or the compositor needs to scale it, resulting in a blurry / pixelated cursor.) With fractional scaling, it's even more likely that the required physical size is not available in the theme (which typically has only 2~5 sizes), and you see the result in the picture above.
It can be fixed by moving the "when we can't load cursors in the size we need, load a different size and scale it" logic from apps / toolkits to the XCursor lib. When the app requests cursors in a size, instead of returning the closest size available, the lib could scale the image to the requested size. So apps would always get the cursor in the size they ask for, and their own different scaling algorithms won't get a chance to run.
Either the default behavior can be changed, or it can be hidden behind a new option. But I didn't do that, because I felt at the time that it would be difficult to either convince XCursor lib maintainers to make a (potentially breaking) change to the default behavior, or to go around convincing all apps / toolkits to use a new option.
Then it came to me that although I can't fix all these toolkits / apps, they seem to all work the same way if the required physical size is available in the theme - then they just draw the cursor as-is. So I added a lot of sizes to the Breeze theme. It only has size 24, 36 and 48 at the time, but I added physical sizes corresponding to a logical size 24 and all global scales that Plasma allows, from 0.5x to 3x, So it's 12, 18, 24 ... all the way to 72.
It was easy. The source code of the Breeze theme is SVG (so are most other themes). Then a build script renders it into images using Inkscape, and packages them to XCursor format. The script has a list of the sizes it renders in, so I added a lot more.
And it worked! If you choose Breeze and size 24, then (as in the bottom row in the picture above) various apps draw the cursor in the same size at any global scale available in Plasma.
But this method has its limitations:
36x3=108 is not available in the theme, and you see the mess again. But we can't add sizes infinitely, as explained in Vlad's blog, the XCursor format stores cursor images uncompressed, so the binary size grows very fast when adding larger sizes.Both limitations can be lifted with SVG cursors. But before getting to that, let's talk about the "right" way to fix the cursor size problem:
The simple and reliable way to get consistent cursors across apps is to not let apps draw the cursor at all. Instead, they only specify the name of the cursor shape, and the compositor draws the cursor for them. This is how Wayland cursor shape protocol works. Apps no longer need to care about the cursor theme and size (well, they might still need the size, if they want to draw custom cursors in the same size as standard shapes), and since the compositor is the only program drawing the cursor, it's guaranteed to be consistent for all apps using the protocol.
(It's quite interesting that we seem to went a full circle back to the original server-defined cursor font way in X11.)
Support for this protocol leaves a lot to improve, though. Not all compositors support it. On the client side, both Qt and Electron have the support, but GTK doesn't.
There are merge requests for GTK and Mutter, but GNOME devs request some modifications in the Wayland protocol before merging them, and the request seems to be stuck for some months. I hope the recent Wayland "things" could move it out of this seemingly deadlock.
Anyway, with this protocol, only the compositor has to be modified to support a new way to draw cursors. This makes it much easier to change how cursors work. So we come to:
Immediately after the fix in Breeze, I proposed this idea of shipping the source SVG files of the Breeze cursor theme to the end user, and re-generate the XCursor files whenever the user changes the cursor size or global scale. This way, the theme will always be able to provide the exact size requested by apps. (Similar to the "modify XCursor lib" idea, but in a different way.) It would remove the limitation 2 above (and also limitation 1 if 3rd-party themes ship their source SVGs too).
With SVG cursors support in KWin and Breeze, I plan to implement this idea. It would also allow the user to set arbitrary cursor size, instead of limited to a predefined list.
It's a new problem in GTK 4.16. If you use the Breeze cursor theme and a large global scale like 2x or 3x, you get huge cursors:
It has not limited to Plasma. Using Breeze in GNOME would result in the same problem. To explain it, let me first introduce the concept of "nominal size" and "image size" in XCursor.
Here is GNOME's default cursor theme, Adwaita:
"Nominal size" is the "cursor size" we are talking about above. It makes the list of sizes you choose from in the cursor theme settings UI. It's also the size you set in XCURSOR_SIZE. "Image size" is the actual size of the cursor image. "Hot spot" is the point in the image where the cursor is pointing at.
Things are a bit different in the Plasma default cursor theme, Breeze:
Unlike Adwaita, the image size is larger than the nominal size. That, combined with a global scale, triggers the bug in GTK4. Explanation of the bug.
XCursor allows the image size to be different from the nominal size. I don't know why it was designed this way, but my guess is so you can crop the empty part of the image. This both reduces file size, and reduces flicking when the cursor changes (with software cursors under X11). But the image size can also be larger than the nominal size, and Breeze (and a lot of other themes) uses this feature.
You can see in the above images that the "arrow" of nominal size 24 in Breeze is actually similar in size to the same nominal size in Adwaita. But the "badge" in Breeze is further apart, so it can't fit into a 24x24 image. That's why Breeze is built this way. In a sense, "nominal size" is similar to how "font size" works, where it resembles the "main part" of a character in the font, but some characters can have "extra parts" that go through the ceiling or floor.
This problem is already fixed in the main branch of GTK 4, but it's not backported to 4.16 yet, probably because the fix uses a Wayland feature that Mutter doesn't support yet. So at the moment, your only option is to use a different cursor theme whose "nominal size" and "image size" are equal.
The cursor code in GTK3 is different from GTK4, with its own limitations. You might find the cursor to be smaller than in other apps, and if you run the app in a terminal, you might see warnings like:
cursor image size (64x64) not an integer multiple of scale (3)
GTK3 doesn't support fractional scales in cursors. So if you have cursor size 24 and global scale 2.5x or 3x, it will use a scale 3x and try to load a cursor with a nominal size 24x3=72. And it requires the image size to be an integer multiple of the scale. So if your theme doesn't have a size 72, or it does but the image size is not multiple of 3, GTK3 fallbacks to a smaller unscaled cursor.
OK, this is a long post. Hope I can bring you more cursor goodies in Plasma 6.3 and beyond.