Desktop Containment moving to Plasma Quick

As many other components of the Plasma Workspaces, Plasma Desktop’s default Containment is being ported to QML. A technology preview of the containment is being demoed and can be tested by a wider audience now. While the port is mainly replicating the current desktop containment in QML, its interaction scheme to position and manipulate widgets on the desktop has been improved.

First of all, a note: The code presented in this article is not part of the upcoming Plasma Desktop 4.10. It can easily be installed on top of it, it might see inclusion in the summer 2013 release, however

In our Roadmap, you learn that KDE is currently porting many aspects of its workspaces to QML, with the goal to create a more modern user experience on top of state-of-the-art technologies such as Qt5, OpenGL scenegraph and Wayland. The move to QML is a gradual process, made possible by the componentized architecture of Plasma. Widgets and other components that make up the workspace are replaced with QML ports one by one. The premise is to not introduce regressions by shipping each component “when it’s ready”. Ultimately, we need a complete set of QML components to run the whole desktop (and at some point also apps) directly on top of the graphics hardware, leading to higher graphics performance and more available resources on the CPU.
One of the important pieces is the Desktop containment. This is the component in Plasma that is responsible for managing and laying out widgets on the desktop and creating the toolbox (which makes some “workspace actions” available to the user. In general, a “Containment” is an area on the screen (a panel, the desktop background, the dashboard, …), and it takes care of managing widgets, their position and sizing within. It also offers access to action specific to widgets, or the containment or workspace.
The currently shipped (also in 4.10) default Desktop containment is written in C++, using QGraphicsWidgets and offers free placing of widgets on the desktop, with a bit of edge and overlap detection and repositioning poured in.

Demo movie of the new QML Desktop containment

User interaction improvements

Most of the new containment is exactly the same as in the current default — this is done by design, we do not want to introduce radical changes to the workspace (and the users’ workflows), but rather improve gradually and in an iterative process. There are two areas (which in fact are closely related) where we did change a few things: positioning/sizing and visual cleanliness. These are expressed in two changes: integration of applet handle and positioning aids.
In order to reduce visual clutter, we integrated the applet handle into the applet’s background frame. Previously, it would be its own frame, and shift out as separate element from under the widget. Merging handle and background frame reduces the number of distinct elements on the screen and allows less intrusive transitions when the widget handle becomes visible.
The second important change is that we now provide helpers when the user moves and resizes a widget. When moving, we show a halo at the position the applet will snap to when dragged. This makes widget placement more predictable and allows the user to get it right in one go. We also align the widgets to an invisible grid, so applets automatically end up being aligned pixel-perfectly with each other, which leads to a more ergonomic workflow, cleaner appearance of the workspace, and again to less visual clutter.

Platform improvements: Bindings and Toolbox

An important aspect of the work on the QML containment, was to improve the bindings which load declarative code (QML) into Plasma shells, these improvements are included in Plasma 4.10, due to be released in early february. This includes the necessary platform features to allow running fully-featured QML containments, something which we have done in Plasma Active for a while, but within a more confined context.

As a result of this work, Plasma can now also load toolboxes written in QML. The Plasma Toolbox is the little widget with the Plasma icon you can see on top of many containments, and which gives access to actions such as add widgets, settings, shortcuts, etc.. The toolbox used with the containment shown is a 1:1 port of its counterpart in the current default (C++) toolbox. The name of the toolbox package is currently hard-coded in the bindings (it loads it from the org.kde.toolbox package and silently falls back to the C++ implementation if that isn’t found — a 4.10 feature), but it also opens up this part of the workspace to QtQuick goodness. The toolbox is basically a translucent layer on top of the desktop, so much freedom is given to other implementations).

A template and a bridge

The code is not only there to replace the current containment, it also serves as a template for new developments. With the new containment bindings in place, it is now very easy to create your own containment, modify someone else’s and publish them to share them. The containment shown is just one example for what we can do with the QML integration features in Plasma. As Plasmoid packages are architecture independent, this of course works across devices and different workspaces.

The work that is upcoming in Plasma Desktop is further bridging the gap between Plasma’s interfaces for different devices and formfactors. Some of its code has been introduced in Plasma Active, and is now available in a more generic fashion also for Plasma Desktop (and Netbook). This brings us closer to one of our goals, having only one shell that dynamically loads a suitable interface (Containment, Widgets) for a given formfactor, use case, output device, etc.

Give it a spin

If you’re interested and would like to try it (we appreciate feedback, it’s especially valuable in this phase!), there are two ways to get this containment. The minimal requirement for it is Plasma 4.10-beta1.
If you’re using git, you will find the code in the branch called “plasma/sebas/desktop-qml”, just check it out and build it, install it, run kbuildsycoca4, and you’re done.
If you are using the packages, you can easily install the following two Plasmoid packages to your system:

If your system is using a version prior to KDE SC 4.10-beta1, the packages will install, but not work.

The following commands install the necessary Plasma packages into your home KDE install directory.

# create the package directory and go there
mkdir -p `kde4-config --prefix`/share/apps/plasma/packages/org.kde.toolbox
cd `kde4-config --prefix`/share/apps/plasma/packages/org.kde.toolbox
# unpack the plasmoid package
unzip ~/path/to/toolbox-git28012013.plasmoid
# check if it's installed correctly, 
# this should list metadata.desktop and contents/
ls -la `kde4-config --prefix`/share/apps/plasma/packages/org.kde.toolbox

[Edit: changes –localprefix to –prefix, as we’ve found a bug in –localprefix code.]
Then install the desktop containment package (If you’re updating the containment at a later stage, use plasmapkg -u.):

plasmapkg -i desktop-git28012013.plasmoid

You can now choose the new containment from Layout dropdown in the Desktop Settings, pick “Default Desktop (QML)” there.

I would like to thank Blue Systems for supporting my work on the above topics.

21 thoughts on “Desktop Containment moving to Plasma Quick

  1. You are doing so great job guys! I am glad to read that will be a invisible grid to help alignement.

    The only thing that disgust me (a lot), is the halo or transparend bounding box that follows the desplacement of the widget. It’s the same old case of the transparent box that follows the mouse in the combo box of the system tray hidden elements (and in other places of Kde, I don’t remember more now). It doesn’t help usability (distracts the eye focus from the mouse to that element) and aesthetically I found it disgusting too (but that is opinable, in my work all of the Kde users are annoyed for that).

    Anyway great job again, 4.11 will be amazing :)

    1. We are currently experimenting with the halo, how translucent (i.e. visible) it should be, the duration of its movement, etc. During usage, I don’t find it distracting at all, but helpful since it shows where the widget will be placed once dropped, so it makes the thing more predictable.

      The nice thing about it is that you can very easily change these kind of things now, no need to grab a compiler, no need for C++, so we might see many variations on the theme.

      1. Yes, you are right, as I wrote in other comment, the info that it brings of its placement is great, but it’s not necessary that the glow box lags behind the movement of the plasmoid, this is the thing I find annoying and that distract the focus of the eyes harming usability (the example of the system tray is even worse case, but I think here is a bad idea too, in my opinion).

        Ah, and thanks for your patience answering this and other comments :)

        1. The perceived lag is a short animation that “helps” the brain to understand what’s going on. It only takes 75ms. This is one of the things that can easily be tweaked, and we’re still looking for “perfect”, or well-balanced values.

          1. I have to agree that it’s distracting. I saw it in Plasma Active too and I always thought that the system is lagging. It’s not helpful if it moves at some distance behind the cursor as that would only show where it would been place if I drop it a few milliseconds earlier. My brain want to know immediately where something will be place.

            I think the perfect way it to check the underlying grid and highlight the cell where it will be place. Good examples of the are the preview placement of Qt dockwidgets or the system in WordPress.

            I think it’s a big mistake to animate anything that has to keep up with a cursor.

          2. After thinking it a lot (as I did with the other example I talk about) I still think this animation forces the eye to refocuse from mouse to animation to mouse harming usability. In my opinion your idea of the exterior glow is great enought to communicate the user that a snapping is happening (even without a auto-snapping as it happens on design programs, its easy to perceive bye the user, but your external glow is a nice improvement).

  2. Thank you for this update. I have been very curious as to the containment and panel QML progress. This is a clearl improvement on what we have. I love the applet handle and the snap+halo effect. It will make interacting with the desktop easier, more beautiful, and more fun. I really look forward to trying this out soon!

    Great work!

  3. Awesome work! Really love it. I always hated the applethandle but the new solution makes it appear clean and unobstrusive. And with the QML port we get a bonus point: The applet handle also closes when leaving the applet via a window (ie. move a window, partially covering a widget, hover the widget and then move the mouse over the window. Result is, the applethandle stays there) which was annoying.
    Could the gridSize become user-configurable? And it should be smaller by default, like 8px or so, 24 is way too rough imho.

    1. I’m still experimenting with the ideal grid size, but won’t make it configurable. I just don’t want to introduce configuration options, and, while using it, it really doesn’t make a huge difference, as long as the grid is within certain bounds. (It will probably be easy to change it in the .qml files, of course.)

      8px as you suggest probably won’t be possible anyway, since the FrameSvg’s borders with Air are already much larger.

  4. The halo would be great if it doesn’t lag behind the real position, its usefull because it shows how it will snap, but I think harms usability if it lags behind as I comment before .

  5. This turned out to be a complete disaster.
    * I can not freely place plasmoids any longer, but is forced to use what margins YOU like – not what I like. There need to be an override for that rigidness!
    * Plasmoids that have shifted angles does not work with this code. the toolbox is misplaced, and switching angles are impossible.
    * It did not pick up the current settings when an activity was switched over
    * I can not alter the settings for the activity I tried with any longer, the configure entry of the desktop context menu is greyed out.
    * The activity manager is now empty

    So good that there is time to work on this before release. Maybe wait for 5.0!

    1. Well, bugs are the reason why I’ve made it available already. It’s definitely too soon to point it to a specific release yet. You can still find the configure entry in the toolbox, by the way. It being greyed out in the context menu is a known bug.

      What do you mean with “shifted angles”? The widgets have a rotate button (interaction is a bit wonky), but it worked fine “on my machine”, so we’d need to sort out what’s going on there. What current settings when an activity is switched are you referring to? (The containment is switched along with the activity.)

      The margins are mostly dependent on the theme.

      I understand some of the comments you have, but not all. As we’re already talking on IRC, we can sort it out there. :)

      1. Well, by “shifted angles” I meant “rotated”. This problem is very bad with the pictureframe plasmoid.

        After using the qml desktop, both my activity manager and plasmoid list (the widget displayed when “add widgets” is activated) were empty, and I ended up deleting all plasma/activity configuration, since noone had a working cure. Could it have to do with removing the toolbox package installed to test the qml desktop?

        1. No, we found a bug in the path resolution of packages. I’ve changed the instructions in the article above and am now looking into this problem.

  6. Help needed to recover!

    I can not get the activity manager to work any longer, it comes up with an empty window.
    I need to delete the activity that I switched to the QML desktop and recreate it so it becomes usable again.

  7. another piece that fits in the great picture!

    so welcomed are the new design and usability improvements, but you could push them a little further:
    I still see the toolbox: isn’t right-click-on-desktop pop-up menu a good enough replacement?
    the locked/unlocked mode: possibly overtaken by sensitive borders, select-on-mouse-overlay delay?

    I know these are largely debated topics, but.. that’s it! :)

    1. The actions on mouse click can be changed to not show a menu on right-click on desktop. So the toolbox is a an always available and no matter how you configured your desktop reliable way to get to the menu.

      In addition the toolbox provides more as it also shows the activity name and is a “show desktop” feature when clicking.

  8. If I install this as a new user will this leave my original user settings untouched?

    I tried as my normal user and found that the add plasma widgets bar became empty. I had to delete .kde to get things back to normal.

    I definitely want to help test cool new things out but don’t wanna risk my settings!

    1. Don’t install the toolbox as a user, install it into the system installation. I’ve changed that in the installation instruction to install the toolbox to the system prefix, with that you’re fine. Also no need to ditch your ~/.kde, just removing the directory `kde4-config`/share/apps/plasma/packages would have been enough.

      If you install it as a new user, it will still be available in the system, as soon as you remove the toolbox and the desktop containment package, you’re clean again, however.

      We’ve hit a bug when Plasma/Generic packages are installed locally (that hasn’t been done yet, and our tools don’t support it as this point. A patch is in the review queue right now, so soon, also that will be fine.

Comments are closed.