We've released a new video! ..Templates! you can create them with Krita to save time in your digital paintings and be more focused on your artwork. They are seamless, they are useful, and they are really easy to generate. So let´s go with another supercool feature of Krita.
Check out the video for download links for the templates themselves!
Here's our bi-monthly update from KDE's personal information management applications team. This report covers progress made in September and October 2024.
Since the last report, 24 people have contributed over 1100 changes to the KDE PIM code base. We also released a two bugfix releases of the KDE PIM Suite with the Gear releases 24.08.1 and 24.08.2
Please note this is the last bi-monthly blog post for KDE PIM. We will continue to work on KDE PIM but weekly improvements to KDE PIM are now included in the This Week in KDE Apps blog.
The KDE PIM team was at Akademy from the 7th to the 12th of September in Würzburg (Germany). We hosted again a PIM BoF.
We covered a few topics and made plans. In particular we touched upon contributions blockers, we hope the milestone system will help and also working on the amount of repositories which are not part of KDE Frameworks. Things are progressing in the right direction but slowly. Feel free to reach out to help!
Talking about the milestones. You can see what we got in store on the Gitlab board. Some of them are progressing nicely like the resurrection of Kontact for Windows or the port away from QCA.
If you see anything you fancy and you would like to help, reach out to us on the #kontact:kde.org Matrix channel!
Our travel assistance app Itinerary got a new two-level trip/timeline view, an extended public transport location search, a new full trip map view and better Android platform integration. Read more in its own bi-monthly update.
David has been working on fixing bugs around sound handling. In particular, repeating audio alarms only playing once have been fixed. Likewise the failure to play sound files using libVLC on some systems is gone. Also the backend to play sound can be changed at build time, it can use VLC or MPV.
But that's not the only bugs which got squashed. It's now possible to wake from suspend when using RTC wake and a crash has been fixed affecting systems where the kernel supports alarm timers.
Last but not least, the GUI has been improved around the run mode options in the preferences dialog.
Claudio has been busy fixing regressions and improving the stability of Merkuro. Notably, maps are now displayed again (if the event contains coordinates). Also, the collection combobox in the editors are now initialized with a valid collection and filtering features have been repaired.
The general improvements to support Plasma Activities is still on going. It is not enabled by default as it requires Akonadi Resources support to become really useful and the corresponding changes are not there yet.
On the KMail front the search has been greatly improved. There is now
a custom syntax usable in the search text field. One can now use keywords
like subject:, body:, to, from, has:attachment, is:important,
is:replied and so on to make more precise queries.
For instance one could write "from:vkrause@kde.org to:kde-pim@kde.org is:important"
to get only the emails from Volker on the kde-pim mailing list which are also flagged
as important.
As you may know, Fedora KDE 41 was released a couple of weeks ago.
I wanted to talk about a special feature that our colleague @farchord (with support from upstream developer @Nate Graham) has brought to our Fedora KDE distribution:
Enabling Third Party Repositories With A Single Click!
Thanks to the flexibility of plasma-welcome we can offer this feature 
Right after installing Fedora and on first login you will be presented with the Plasma Welcome window:
Before you click on Skip , you can go through the different slides to read about KDE and Fedora and also to decide whether you want to contribute with anonymous metrics or not (note: I personally do not):
Here is where the interesting part comes in, on the next slide:
With a simple click of a button you will enable the most commonly requested by our users Third Party Repositories like rpmfusion! (note: you will be asked for your administrator password)
Once the request is processed, the message will change to:
That’s it! You have successfully enabled Third Party Repositories without needing to modify any file or running any command whatsoever
Before you do anything with your system and your new configuration, I will strongly recommend to update your system via Plasma Discover :
Proceed with all the update and reboot to get the latest and shiniest from our repositories.
Finally, to verify that the Third Party software is available, you can check:
And that is it!
Enjoy!
This is all thanks to farchord, siosm , aleasto and ngraham‘s work!
Has this ever occurred to you? The most joyful moments of your life got filled with sorrow, a grief of loss…
Let’s talk about the Ubuntu Summit first, my international conference and solo travel outside my country. Probably I am the first from my entire extended family to visit a European country. My parents, well-wishers everyone was so happy. Only person didn’t know much about this, my maternal grandfather, whom I called (yes, “called”, he left us on 27th October 2024) Dada. Let me tell you about the summit first.
A few weeks ago Qt 6.8 was released, delivering many fixes and improvements for our software. Some of them were contributed by yours truly, and in this post I want to highlight some of them.
They relate to graphics tablet/stylus input on Wayland. Before we go into the fixes let’s have a quick overview of the flow of tablet input events on Wayland:
The genesis of input events is in the kernel driver for the particular tablet, which talks to the hardware (via USB, bluetooth etc). The kernel passes events to userspace via the evdev system. On the userspace side a Wayland compositor reads those events. Most compositors leverage libinput for this, a library that transforms raw evdev events into something more usable for the compositor while applying some cleaning and configuration. The compositor then delivers events to native Wayland applications using the tablet-v2 protocol. For legacy XWayland applications the compositor uses this protocol to send events to XWayland, which translates them into things X11 apps understand. The compositor can apply useful transformations to the input, like which area of the screen the tablet is mapped to, changing the pressure curve of the pen, or binding buttons to keyboard shortcuts.
The application then processes the events, potentially leveraging a UI toolkit like Qt. Qt creates QTabletEvent object for incoming Wayland events and delivers those to all UI elements. In case no UI element reacts to the event Qt will synthesize a mouse event from the tablet event and deliver that to the UI elements. That way most controls like buttons and menus don’t need special code to handle tablet input. Only when doing very low-level input handling or when needing tablet-specific interactions (like reacting to different pressure values) application developers need to explicitly handle tablet events in their code. Most UI toolkits will work somewhat similar to this. If an application doesn’t react to tablet input at all please file a bug against the application.
Qt Wayland had support for tablet input for a few years now, so what exactly needed fixing? The first thing is cursors. In Wayland the application tells the compositor which cursor to use. This can be done either by specifying a surface (i.e. an image) or a named cursor shape. Guess which one Qt used? That’s right: Neither. It just didn’t specify a cursor at all. The result depends on the compositor: KWin would display a cross-hair cursor as a fallback, which is ~okay, but not the cursor the application developer asked for. On other compositors I’ve tested there will be no cursor visible at all, which isn’t okay at all. For Qt 6.8 I implemented the missing cursor support, so now tablets get the same cursor as mouse input (unless of course the application developer wants a different cursor for tablet input).
Another thing that affected mostly non-Plasma users is client-side decorated windows. On Plasma Qt applications usually use the server-side decoration provided by KWin, but e.g. on GNOME Qt is responsible for drawing and handling window decorations. For this Qt features a plugin system so different decorations with different look-and-feels can be swapped out. Unfortunately those decorations didn’t handle tablet input at all, so it wasn’t possible to move around or close windows using a tablet stylus. I fixed this by pretending the tablet input is mouse input to the decorations, which was a simple yet effective solution for the issue. If there is ever a need for decorations to treat tablet input different to mouse input we can revisit this.
Talking about moving windows, a feature most KDE apps have (even if off-by-default these days) is dragging any empty area to move the window. This wasn’t working when using a stylus. Why? For that we need to look at how this works on a Wayland level. The xdg-shell protocol (the one responsible for most application windows) has a move request that asks the compositor to start a move interaction for the window. As part of the request the application must pass a serial, which is a number that corresponds to the last input event the application has received. To avoid applications suddenly deciding to move in the background compositors usually only allow move requests as a result of direct user input, so this serial must match the last input event. Qt wraps this move request inside the QWindow::startSystemMove function. The problem was that Qt didn’t keep track of the serial it received as part of tablet input, so when starting the move it would pass a wrong serial and the compositor (rightfully) refused the move. A few extra lines later the serial was tracked properly and moving windows with a stylus worked, just in time for Nate to disable the feature by default.
The same problem also affected drag-and-drop. When starting a drag with a stylus Qt now passes the correct serial, making drag-and-drop work (at least on the Qt side, there currently is a bug on the KWin side that prevents this from working).
The last fix for today relates to how applications react to the tablet events. Sometimes applications process clicks differently depending on what keyboard modifiers are pressed. For example pressing Ctrl while clicking on files in Dolphin allows to select multiple files. For this to work Qt conveniently delivers the active modifiers with every input event. Alas for tablet input the modifiers got lost along the way, so it wasn’t possible to select multiple files using a stylus. One small fix later it works as expected.
That’s all the Wayland tablet related fixes for today. If you find more issues in Qt/KDE apps related to tablet input on Wayland please report them on bugs.kde.org and I’ll look into them.
That’s not all there is about Wayland tablet improvements though. Fully in the spirit of the “We care about your input!” Goal there are exiting things happening on the KWin/Plasma side that I’ve been involved in. Stay tuned for more!
In my position of Software Platform Engineer at KDE I work on common building blocks for KDE software, like Qt and KDE Frameworks. This work is possible thanks to your generous donations. Check out our end-of-the-year fundraiser if you’d like to see more work like this.
Make sure you commit anything you want to end up in the KDE Gear 24.12
releases to them
Next Dates:
Let’s go for my web review for the week 2024-45.
Tags: tech, democracy
I didn’t know the voting rolls were public record in the US… this is a really bad idea.
https://www.404media.co/voted-in-america-this-site-doxed-you/
Tags: tech, networking, security, protocols
Looks like there are people out there to get Tor relays down… and they found a smart networking trick I’d expect to not work anymore.
https://delroth.net/posts/spoofed-mass-scan-abuse/
Tags: tech, xmpp, ux
Could XMPP make a come back if the user experience was better?
https://adele.pages.casa/md/blog/xmpp-the-forgotten-gem-of-instant-messaging.md
Tags: tech, protocols, fediverse, governance, decentralized
Interesting explanation of the different visions and governance behind ActivityPub and ATProto.
https://fediversereport.com/a-conceptual-model-of-atproto-and-activitypub/
Tags: tech, syncing, data
Interesting dimensions to use when classifying syncing solutions and to see which ones will meet your constraints.
https://stack.convex.dev/a-map-of-sync
Tags: tech, databases, data-science
A good reminder that I should probably evaluate DuckDB for some of my tooling.
https://pgrs.net/2024/11/01/duckdb-over-pandas-polars/
Tags: tech, systemd, embedded
This is a good point. systemd is kind of turning into a monoculture, but what are we loosing? Indeed, right now things could be better on deeply embedded systems (I insist on the “deep embedded” here which is often more limited in resources). Unlike the author I think they could be improved and they don’t quite apply to a good chunk of recent embedded platforms though.
https://kevinboone.me/systemd_embedded.html
Tags: tech, databases, sqlite, tools, syncing
If you wonder how the protocol is designed and how the actual implementation works, this is a nice introduction. Clearly it’s helped by the size of that program which is fairly small.
https://nochlin.com/blog/how-the-new-sqlite3_rsync-utility-works
Tags: tech, c++, complexity
Good illustration of how the C++ language complexity is out of hands.
https://azeemba.com/posts/cpp-complexity-compiler-bugs.html
Tags: tech, c++
Still, C++ improved in recent years. The problem is that we tend to stick too much to the old constructs we already know and that things keep piling up but nothing is removed.
https://lemire.me/blog/2024/11/02/having-fun-with-modern-c/
Tags: tech, html, accessibility, low-tech, complexity
A nice subset of HTML to ensure better accessibility and reduced complexity.
https://smolweb.org/specs/index.html
Tags: tech, web, frontend, html
Each has a use, they shouldn’t be conflated. It makes for poor user experience and accessibility otherwise.
https://marijkeluttekes.dev/blog/articles/2024/11/04/html-link-or-button-that-is-the-question/
Tags: tech, remote-working, management, product-management
A bit biased toward stable product teams only. Still, there are good tips which are more widely applicable here. This gives a good idea of the management of a distributed team of remote workers.
https://matt.blwt.io/post/long-distance-relationships/
Bye for now!
I spent past three weeks working on refactoring and fixing legacy code (the oldest of which was from 2013) that handled positioning Plasma desktop icons, and how this data was saved and loaded.
Here's the merge request if you're curious: plasma-desktop: Refactor icon positioner saving and loading
The existing code worked sometimes, but there were some oddities like race conditions (icon positioning happens in weird order) and backend code mixed in with frontend code.
Now I am not blaming anyone for this. Code has tendency to get a bit weird, especially over long periods of time, and especially in open source projects where anyone can tinker with it.
You know how wired earbuds always, always get tangled when you place them in a drawer or your pocket or something for few seconds? Codebases do the exact same thing, when there are multiple people writing on things, fixing each others' bugs. Everyone has a different way of thinking, so it's only natural that things over time get a bit tangled up.
So sometimes you need someone to look at the tangled codebase and try to clear it up a bit.
When going through old code, especially some that has barely any comments, it can take a very long time to understand what is actually going on. I honestly spent most of my time trying to understand how the thing even works, what is called when, where the icons positions are updated, and so on.
When I finally had some understanding of what was happening, I could start cleaning things up. I renamed a lot of the old methods to be hopefully more descriptive, and moved backend code — like saving icon positions — from the frontend back to backend.
Every screen (PC monitor, TV…) tends to have it's own quirks. Some, when connected with display-port adapter, tell your PC it's disconnected if your PC goes to screen saving mode. Some stay connected, but show a blank screen.
One big issue with the icon positions was that when screen got turned off, it thought there was no screen anymore and started removing items from the desktop.
That's fair. Why show desktop icons on a screen that is non-existent? But when you have a monitor that tells your PC, "Okay I'm disconnecting now!" when the PC says it's time to sleep, wrong things would happen.
This condition is now handled by having a check that if the screen is in use or not. Now when screen is not in use, we just do nothing with the icons. No need to touch them at all.
Our icon positioning algorithm uses something called "stripes."
Every resolution has it's amount of stripes. Stripes contain an array of icons, or blank spots.
So if your screen resolution is, let's say, 1920x1080, we calculate
how many stripes and how many items per stripe will fit on that screen.
@marcdeop:matrix.org
soumyatheman
GSoC
nicofee
Stripe1: 1 2 3 4 5 6 7
Stripe2: 1 2 3 4 5 6 7
Stripe3: 1 2 3 4 5 6 7
And so on..
But when you change your screen resolution or scale factor, how many icon stripes you have and how many icons fit on each stripe will change.
So if you have one of those screens that looks to the system like it's been unplugged when it goes into
sleep mode, previously the stripe amount would change to 1 row, 1 column. And the icon positioner would
panics and shove all icons in that 1,1 slot.
Then when you'd turn the screen back on, the icon positioner would wonder what just happened and restore the proper stripe number and size. But by that point it would have lost all our positioning coordinate data during the shoving of icons in that one miniscule place, so instead it would reset the icon positions… and this leaves users wondering why their desktop icon arrangement is now gone.
Here we have to also check for the screen being in use or not. But there were other problems.
The prior code saved the icon positions every time the positions changed. Makes sense.
But it didn't account for the screen being off… so the icon positions would get saved while the desktop was in a faulty state. This also causes frustration because someone arranges the icons how they wish, but then screen does something weird and they're now saved in wrong places again.
Our icon positions were updated after almost every draw call, if the positions changed. So this would mean the saving would happen rather often and no matter what moved them.
We had to separate the user action from computer action. If computer moves the icons, we ideally do not save their positions, unless something drastic has happened like resolution change.
The icon positions are saved per resolution, so if you move
icons around while they're displayed on a 3440x1440 screen and then change the resolution to 1920x1080,
both will have their own arrangements.
This part of the codebase did not previously work, and it would always override the old configuration,
which caused headache.
So now we only save icon positions when:
This makes the icon position saving much less random, since it's done only after explicit user actions.
The last thing that caused headaches with the icon positioning was that the area available on the desktop for icons was determined before panels were loaded. When the panels loaded, they would reduce the amount of space for desktop icons, and that area would constantly resize until everything is ready.
In previous code, this would cause icons to move, which updates positions, which then saves their positions.
So let's say you arrange your icons nicely, but the next time you boot into plasma, your panels start shoving the poor icon area around and the icons have to move out of the way… and now they're all in the wrong places.
This was already partially fixed by not saving when the computer moves the icons around: we just load the icon positions when the screen is in use and we are done with listing the icons on the desktop. Part of the margin changes happen when screen is off.
We still need to fix the loading part; ideally we load the icon area last, so that it gets the margins it expects and doesn't shuffle around while panels are still appearing. But it was out of scope for this merge request.
It may not sound like much, but this was a lot of work. I spent days just thinking about this problem, trying to understand what is happening now and how to improve it.
Luckily with a lot of help from reviewers and testers I got things to work much better than it used to. I am quite "all-over-the-place" when I solve problems so I appreciate the patience they had with me and my questions. :D
What I mostly wished for when working on this were more inline code comments. You don't need to comment the obvious things, but everything else could use something. It's hard to gauge what is obvious and what is not, but that kind of answers the question: If you don't know if it's obvious or not, it's likely not, so add some comment about it.
I do hope that the desktop icons act more reliably after all these changes. If you spot bugs, do report them at https://bugs.kde.org.
Thanks for reading! :)
PS. The funniest thing to me about all of this is that I do not like having any icons on my desktop. :'D
The last maintenance release of the 24.08 series is out. We fixed some issues, so project opening should be working again.
While I do have a Qt git build on my machine that I use for development, I usually only test individual applications and functionality but hardly ever run my full Plasma session on it. This means that for day-to-day use I typically only get to enjoy new Qt features once they have actually been released.
One feature I talked about in the very last issue of “On the road to Plasma 6” is a nice API for XDG Foreign. To recap: it’s a Wayland protocol that lets an application export a window to another one so it can can attach a window to it. For example, the XDG Desktop Portal wants to attach the “Open File” dialog as if it were coming from the application that requested it.
Of course we don’t want to write low-level Wayland code and instead have an easy to use API for it. The KWindowSystem::setMainWindow function does just that: hand in a window and the token you received from the other application (created through KWaylandExtras::exportWindow) and it takes care of everything else. Presumably, you want to set the parent window before showing your dialog to make absolutely sure it’s set up properly.
However, Qt did not have an API to tell us when the underlying XDG Toplevel (think: a regular desktop-y window with a title bar and what not) had been created. We were only told when the basic wl_surface was created, which was too early, or the window was exposed/shown, at which point it was already flashing up in the user’s task bar. Hence, I added a new QWaylandWindow::surfaceRoleCreated (and corresponding surfaceRoleDestroyed) signal. Utilizing that, the aforementioned KWindowSystem API now works perfectly.
Another major addition to Qt Wayland that I have been looking forward to very much is support for the XDG Dialog protocol. While a window could have always had a parent (e.g. a popup menu or settings dialog parented to the application’s main window), there was no concept of a “modal” dialog. Therefore, we did not support the “dim parent” effect under Wayland that darkens a window to indicate it cannot be interacted with. More importantly, KWin couldn’t take it into account for its focus handling either. It happily let you focus a blocked window but the application would then just ignore your input.
This was most noticeable for me when Alt+Tab’ing back and forth, for example using the “Open File” dialog in one application and then trying to switch to the other to verify where the file was actually located. Instead of cycling between the file dialog and the other application, it would alternate between the file dialog and the blocked main window.
Sadly, even when I upgraded to Qt 6.8 the situation didn’t improve. I noticed that Alt+Tab actually showed the dialog twice. This looked like a bug and sure enough comparing it to the Plasma 5.27 LTS session on my other computer proved that it used to work at some point. At first I didn’t spot anything obvious until I noticed a small typo that must have slipped in during some major refactoring. Instead of not including the main window when it had a modal child, it included the modal child once again! Sure enough, adding an exclamation mark (the logical NOT operator in C++) did the trick.
If you want to support more good people such as myself, consider donating to the KDE End of Year Fundraiser!
