What’s going on in Plasma Workspaces 2?

While moving its codebase to Qt5, the KDE Development Platform is undergoing a number of changes that lead to a more modular codebase (called KDE Framework 5) on top of a hardware-accelerated graphics stack. In this post, you’ll learn a bit about the status of Frameworks 5 and porting especially Plasma — that will be known as Plasma Workspaces 2, paying credit to its more convergent architecture.

Let’s start with something visual, before we get to the nitty-gritty:

Video showing a basic port of a Plasma Desktop Containment to Plasma 2

Frameworks 5

A whole bunch of libraries can now be built, installed and packaged separately. Those include (in tier1) Solid, Threadweaver, kdecore, karchive, kwindowsystem, and more, and in tier2 kauth and kconfig. Plasma has already moved into its own repository, and can of course also be built separately.

Kevin has been plugging away at removing problematic interdependencies between those libs, and recently could ditch (i.e. move to kde4support) a few classes that make it easier to just use Qt machinery (QApplication & friends) to bring up “KDE applications”. KAction has gone, KAboutData, so KDE Applications are now less “special” in the Qt world — a good thing for portability.
Splitting and untangling kdeui from kdelibs proves to be a bit more work- intensive than initially hoped. Fracture lines are becoming visible. The problem here is that this task is holding up the parallelization of development, so this has a high priority right now.

We’re also using a continuous integration system now to keep us on our toes with respect to “buildability” (which can be a bit daunting with so heavily shifting ground in kdelibs, this will calm down at some point though).

Video showing a Plasma 2 OpenGL shader demo widget

Plasma & KWin

Good progress, especially in the last month, in three areas:

API reviews: we’ve been doing weekly sessions for libplasma2 API reviews, where we’re going through the entire API and think about improvements for the Plasma 2, post-graphicsview world. As a result, libplasma2 has shrunk to about 1/3 in (compiled) size in its current state. We don’t expect it to grow much, since, in the scenegraph world, it plays another role than previously (although developers used to QML won’t really notice). (Join in the Hangout, if you like, we usually start on Monday morning around 10.00 UTC, just pop up in the #plasma channel and ask Marco to invite you). Our mutual status updates and Cool New Development is recorded and made available on Youtube for interested people, Last Monday’s session can be found here, but today we skipped it — you get this more detailed blog post in return. :)

Imports: Basically our QML runtime, it consists of Plasma Components, extras, bindings for things like dialog, framesvg and dataengines, drag and drop, krunner models, and a bunch of other stuff. I’m working on this right now, and have about 95% of the imports originating from kde-runtime working in Plasma2. We’ll be able to offer almost the same API to Plasma2 QML users, as in Plasma1, so porting of your QML code will be very easy.

Shell: In Plasma2, instead of having specific plasma-desktop, plasma-netbook, plasma-device shells, we will use one “generic” shell that loads containments (which then load applets), wallpaper, toolbox, etc. The shell can dynamically replace these components (change wallpaper, for example).

A few things are new here: in Plasma2, plasmoids provide their config ui via QML files, that are part of the package. That solves the problem that we could not really influence the behaviour of the configuration UIs from QML in Plasma1. It will also allow to transparantly switch between instant apply and “OK/Apply/Cancel” buttons, depending on what fits the usecase. Marco is on this.

Martin has been pushing the removal of the direct X dependency further through porting to XCB. He’s also recently started on a Qt5 port. One problem with KWin is that Martin needs a bunch of changes to have QtQuick and KWin run in the same process, that means making sure that KWin and Plasma (or QtQuick2 really) properly share and interact in the same OpenGL context. There’s a chicken-and-egg situation for kwin, since it needs to load for example window decorations and task switchers (both from QML) to be useful, but it can’t right now. The X11-based windecos won’t make it into Plasma2, so we’d rather avoid porting them just for the time being. Martin is on that though, and he earns our gratitude for going through this painful period in the porting procedure.

16 thoughts on “What’s going on in Plasma Workspaces 2?

  1. The X11-based windecos won’t make it into Plasma2, so we’d rather avoid porting them just for the time being.

    Obviously, if one wants to have the decos in Plasma2, it can easily be ported. It’s just me is not going to port decorations we wanted to kick for quite some time.

    Oxygen and Aurorae are not affected – they will be ported. Though at the moment I have the deco building disabled as it’s only running on error ;-)

  2. Looks cool but why are you talking about Plasma Workspaces 2 when the current version is 4.10. To this day we have a hard time communicating the branding of KDE=community and when we have to explain now that after 4 follows 2, it’ll be a nightmare. Why not refer to it as PW5?

    1. In general, we refer to the currently released (lib)plasma as Plasma 1, and to the next version (which we’ve named libplasma2 as Plasma 2), or Plasma Workspaces 2.

      By the way:

      miro.sebas(~): plasma-desktop –version
      Qt: 4.8.4
      KDE Development Platform: 4.10.00 “release 1”
      Plasma Desktop Shell: 0.4

      Don’t get too hung up on the name though, there will neither be a PW2 or 5 if the code doesn’t get written. :)

      1. Sebas, your example seems to be confirming what Kamikazow said, that the current version is 4, and your next (might) be two (but might report in the command line that it is 5).

        You may call it Plasma 1, but the rest of the world calls it KDE4.

        1. …and thereby stabbling us, and our branding efforts in the back.

          There’s a reason why we do not call it KDE4 anymore. For your convenience, let’s go over this once again:

          The community has grown to big to put everything it does into one big release. We’ve seen this tendency around KDE3 times with Extragear, 4.0 showed it in a very painful way: The platform was ready, many apps were fine, the desktop shell was not up to the task — yet its bad quality made the whole of “KDE” look bad, while it was really Plasma that caused the uproar.

          This is exactly what we’re trying to fix, we’re untangling the different products, so they are perceived as that. This is nothing more than bringing our naming in line with reality, with what makes sense, and clarifying our structure in our naming.

          You can be all “I’ll keep doing it like I want”, but that simply suggests to me that you’re not understanding why we’re are doing this, or, and that would be a lot worse, you get kicks out of throwing sticks into our wheels.

          As to my example: You are sure you read *and* understood it? The development platform is at 4.x, and that’s different from the program version. This is the same for many other apps (I’ll leave it up to you to verify it, it’s really easy!) and has been like that forever.

          I realize that discussing version numbers are a fine way to spend your time, I don’t consider it a productive way to spend my time over and over again. It’s a shame you lack the respect for that.

  3. Great news, any schedule? Is it possible that 4.12 could become plasma2/qt5? What about system resources? Is it possible to get even lighter & faster KDE? (log-in time is a major PITA even on high end pc and it’s been this way for 5 years, also application could start faster). I’m glad you get rid of this “plasma-netbook/etc” crap and bringing one good configurable desktop :)

    BTW I heard that plasmoids can use javascript, will it affect system load and responsiveness?


    1. Plasmoids can use and do use JavaScript today, in 4.10. Performance with QML Plasmoids seems fine so far, maybe even a bit better with graphically heavy ones as we can offload much of the work to get the pixels on the screen to the GPU.

      1. My experience with pure QML-plasmoids (pure = no C++ involved except in the data-engines they use) is that you can make them (almost) as fast as the C++ version. But you have to pay extra attention to optimize your code: you should delay loading any Item until it must be shown (for example in my AppMenu QML plasmoid, if the favorites are unlocked, an “Add to favorites”, “Move favorite up”, “Move favorite down”, … button appears on the hovered menu-item; if the plasmoid would load those buttons on all menu-items even before they are shown, then my plasmoid would be slower; one can also notice a speed-up in loading the plasmoid and showing the submenus when the favorites are locked and thus those buttons are never loaded), you should avoid loading large images (for example in my Luna QML plasmoid, if I would load the luna.svgz file (which contains the images for all moon-phases) entirely and only show the correct element, then the plasmoid would start much slower than when I cut the svg-file in 28 svg-files (one file for each moon-phase) and only load the correct svg-file), you should also pay attention to your JavaScript code (there was one for-loop in the C++ code of the original Luna plasmoid which did a lot of superfluous calculations, that was not a big problem for the C++ plasmoid because C++ is fast, but after optimizing this for-loop for the QML+JavaScript version, the speed difference was noticeable), you should avoid JavaScript as much as possible and depend as much as possible on data-engines (which are written in C++). In kde-workspace trunk there are some hybrid QML/C++ plasmoids, where the heavy work is done in the C++-part. This is also a good idea to make the plasmoid fast, but I don’t understand why the authors did not make a data-engine instead (for things like “Recent Documents”, “List of places”, taskbar with screenshots, …; these are things that a 3rd-party plasmoid developer would also be interested in, now the 3rd-party developer has to reimplement all that stuff).

        1. Dataengines are shared across the whole system, so one dataengine can provide the data for multiple plasmoids. The other way round, it also works: You don’t have to rewrite the dataengine if you want to put a new UI on top of that.

          If you’re missing a certain dataengine, maybe that’s your opportunity to dip your feet into Plasma development? It’s quite fun. :)

          As to performance in general, I’d recommend a read over: http://doc.qt.digia.com/4.7/qdeclarativeperformance.html

          Yes, we’re very aware of these things, in fact I spent most of last night on performance improvements in the containment shown. The result is massive, number of object is more than halved, less than half of the code is loaded initially, and more things are unloaded from memory once they’re not used anymore.

          As to delay loading … that’s exactly what we do in the Plasma 2 shell, pieces are loaded bit by bit, and you can actually see the elements appearing one by one. Startup of the shell itself is almost instant.

  4. (This comment is not intended to be interpreted as “trolling”. If you think you will be prone to do so, please, stop reading now.)

    First time I tried 4.0, I felt like plasmoids were a failure. The concept is ok, after all – gdesklets, conky, superkaramba were somewhat popular. But as an addon, not as a core feature. And almost everyone in the interwebs seemed to agree with me. So I thought: KDE will start shifting away from the plasmoids idea as soon as they can.

    But no… you don’t even consider that. As you can see, new methods for programming plasmoids appear; you can do it in C++, QML, JS, Python… and a lot more of languages. And even after that, plasmoids are not popular at all. Don’t get me wrong – I’m not against plasmoids, I understand some people use them and that they may be useful but please don’t make the KDE experience depend that much on plasmoids.

    A lot of parts of the KDE desktop core are plasmoids, and they don’t work very well. For example, take the notifications system. Oh, you’ve guys have taken like 10 releases to include a “fix” – and it is still far from perfect. It’s still completely deformed. NetworkManager? The same.

    I don’t have time to write a comment as long as I wanted to, but I think you get the idea. If you want KDE core components to be written as plasmoids, do it – but make it feel solid. You see Windows? Have you ever used its wifi networks dialog? It feels solid as a rock. Did you see its Alt+Tab dialog? Or the GNOME3 one? Solid too. Not something that blinks, wobbles, fells unresponsive, sloppy, deformed, as all plasmoids do. All of this is aceptable for a plasmoid that is meant as an addon – but not for a core component.

    Keep it solid, man.


    1. Hmm…

      First of all, I don’t know what you are doing to your desktop setup, but none of the plasmoids you mention (NM, Alt-Tab, etc.) feel or look “wobbly,” “blink” or are unresponsive. In fact, I have not idea what you might mean. They works as I expect them to do. My laptop is not top of the line, by the way. So I guess “I think you get the idea” is simply not the case, at least for me.

      Second, you seem to misunderstand what is being done for plasma 2. “KDE core components to be written as plasmoids” is not what the article is about. The article is about moving plasma to new low-level technologies provided by Qt. It’s not about making e.g. Okular a plasmoid. Nobody said anything like that.

      Third, every desktop needs things like a taskbar, applets, etc. It does not matter whether you call them plasmoids or not. Thus “So I thought: KDE will start shifting away from the plasmoids idea as soon as they can” makes no sense. Sure, don’t like or use the note plasmoid. Fine. But you do want a panel, right? I vote for keeping things like that.

      To clear up your confusion: “plasmoid” simply refers to something as having been written using the plasma library. What you might have intended to say was “please write the desktop widgets without the plasma library.” But why? This makes no sense. Libraries make application development easier and more reliable, help apps (in this case widgets) look and behave in similar ways and make the software ‘lighter.’ Just like we don’t all rewrite the kernel and the X windowing system, but build on top of them, Most KDE widgets use the framework provided by libplasma.

      In fact, if you compare the last few widgets that do not make use of plasma (klipper and kmixer) with plasmoids, you will see that they look horrible, don’t align well with the panel (mine is vertical) and have a noticeable lag on first load. I wish they’s become plasmoids sooner than later.

  5. Hi,

    I have a question about KDE5. You say here KDE Framework 5 is “on top of a hardware-accelerated graphics stack”. Does this mean that KDE Framework 5 will require 3D accelerated graphics drivers to work? I currently really admire the current KDE 4 implementation, which can be configured to work with openGL if desired, but if not it runs fast and light using xrender without any special 3D drivers. Currently Gnome is virtually unusable without good 3D graphics drivers, despite the llvmpipe implementation that offloads the heavy work onto the CPU. I think it would be a major step backwards for KDE 5 to require 3D rendering and compositing.


    1. You are mixing up a few things here. What you are talking about is compositing. In KWin it’s possible to use OpenGL, XRender or no-compositing – that won’t change.

      The OpenGL need for QtQuick2 has nothing to do with compositing on the window manager level. That is KWin will require OpenGL due to QtQuick2, but doesn’t require compositing. User interfaces like the one done with QtQuick2 are not as demanding to especially memory and bandwidth as compositing.

      On the long run of course we will require compositing and OpenGL. We are getting more and more in a direction that even ten year old hardware is capable of running OpenGL. That’s the point where one has to ask whether it’s better to sacrifice for every user of modern hardware or sacriface for users of ancient hardware – who could as well just run the Qt4 or Qt3 based version. Nobody is forced to update to new software, but nobody should expect new software to run on old hardware. And as a matter of fact – facebook won’t work on that either.

  6. Good news. I am running 4.10.1 with Mint 13 and experience is greatly satisfactory (with Nepomuk changes, Dolphin integration, screenlocker widgets, etc) but i have few complaints as well. (Constructive feedback – this may not be the right but am in a mood to write ;-) now and here)
    Firstly, I experienced few crashes when I change the theme (or add widgets. This really *should* not happen, i.e., A widget crashing desktop! And i cant even report bug because I could not successfully install those extra libraries required. I think the core KDE components should take some features from widgets developed by community and merge / replace them. Ex: Veromix – volume applet has amazing features compared to KMixer but hogs CPU. And to yaWP ( I just love it) i had to compile stuff and there were so many missing dependencies,etc but finally i got it to work.

    I have two laptops and one is an Optimus setup (screw Nvidia for their Linux support) and am missing those nice KWin effects which work perfectly in my other laptop. And I have not found an answer for making desktop effects work with Optimus laptops . (We thankfully have bumblebee for other applications to take advantage of graphics card)

    I had a steep learning curve understanding desktop containments – workspaces, activities, desktop widgets, panel widgets. You guys are doing an amazing job in development and design but perhaps not adequate time for building tutorials / documentation. Why not a demo video included as part of KDE? My vision for KDE is to be idiot-proof desktop and you can already boast as am quite a living proof of it. :-)

    Finally, one humble request – I know you development guys are very busy but please do spend some time on user forums and see for common issues that users face

    Thanks for reading through. KDE rocks.

    1. Here’s my recommendation (you might not like it): Next time, buy hardware that you can get Free drivers for.

      I personally lost interest in the blobs of nvidia and AMD and am not using any of their drivers. If they don’t work, that’s bad, but it’s not something I can change. The right address to complain is NVidia, and the right way to do it is to not buy their products.

      As to your suggestions, maybe that’s your chance to get involved and improve KDE in these areas? We simply can’t do anything we’d like, as we’re still bound to those pesky 24 hours in a day, but with more people caring about different aspects, we can make our software and ecosystem more accessible to a larger group of people.

      1. Thanks for the reply. Yes, after my usage of Linux I realized that buying a system is not like any other electronic appliance and need to consider various options like compatibility, driver support, etc. Next time, I will try buying a Linux pre-installed laptop.

        Sure, I want to contribute and give it back to community and am doing my bit (tiny) by hanging around in support forums and IRC channels of Linux Mint, promoting KDE and Linux amongst friends and social networks, raising bugs :-P, etc. But, yes I need to go beyond these and contribute in regular and proper fashion. I am not a programmer but can surely contribute in documentation part once I am comfortable with various aspects of the system.

Comments are closed.