Next means Focus on the Core

The metaphor of a home make-over crossed my mind today, and I think it implies a few ideas that connect to Plasma Next quite well.
Plasma Next
Plasma Next is a new iteration of the Plasma workspaces. This is the first time, that KDE’s workspace is released independently from its underlying libraries and the applications accompanying it. It is built upon KDE Frameworks 5 and Qt5. “Plasma Next” is our name for the development version of Plasma, the final product will not be called “Next”. The planned release does not include the applications that are shipped today as part of the KDE Software Compilation. Applications, just like the Frameworks follow a different release schedule. Of course it’s entirely possible to run KDE SC 4 Applications on a Plasma Next desktop, and vice versa.

We have now settled on a release schedule for Plasma Next, which plans for the first stable release in June. It’s a good time to talk about what’s to expect in this first release. I think we’ve got some pretty exciting improved technology in the works. As our new baby shapes up, let’s take a look at what’s old and what’s new in more detail.

Frameworks 5

Plasma Next bases on KDE Frameworks 5, which is a modularized version of the venerable KDE development platform, kdelibs and friends, so to say. This results in a reduced footprint in terms of dependencies. The Plasma libraries and runtime components are one of those Frameworks itself, providing the tools to build applications and workspaces. Plasma has been one of the early adopters of Frameworks 5, mainly for the reason that we had to do some development in parallel. While building on an unstable base wasn’t always easy, it certainly has its benefits: We could check the viability of the Frameworks goals, and catch regressions early on. A good test harness only goes so far, actually building a real world application with the libraries makes sure they’re stable and functioning. These days, the issues are gone, KDE Frameworks has stabilised enough that applications can be ported quite easily.
With the move to Frameworks 5 come some architectural changes that allow us to cut out some “runtime fat”, we can get rid of some separate processes with the new architecture, which results in a leaner system for the user.

QtQuick for the UI

Plasma Next wallpaper selection
Plasma Next wallpaper selection

The transition to QtQuick reaches a very significant milestone in Plasma Next: the whole UI is written in QML. This concludes a transition process which we’ve started in Plasma 4.x, as a side-effect it solves a whole class of long-standing quality and maintenance problem in the code, it means a higher quality for many users. The transition to QtQuick-based UI has been fairly smooth so far, so we are not jumping onto something entirely new here, which means that we have been able to port much of the existing and matured functionality from Plasma 4.x over to Plasma Next. Our QML APIs have not changed radically, so porting existing code written in QML to Plasma Next is not a huge amount of work. For add-ons written in other languages (UIs written in C++, Python and other languages are currently not supported, this is a conscious design decision, and unless there are QML bindings for these languages (which seems like a weird idea), this is unlikely to be supported in the future. Instead we’ve improved and matured the QML API to a level where it’s very easy to create almost anything you can dream of in QML.

New Graphics Stack

Plasma’s graphical stack reaches a new state-of-the-art this year. We are now able to fully offload the rendering of the UI into threads, and other processes, making the UI responsive by default. We also offload visual effects almost entirely onto the graphics card. This means that it’s faster, so you get better framerates out of it, it frees up CPU time for the user and it’s also more energy-efficient, so saves some battery life.
In case the system falls back to software rendering, we can now centrally disable animations, so even on systems that paint slowly, or we can reduce repaints drastically to give a snappy feel. This means that the visual effects in the UI degrade gracefully with available graphics features on the system. For the vast majority of users, this isn’t an issue anyway, their systems run a fully hardware-accelerated desktop with complete ease. On these systems we can improve the user experience by using the graphics card’s capability — and not only that: The transition to QtQuick 2, which is part of Qt5 means that all the work at UI level can be offloaded onto the GPU as well.

Another hot topic these days is Wayland readiness. This is currently work in progress, Martin Gräßlin’s blog shows some impressive progress on running KDE applications on Wayland. This is one of many important milestones. The most complex case is running a full Wayland session with Plasma and KDE applications, and we are not there yet. Wayland support is continuously improved.

Polished Interaction

Let's try a dark theme
Let’s try a dark theme

Next to these architectural changes, we’ve also put some work into the actual UI visuals and interaction. We are in the process of establishing a Visual Design Group in KDE. Which already participates in the development of Plasma Next. The first results of this will be visible this summer, and the group is currently hashing out plans for the future. There is some serious design love appearing. You can follow the progress of it on the wheeldesign blog.

One of my favourite new features that has recently landed is Marco’s work on contrast behind translucent dialogs, which hugely improves readability in many cases, and make “the old Plasma” almost look bland in comparison. We’ve cleaned up quite a lot of workflows, not by making them any different, but by removing visual noise in between. The idea is to polish common elements to feel fresh and like an upgrade to users, but not entirely different. In the UI, known behavioral patterns are kept in place, with more pronounced core functions, and less fuzz around them. We’re aiming at keeping all the functionality and adaptability in place. To the user, the migration to Plasma Next should feel like an upgrade, not something completely new, but trusted after a bigger step in its evolution, yet recognizably true to its values.

We want to achieve this by concentrating on the core values, on what makes us good, and what users love us for. But we also do not want to pass the opportunity to fix what nags us and our users. Improvements in details mean that we listen to our users, a large portion of which do not want to be the subject of UI experiments, but who require a reliable system that supports and improves the personal workflows they have almost brought to perfection.

Of course, all of these workflows rely on many details behaving as they do, and these things are different for everyone. A small difference in behavior, or a missing seemingly minor feature might make or break any given workflow, there is no guarantee to be made, just a promise of best effort.
Many, but not all parts are co-installable, and it will be possible to use KDE SC 4 applications in a Plasma Next environment, and vice versa.

Beyond Devices

Plasma Next runs on top of a device-independent shell. The whole UI is structured into logical blocks that can be exchanged at runtime, this allows for dynamic switching the user interface to suit a different form factor. A target device will typically have the plasma-shell (and runtime bits) installed, and one or more device-specific shells. We are now readying the first of these “workspace user experiences”, Plasma Desktop. Others, such as the tablet-oriented Plasma Active UX will join in subsequent releases.

When will it be good enough for me?

While no .0 will ever be perfect, I expect that Plasma Next.0 will feel very much like an evolutionary step to the user, and certainly miles away compared to the impact of Plasma in KDE 4.0. For those that still remember the transition from KDE 2.2 to KDE 3.0, this seems rather comparable. While KDE 2 was almost a complete rewrite of KDE 1, the 2 to 3 transition was much less radical and far-reaching. We saw the same pattern between KDE 3 and 4, which again was quite radical, especially in and kdelibs and even more so for the workspace — Plasma which was completely new in 4.0.

In the first stable release of Plasma Next we want to provide a stable and fully functional core desktop. We concentrate on making the most important default functionality available, and are polishing this first and foremost. I expect that most users can be just happy with this first release, but as I said, there’s no guarantee, and maybe you’re missing something. For those that want to make the switch later, we have of course our long-term maintained current Plasma stable, so there’s no rush.
This concentration on the core also means that not every single feature will be available immediately. We are, however aiming at feature parity, so in most cases, a missing feature in .0 will be brought back in a later release. The kdeplasma-addons module, which contains additional functionality will likely not be ported by summer.

Ultimately, the way to make a good Plasma Next happen is to lend us a hand and take part. Even better, you don’t have to wait with this until summer. Take the plunge, build KDE Frameworks 5 and Plasma Next, try it and help us completing the core functionality and to fix bugs. That is exactly what we will be doing in the next months leading up to the release this summer, and we hope the experience will be delightful one for our users.

55 thoughts on “Next means Focus on the Core

  1. The wallpaper-config window’s title bar has a placeholder icon. In the current version the same icon as the top one in the sidebar.

  2. For that “Plasma Next wallpaper selection” image, I am curious about the visual design detail, specifically with the buttons. Would it be reasonable to give feedback on it now, or should I wait or find another instance?

    1. Go ahead. Can’t promise that the feedback is useful for us, at this point, but without knowing what you think about, we can’t.

  3. Seems like you guys have been really busy. It’s really starting to show. I especially like how the icons in the battery icon are nice and big. As for the icons, Jens and co. sure know how to keep up the suspense (making us wait a week to see the new color scheme for Plasma and I guess KF5-based applications and now making us wait a week just to hear about the icons).

    I also see a few changes to Oxygen. Is that on purpose or just some porting to Qt5 issues?

    Also, how are the Plasma Look and Feel Packages coming along? Is the idea something like packaging a color scheme, Plasma theme, icon theme, and a QtCurve theme compressed into one tar that can all be activated from a single place in the settings?

    1. Now that I had another look at the pictures, Oxygen in the second picture looks normal but there is some white missing in the left pane.

      1. That’s a bug in QtQuickControls, the view background color doesn’t seem to make it through. (The theme dialog is C++ / QWidgets, the wallpaper one has migrated to QML already).

    2. They’re basically in place. The idea is not to collate different types of addons into one package, but to cover all aspects relevant to the user (so everything UI). A Look and Feel package refers more to the layout and interaction, the visuals are controlled by the theme (which also holds the color scheme). One of the things that has recently been moved to the L&F package is the OSD for example.

      1. Thanks for the explanation. I thought “Look and feel” would have meant visuals and interactions, respectively. Can’t wait to actually try them out to understand them more. Also, thanks for the replies.

  4. I’m just curious if the buttons in the wall paper dialog will stay as squeezed looking as they are now (no padding between icons and button frame). One thing i’m disliking more and more is that it seems no one does pay attention to these things for KDE (!?)…and the whole new desktop will look like the old. Beside that…severything sounds very promising!

    1. You are aware that we have months of polishing ahead of us? Maybe it’s just that nobody had the time for such details as we have more important things to work on.

    2. That’s a problem with the Oxygen style in collaboration with QtQuick Controls. We have already solved some of these issues, but aren’t done yet. A list with issues if you’d like to jump in and lend a hand can be found here. More information is on David’s blog.

  5. Well , let me say something about the wallpaper window.

    the most of times , me like and a lots of people , needs to see the wallpaper in action so i need always to click on apply , for me this is a no sense ,

    is not possible to apply directly a wallpaper when a picture is selected? is not more convenient ? isn’t easy to do ? just connection the slot ?

    1. Our complete configuration architecture is built around non instant apply. We cannot just exchange one part. It has to be all or nothing, otherwise we create a very unpredictable and non-intuitive user interface for our users.

      1. mm i can’t undestand your point of view martin , or maybe i it’s not clear my think :

        right now it’s

        1 user changes wallpaper
        2 user clicks apply
        3 user dislikes the wallpaper
        4 user changes again
        5 user clicks apply
        6 finally user like new wallpaper

        what i would like

        1 user changes wallpaper hovering a new wallpaper , system will remember old wallpaper and show the new wallpaper on the desktop, if nothing is applied system will restore the old wallpaper

        2 to apply this change instead you should just click apply

        so why this is non-intuitive ?

        :D well actually i am one of yours user and i don’t really like to click a lots for me it’s not comfortable and not intuitive right now

        i think that a system must be comfortable kde it’s my dekstop since 7 years but it lacks of these little things

        1. And how many users would exit the dialog without clicking apply thinking it got already applied and then go “why is the change gone?”

          1. quote:: And how many users would exit the dialog without clicking apply thinking it got already applied and then go “why is the change gone?” ::quote

            That’s a non sense argument. KDE already has a function where, if a user attempts to move to another tab in the control panel, or to move back to a previous item, it will display a message asking you to confirm or cancel the change.

            So it is not at all difficult to allow a user to make a change, then see it applied to the desktop, decide they don’t like it, try another, etc, then when they attempt to leave the current area without making the change permanent, display the same pop up message that gets displayed in other parts of the control panel, asking them to confirn or cancel the change.

        2. While in reality, your option works like this:
          – User opens dialog, picks wallpaper, sees it applied
          – User closes dialog, wallpaper changes back,
          – User has to reopen the dialog and find out that the wallpaper only stays after closing the dialog when the apply button has been clicked
          – User screams and shouts, calls developers stupid and writes us hatemail

          This case, while a bit exaggerated is the exact reason why we do not mix instant-apply with the Apply/OK button model.

          1. nowardev already proposed one solution to that dilemma.

            IMO opinion, another one would be what is used for document preprints, where you have a watermark that says “preview”. That could be either on the desktop where the wallpaper is shown or on the thumbnail in the selection dialog.

            Still, I do understand your concerns.

          2. Why not have a hybrid of the two models, an instant apply model coupled with a REVERT/Ok model (dont even think the ok is necessary, just this one revert button will be enough, double win as a button is eliminated without losing funtionality)

            On hovering the wallpaper, it instantly changes (previews) on the screen, on hover out – the old wallpater returns (note, revert isnt necessary for hover). But on clicking on the wallpaper, the screen changes to the new wallpaper instantly (instant apply), but now the revert button is enabled and one can choose to go back to the original wallpaper.

            Best of both worlds, and infinitely more intuitive

      2. Totally agree.
        But, maybe it can be done like the Konsole color settings, which are previewed on hover.
        Just a thought.

        1. This is a good example, it work there great. The same could work for wallpapers. It is faster to do, and more intiutive.

          Although I understand that the whole KDE desktop works with the Apply button, but that dessision may be the more appropiate two and also one decade ago, but is it still now?

          It doesn’t seem to me that [Ok, Apply, Cancel] is the best option. Maybe [Revert, Ok]?

  6. Will native addons be installable from the UI? Should be entirely possibly but would need a c++ compiler as a dependency. (like Node.JS does it)

    1. Native addons are written using Plasma Quick and packages in Plasmoid packages (those can be additional or replacement widgets, wallpapers, containments, whole shells, basically everything you can think of in Plasma).

      Some of these things need additional libraries (imports in the QML world), and those are usually written in C++. Plasma already comes with most of what one needs, but the add-on system will not be able to install additional C++ code from packages. That’s up to the package management system of the distro, and it’s not likely to change.

      1. That’s a pity, I would really see Plasma packages flourish if distributions where not involved with the addons. In my opinion a full-fledged package manager focused on developers (command line) would give a lot of life to the ecosystem. Of course some addons would require invoking the system’s package manager but basic C++ code should be compiled via plasmapkg or whatever.

        To create an addon in Node.JS i simply do:
        npm init # this asks me some questions about the addon and creates the basic structure for the addon
        npm publish # publishes the addon using my profile and private keys

        See perl’s cpan or ruby gems for other examples.

        Well, that’s my take … since KDE 4.0 I really was excited about Plasma and user created addons but now few years have gone and I see really not too many high quality addons. I have created two private addons for myself but I had no clue how to publish them from plasmapkg so I just do not care.
        First – please be more developer friendly, allow easy creation and publishing of Plasma addons. (including native ones)
        Second – please be more user friendly, allowing easy installation of the above. Do not rely on system packages when not necessary.

        1. Perhaps you’re looking for something like Bodega?

          Interestingly, the bodega server even uses Node.JS.

          What I don’t like about Ruby gems and Perl’s CPAN that it is a shadow package manager. Something that has serious overlap with the system’s package manager, but duplicates much of its functionality for a more limited use-case for one specific language. Bodega is quite different in that regard, as it collates different sources into one offering for the user.

          1. Well perhaps that’s right tech but I am interested in an integrated solution in Plasma itself so that the whole community can use and improve, it is no

            I want anybody to be able to:
            plasmapkg install bitcoin-charts
            … and have bitcoin-charts

            the author (for example myself) should be able to easily publish via:
            plasmapkg publish bitcoin-charts

            Such solution would only work if it were oficially blessed by the Plasma itself.

            Optional auto-updates should also be a possibility with this.

    1. So… you do this:
      System Settings -> Workspace Appearance -> Window Decorations -> Click “Configure Decoration” -> Shadows

      Then you can change the color of them (making it a shadow instead of a highlight) or remove them completely

        1. I love the blue glow. I don’t even use oxygen, I use qtcurve, and I have the blue glow enabled.

          1. Sounds like a poll to me :)

            Personally the “Is very Kitsch” speaks for my opinion too. A very slight shadow-effect might be better.

        2. Lol at your comparison. I had a long time to use the oxygen window border but now you mentioned, I switched to it again and I kind of like it.

    2. I agree that the blue glow should not be set by default. Let’s take some aesthetic cues from today, not yesteryear.

      1. How is it a cue from yesteryear when no other DE ever had this effect, and afaik it was new in kde 4 (not that old)?

        1. “Aesthetic cue from yesteryear” doesn’t mean *exactly that one particular effect mentioned*. It just means any tacky effect of the sort referred to, like a glowing blue shadow, or some flashy glowing effect, or shiny/glossy effects, or what have you. Just think up your own tacky aesthetic effect of yesteryear. Well my advice is not to follow those design cues but to follow today’s. Was that really so hard to understand from what I wrote?

  7. This is the first time, that KDE’s workspace is released independently from its underlying libraries … is built upon KDE Frameworks 5 and Qt5.

    So, is independent or not?

    1. It is released independently, yes. It build on top of Frameworks and Qt5, among a whole bunch of other things. Those are not mutually exclusive. :)

  8. I will admit I am quite excited about the next KDE, being a user since 3.x. But I do hope that some remaining problems is finally cleared up in this new version.

    For one multi-monitor support has a few problems such as child applications popping up in random locations, instead of following the parent application. I too would like to see applications appearing where the mouse clicked. (Hence if I have two menus on two monitors, the application would appear on the monitor where the menu is.)

    But overall, you have done a remkarable job on KDE. It’s the only GUI I desire, but it’s a bit too heavy for use on a low-powered netbook.

    1. There’s a config option to have the active screen follow the mouse. That should ensure that new windows open on that screen. There are a few applications which break it by positioning themselves, but latest with Wayland that will be fixed.

  9. I really think they should remove that manga-ish blue blur on the active window, and just put a regular shadow.

  10. I’m more concerned about the performance of the QML-based plasma next compared to native C++ current version of plasma. Don’t you think that it would have been better to write the code in native C++ for a better and responsing UI? I tested plasma next in project neon and seemed to me that the user interface is not as fast and responsive as KDE 4 plasma. :(

    1. native C++ like in KDE 4 plasma means rendering on the CPU. With QML we get the rendering done on the GPU and in a background thread. So from an architecture point of view the approach is already better. Obviously only the UI is done in QML which means all the heavy work is still done in C++. Also most of the UI in KDE 4 plasma is already QML, so there is not much change at all ;-)

  11. I will just say that no matter how great the underlying technologies might be for a KDE desktop, when people see that terribly outdated Oxygen theme and icons most of them simply don’t want to use that desktop. Maybe it’s unfair, but it’s a fact, and I hope somebody over there is aware of it.

  12. I’m really glad to hear about KDE’s continued thoughtfulness in the area of graphics support. It’s great to see offloading of rendering onto the graphics card. But, if I understand this post correctly, KDE next will still run smoothly on systems that for one reason or another don’t have 3D graphics support? So I can be confident that if some kernel update breaks my graphics drivers, I can still boot in VESA and have a KDE desktop that functions at normal speed (albeit without any graphical effects) and doesn’t make my CPU go crazy?

    Thanks to all KDE devs for their hard work!

    1. This just happened to me yesterday, during an upgrade of my Debian Sid machine. With failing compositing, it didn’t look as fancy, but worked just fine otherwise.

      This can’t be generalized, however. It completely depends on how broken your system is, the point is that our code will go to some lengths to support this case.

Comments are closed.