During the last several months, I've been rewriting the backend for Plasma's Task Manager, the strip of launchers and windows embedded into the panel at the bottom of the screen.
My current Task
What's in a Backend
The backend's responsibility is to gather (or store) pinned launchers, startup notifications and window information, and combine all that raw data into the abstraction known as tasks, forming a rough lifecycle: Launchers transition into startup notifications and then window buttons, though none of these states is technically required or guaranteed, resulting in the need to be able to match up each type of thing with any other based on what is known about them. Along the way the data is also filtered (e.g. by activity or virtual desktop), sorted (say, alphabetically, or at the user's behest, when tasks get dragged around) and optionally grouped.
The code currently performing these duties has been with us a long time—it goes back to, incredibly, KDE versions released some 16 years ago. Rewriting it finally became necessary as part of our ongoing efforts to add support for the Wayland windowing system to Plasma, as the old code was heavily tied to X11 concepts and window metadata. However it also had some fundamental limitations and problems that badly needed addressing, and was written to engineering standards we've since surpassed in the community (e.g. it wasn't unit-testable, while the new backend is written to be).
As such the new backend certainly enables the Task Manager to support Wayland, but also immediately translates to various improvements for users on X11, as well as the developer audience:
- Improved performance. On virtual desktop or activity switches, or certain settings changes, the old backend would trigger a full reset of the Task Manager UI, requiring costly reinstanciation and relayout of all the buttons. The new backend is smart enough to only make the changes necessary each time, saving a lot of cycles.
- Improved behavior, particularly when grouping tasks. The old backend could act unreliably and unpredictably at times, failing to properly reform groups after virtual desktop switches, or losing sort order for tasks in a group when the group was broken apart. A much cleaner internal implementation of grouping should do away with these sort of annoyances. Further, a key task of the backend is to determine that two different types of things (say, a launcher and a window) belong to the same application, based on their metadata—these types of equivalence checks were sometimes done in subtly different ways across different parts of the old backend, such as sorting and grouping. The new backend consistently uses the same data and business logic in all cases, making behavior more predictable. Additionally, changes made in the system Menu Editor (e.g. selecting a different icon for an application) now appear immediately in launcher and window buttons, instead of taking their time or even requiring a restart.
- Improved memory usage. The old backend would keep data for windows common to virtual desktops or activities redundantly, as well as store some icon data not actually used anymore by modern codepaths. The new backend keeps less data, and keeps it only once.
- Cleaner and more maintainable code. After 16 years of development and maintenance, the old backend had turned into a big hairy ball. Along with a lack of unit tests, this kept us from fixing some of the above issues for fear of breaking more in the process. The new codebase benefits from being written to the list of requirements gathered over all those years. It knows much better how to separate its concerns, and implements features such as sorting and grouping agnostic to the underlying windowing system. The new code being much easier to work with will also enable us to translate user feedback into Task Manager changes much more readily again.
- Improved Wayland support. While more work remains to be done to get task management to feature parity with X11, this is now largely a matter of supplying the new backend with the data it needs, feeding into upper layers ready to consume it and fully shared between both supported windowing systems. The much improved Wayland support will also enable the task management backend to be shared between Plasma Desktop and Plasma Mobile for the first time.
Now nearing completion, this new backend will undergo heavy testing and polish over the next several weeks. We hope to ship it with the upcoming Plasma 5.7 release.
Thanks for working on this!
That's why I hate reading PlanetKDE: I read about cool improvements I want to get, but always I have to wait for the next release, sometimes even longer. So I am constantly dissatisfied with the software I use :-)
That is why KDE-neon is such
That is why KDE-neon is such a good idea.
When the user .iso is ready you will get the latest KDE/QT packages hours after the release....
use an already established rolling release like Arch, Manjaro, Tumbleweed, Netrunner, KaOS, etc.
for the win ;)
That's more than welcome! Thank you for your work!
On the subject: does that mean we could finally have non-grouping same-task entries (though right beside each another, in launching order) on Icon Only Task Manager plasmoid? That is, if Firefox launches a popup/dialog, I'd not be obliged to have them grouped as the only option and having to click it's icon to see Present Windows, realize where each window went to select the one I want but, instead, I would just get a new entry beside Firefox' and switch with a single click (task manager's tooltip could help me figure out which is each in case I need, just as it is for Task Manager with texts).
This is mostly a settings
This is mostly a settings question -- a setting for this is currently not exposed, but yep the new backend can easy do it :).
I look forward to seeing the
I look forward to seeing the new version in action. Are you planning to make it more configurable? My pet peeve is the lack of an option to change the font and disable shadowing.
Those would be frontend
Those would be frontend options -- the backend isn't involved with how things are rendered. Currently there are no plans for more visual options, but that may change.
Hey, that's very nice to see,
Hey, that's very nice to see, I had a lot of issues with the spotted points here... mainly placing and re-placing of the taskbar and entries. I remember in 5.4 when I had taskbar entries just leaving behind gaps after being closed, and the taskbar being wrongly sized after docking/undocking - very complex, I understand, but annoying as well.
I have ... an uncommon request, especially on a blog. Could you look at
and tell me weather it's worth reporting as a regression? I think it certainly could be a feature regression, since for some reason some X11 "notify" signal seems to be ignored, not in sense of notifications, but in sense of "flash the taskbar now". It's 5.6 though, but I have realized this to be gone too ... I just don't remember, I had certain things running in konsole doing this but except for the feature this member wrote, I can't make up my mind on where this occurred to me.
The way this kind of thing
The way this kind of thing works on X11 is that a client (a window) sets a "demands attention" hint on itself, which gets unset when the window is raised. The Task Manager backend (both old and new) listens to window state changes and forwards this information to the frontend, which renders the task button in an appropriate style for each state.
In the case of a terminal emulator, they tend to translate terminal state (say, bell escape codes perhaps) to setting this hint.
So the options are:
- Weechat changed and no longer tells the terminal it wants attention
- Terminology changed and no longer understands Weechat's request or jusr doesn't set the hint anymore
- Window management like the Terminology window being active might interfere
I'm not aware of changes to the old backend in that area recently, fwiw.