KDE Plasma Desktop 4.11's new Task Manager

One of the many things to look forward to in the impending KDE Plasma 4.11 release is a new version of the default Task Manager applet, which had its front-facing bits rewritten from scratch, along with additional support work and improvements in the underlying library.

The motivation for the rewrite was two-fold: Address many long-standing and gnarly bugs the old applet was suffering from, and to pull the Task Manager forward into the QML era, making it ready to transition to Plasma 2. Visual and interaction changes were to be kept to a minimum for now, focusing on a regression-free port, but a leaner and meaner codebase along with QML's designed-in flexibility should make a much better foundation for future experiments.

Let's take a look at some of the improvements over the old applet :).

Side bar: The art of putting tasks on screen

The 4.11 Task Manager
There's a lot going on here.

Laying out a task manager is complicated business. Task items have preferred minimum and maximum sizes in both dimensions, derived from the current theme and font settings. This size range information factors into calculating when to break into additional rows (or columns), provided the available space and user settings allow for it. Layout also behaves akin to justified text layout, dividing available space between tasks evenly even when wrapping into multiple rows - but not allowing them to grow beyond their preferred maximum size.

The addition of launcher items complicates things further, making it necessary to carefully negotiate the peaceful graphical co-existence of two different types of items with different preferred sizes, throwing the easy assumption that all items are going to be the same out the window.

Layout also doesn't just have its internal concerns to worry about, but some external ones as well: It has to keep track of when it considers the Task Manager to be full (again drawing on the preferred size range information) and communicate that to the machinery that will try to opportunistically group windows to conserve space. It also has to generate useful size hints for the applet, allowing for things like Plasma's auto-growing/shrinking panels to work correctly.

And then all of that has to work well in both horizontal and vertical orientations, with some subtle differences to tune things for both cases.

Layout: A lot better now

Unfortunately, the old applet didn't do so well on mastering the above. Its layout code suffered from many, many bugs, ranging from just making bad placement decisions to getting stuck mid-animation to causing hangs due to infinite loops. Consistency between horizontal and vertical layout wasn't very good, with support for vertical orientation introduced via copious special-casing and being perennially out of sync with the better-maintained horizontal codepaths.

Layout is also involved with reordering tasks by Drag-and-Drop (if sorting is set to "Manual"), and in the old applet, would occasionally compute incorrect indices for the reinsertion of dragged tasks, particularly at the end of rows and when right-to-left locales like Arabic and Hebrew were used. DND across multiple rows was also a bit crashy.

Many of these bugs only surfaced in somewhat unusual configurations, with the general theme being that new layout features had been added without enough attention being paid to how they would interact with all of the permutations allowed by the feature matrix, not just the most common cases. An example would be combining the presence of launchers with multiple rows, illustrated here:

Layout bug
Layout gone bad: Launchers larger than tasks ...

Layout fixed
And now it's good.

All of these bugs should hopefully be resolved by the new version's layout engine.

Consistent interactions

Not just layout behaves more consistently across features and configurations now, interacting with the Task Manager does, too. For example, the popup for window groups now supports switching between tasks via the mouse wheel and reordering tasks by dragging (again, provided sorting is set to "Manual"), just as the primary UI does.

Speaking of those group popups: Up until now, they weren't smart enough to adjust their size as windows came and went or window titles changed, and if windows set very long titles for themselves, the resulting popups could sometimes show up with unreasonably large sizes. They're much smarter now, handling these situations properly.

Group popup
Group popups learned many new tricks.

Visual fixes and polish

Task buttons have frames (depending on your theme, they come in less or more varieties), and those frames aren't purely decorative - they're used to communicate important state like the identity of the active window. The old applet had several bugs in the code handling button frames, sometimes causing it to claim multiple windows as active or forgetting to reset a frame after a task context menu had been used. These kinds of bugs are gone now.

Task buttons also (well, usually - if layout thinks it has enough space for them!) have text labels with nifty-looking shadows behind them - which the old applet sometimes forgot to re-render for text changes, namely when the font settings were changed. Poof, gone as well.

Themes are also generally applied more correctly now, e.g. taking frame margins into account when making decisions on the size of elements inside them.

Playing nice with the rest of the Workspace

The Task Manager is also responsible for communicating task item positions to the window manager, so the window manager can know the destination for the minimize animation of a window. The old applet sometimes dropped the ball on this duty, causing KWin to animate windows minimizing into the center of the screen, or into outdated positions. Once more I'm happy to report the new version should take this obligation a lot more seriously.

Configuration handling

The old applet would occasionally be reluctant to apply changed settings immediately, e.g. toggling the "Force row settings" option wouldn't take effect unless the value for the "Maximum rows" setting was changed at the same time. Its successor suffers from no such compunctions.


QML is kind to us here, and it's not even the shiny OpenGL-powered Qt 5 version yet. Animations are generally a bit smoother across the board, and specifically the throbber/spinner animation used in place of the icon on task startup notification items sports a much higher frame rate than before.

Startup notification throbber
It may be hard to tell from a still image, but it's spinning a lot more smoothly now.

There's also some bad news (with a side dish of glimmers-of-hope)

Sadly, a few features didn't make it into the new version - yet, at least.

One is the ability to drag tasks from the Task Manager onto the pager, a very nifty way to move windows between virtual desktops. That this wasn't retained is down to a limitation in the components we implemented to teach QML Drag-and-Drop support; I've proposed a patch to address it in Plasma 2 that may even be back-portable to KDE 4, so stay tuned for 4.11.1 possibly addressing this.

The other two are support for manual grouping and uncollapsing groups into an inline representation in the primary UI. Both seem to have relatively few users, partly due to unfriendly interaction design: Figuring out how to actually manually group windows generally took an internet search to learn about the necessary keyboard modifier. That doesn't make the regressions any less regrettable, of course, but on the other hand we will try to bring these back in much improved incarnations in Plasma 2 (or perhaps sooner). It's part of the reason why they didn't make it yet - both features had some fundamentally bad aspects to their current realization, and burdening the new codebase with their complexity was thoroughly unattractive from a cost/gain perspective. We'll do better.

Future plans

The new QML-powered Task Manager is here to stay - this is the codebase we're taking into Plasma 2, delivering on our intentions to make the transition to KDE 5 a more iterative, less disruptive one. The regressions mentioned above imply some open to-dos, and beyond that we'll be investigating new features and ideas, such as allowing apps to do more with the context menus of their launcher and task items.

Meanwhile, the move to Wayland will cause some further work as well, below the visual level this time, adapting the underlying library to KWin becoming the new authoritative source for window data.

I'm hoping you'll enjoy the new 4.11 Task Manager. If you've got any fancy ideas: Throw them my way in the comments!

PS.: A few of the things described here took final form quite late. If you have a problem with the Task Manager in one of the betas or RCs, take the above as an update on what you can expect from the final release.


Few things what I remove from my and (most senior) clients computers is window decoration buttons to minimize and maximize window and I only leave (usually) the close button.

As window decoration buttons are very illogical when you want to maximize or minimize window (this from new computer users standpoint) as task manager is separated from the window(s) and for user a window is the content what they use and they don't see the connection between task manager and window(s).

For many the minimization function is multiple times "What happened, where is my window?" function as they don't see the connection on small button on top right corner and bottom at task manager. And you show multiple times the minimization button to minimize window to task manager and clicking task from task manager to bring it back, they ask "Why I cant just click it down there?" as they get the idea to hide window down instead closing it again but not the idea.

The problem with the task manager is how it works when window is active and when it is inactive. As user does selection of active window trough task manager by clicking a inactive window but then again minimize the window to task manager when window is first active.

I would like to ask about how to get a change to minimize inactive windows from task manager with single click? It is totally different what has been there since Windows 95 or System OS (don't even remember the version) since when it has been in current logic that clicking inactive window activates it (raise it front of the other window(s) and un-minimize it as well).

Example I would like to see function where using mouse wheel over task on task manager would minimize window no matter is it active or inactive. And mouse wheel up would un-minimize window back no matter is task inactive or active.
This way mistakenly minimizing window would not happen and left clicking would only be managing tasks position and context menu (previews by hovering etc).

I don't know statics how many users use task manager to switch between windows unless they don't have access to that window at that moment (small window behind big/full screen window OR window is on other virtual desktop/activity than current one) but I believe there is a need to add new kind feature to minimize/restore windows to/from task manager other than clicking once if active window or twice if inactive. As alone making minimization only happen trough task manager has helped lots of people to understand at once the logic of task manager and that they don't need to close window everytime they want it to go "away" taking screen space and then later restarting application and working with it to return last status.

By Fri13 at Mon, 07/29/2013 - 06:59

In Fancy Tasks it's possible to set custom actions for tasks (including minimize, which could be set as action for left button), although only mouse buttons with optional keyboard modifiers.

By Emdek at Mon, 07/29/2013 - 07:44

It looks much better. I do have a few suggestions, though (may or may not be good ones).

1. It might be better to group all the launchers to the left of the tasks, even in multi-row mode. So if you have two rows, you get two rows of launchers on the left and two rows of tasks on the right. That should make it both easier to layout and also make the launchers look more visually grouped, making it easier to identify and target them compared to the current layout. At least for me the launchers in the screenshot don't jump out at me, I have to focus my attention to find them.

2. There doesn't seem to be a button to close tasks from their thumbnails (but maybe I am remembering incorrectly and this was only ever a feature of icon tasks).

3. The thumbnails only list the application name when there are multiple windows, not the name of each window

4. The thumbnail size is independent of screen size, so on my 1920x1080 laptop screen they are tiny (less than twice the size of the panel itself).

5. The highlight window option doesn't seem to be compatible with the list menu you get on click, the highlighted windows cover the menu

6. Launcher icons don't seem to rescale properly, they are always tiny.

Also, has Icon Tasks been ported, or will it be ported?

By toddrme2178 at Mon, 07/29/2013 - 08:04

> 1. It might be better to group all the launchers to the left of the tasks [...]

See https://bugs.kde.org/show_bug.cgi?id=321128#c16

(Summary: Had the same idea; it's on the table; actually a bit more difficult to do than the current behavior since it involves two containers having to negotiate on number of rows while the size of one depends on the size of the other.)

> 2., 3., 4.

Window preview thumbnails are managed by Plasma's tooltip code, the Task Manager isn't involved with them. I'm unhappy with this layering and we're hoping to fix this in Plasma 2, allowing the applet to do more. Icon Tasks does it by forking/reimplementing substantial amounts of core Plasma C++ code, which would have been a bit silly to do in a QML rewrite :).

> 5.

Please file a bug ticket - this is likewise unlikely to be a regression because the underlying window is simply a Plasma dialog, and I'm skeptical of the chances of an easy applet-side fix, but it's worth investigating.

> 6.

I'll look into that.

> Also, has Icon Tasks been ported, or will it be ported?

As far as the original Icon Tasks goes I can't speak for its maintainer, but I do plan to implement its behavior based on the new codebase,

By eike hein at Mon, 07/29/2013 - 08:22

There was a QML desktop container proof of concept. Where's that proof of concept going? The current desktop has some serious limitations and the PoC as is was very useful. Will that proof of concept be expanded? Can we have a QML desktop containment in PW1, while we wait for the real goodies in PW2?

By Alejandro Nova at Mon, 07/29/2013 - 12:55

Sebastian Kügler has been rocking away on the QML new desktop containment. I believe he's focused on Plasma 2 at this point, though ... I'll ring him to chime in here.

By eike hein at Mon, 07/29/2013 - 12:57

The QML containment is quite usable and useful on Plasma Desktop, so feel free to install it, and have fun with that. I have in fact a few people seen using it, and didn't get many complaints. You can find instructions to install it here: http://vizzzion.org/blog/2013/01/desktop-containment-moving-to-plasma-quick/

The focus has shifted to Plasma 2, however, and this particular containment has already been ported to work with Plasma Workspaces 2. It's likely going to be the default there.

By sebas at Mon, 07/29/2013 - 13:40

In fact, I noticed some issues I had with the QML desktop containment in KDE 4.10 (handles incorrectly sized) disappeared in KDE 4.11, so, thanks for such a good work, Sebastian. Also, the fact that in KDE 4.11 the new containment has no cashew has to be advertised properly.

With minor touches, your PoC can be the default for SC 4.12, while we wait until Plasma Workspaces 2.

By Alejandro Nova at Mon, 07/29/2013 - 22:04

Currently the scroll wheel switches through all windows in the taskbar, but I think a better behavior would be to have scroll up on a task widget to raise the window to the foreground and a scroll down to minimize it. This is, in my opinion, nicer than clicking because if you accidentally click on a window already on the foreground it'll minimize, while scrolling up would just keep it in the foreground (and the same for accidentally clicking or scrolling down on an already minimized window).

By José Pedro at Mon, 07/29/2013 - 19:15

Meh, I'll really miss the drag-to-another-workspace feature, I do use that semi-frequently. Any chance this might get re-added in subsequent 4.11.x versions?

By jospoortvliet at Sat, 08/03/2013 - 17:43