The Road to KDE Frameworks 5 and Plasma 2

KDE’s Next Generation user interfaces will run on top of Qt5, on Linux, they will run atop Wayland or Xorg as display server. The user interfaces move away from widget-based X11 rendering to OpenGL. Monolithic libraries are being split up, interdependencies removed and portability and dependencies cut by stronger modularization.

For users, this means higher quality graphics, more organic user interfaces and availability of applications on a wider range of devices.
Developers will find an extensive archive of high-quality, libraries and solutions on top of Qt. Complex problems and a high-level of integration between apps and the workspace allow easy creation of portable, high-quality applications.

The projects to achieve this goal are KDE Frameworks 5 and Plasma 2. In this article, you’ll learn about the reasons for this migration and the status of the individual steps to be taken.

As this article is going to be a bit long, due to its level of detail, you can just skip to the end of every subsection to get the executive summary. Also, I would like to thank Blue Systems for their sponsoring of a lot of the work that is going into the future of KDE’s products, among which, mine.

Status Frameworks 5

Development of KDE’s Frameworks5, which focuses on modularization of APIs currently contained in kdelibs and kde-runtime, loosening its internal structure and making it possible to only use specific parts by splitting it into individual libraries and solutions.

The entire work to be done for Frameworks 5.0 is split into 7 topics. Three of these “Epics” are done:

  • Initial communication and documentation (Kevin Ottens),
  • Merging of code into Qt 5.0 (David Faure)
  • Reduction of duplication with Qt by removing classes and using their Qt alternatives (Stephen Kelly)

Four Epics are currently work in progress, three of them are monstrous:

  • Build system (Alex Neundorf, Stephen Kelly)
    • CMake (upstreaming some stuff, modularization, porting)
    • Modularization of CMake KDE settings (work in progress)
    • Modularization of macros
    • Review and inventarize Find* CMake modules
  • kdelibs cleanups (David Faure)
    This is a large Epic, containing many bite-sized tasks. Roughly 50% of them are done, 37 tasks remain open and 7 are being worked on, an extensive list is on the wiki.
  • Qt 5.1 merging (David Faure)
    This is the list of things that we haven’t been able to merge upstream into Qt 5.0, so we hope we can upstream as much as possible into Qt 5.1. This can potentially cause timing problems, if we can’t get all the necessary things we need into Qt 5.1. 9 tasks are work in progress by David Faure, Thiago Maciera, Richard Moore and others. 52 tasks are on the todo list, most of them currently unclaimed.
  • Splitting kdelibs (blocked) (Kevin Ottens)
    Another large Epic, in bigger chunks, meaning going through all libraries one by one, porting their build system to the changes in Frameworks5, cut out certain library dependencies and changing the translation system. 13 tasks are done, 12 work in progress and 8 on the todo list, not all of them assigned.
    An extensive list of libraries and their status can be found on the wiki.

Frameworks 5 currently compiles on top of Qt 5.0 and basic system services run (kdeinit5), although not all of its dependencies have been ported to Qt 5. Work on Frameworks5 is ongoing, so it is currently quite a moving target, and will remain so for a while.

Plasma and KWin Direction

An architecture based on Qt5 and Wayland makes it possible to use a more modern graphics stack, which means moving from X11-based rendering to OpenGL graphics rendering. QtQuick2 (which is the QtQuick shipped with Qt5) makes it possible to offer a very nice and extensible development API, while using the full power of the graphics hardware to produce excellent visual possibilites. Plasma offers development APIs that make it easy to create well-integrated applications as well as workspaces that are flexible, extensible and fully featured on top of QtQuick, and in the future QtQuick2.

As KDE moves forward towards Frameworks5, Plasma is taking the opportunity of the source and binary compatibility break of Qt5 to do necessary updates to its architecture. The goal is to have a leaner Plasma Development API and depdendency chain and achieve a better user- and developer experience by moving the UI fully to Plasma Quick, which is QtQuick plus a number of integration components for theming, compositor interaction, internationalization, data access and sharing, configuration, hardware, etc..

This constitutes a major refactoring of the Plasma libraries and components. First, their UI needs to be done in QML. This effort of porting workspace components to QML is already well underway. Second, the Plasma library and runtime components need to be ported from the QGraphicsView-based canvas to QML. This means cutting out dependencies on classes such as QGraphicsItem and QGraphicsWidget to their equivalent in QML. In the case of painting and layouting code, it means porting this code to QML.

Detailed Status Plasma Framework

The first bigger set of tasks is done:

  • API changes have been made in libplasma2 (done)
  • De-QGraphicsViewification of libplasma2 (done)

The open tasks are:

  • Remaining libplasma2 design tasks
    • Out-of-process dataengines
    • Dataengines as models
    • More fine-grained data retention in dataengines
    • Improved remote widgets
    • Change libplasma2 directory structure to reflect Frameworks5 policies
  • Create a scenegraph-based shell, make it load a QtQuick2Corona, Containments and Applets
  • Port QML Scriptengine to QtQuick2
  • Port scriptengine from QScriptEngine to QDeclarativeEngine
  • Remove dependency on graphics backend (QGraphicsView, or scenegraph) (Marco Martin)
  • Port imports to QtQuick2
    • Plasma Core (containing Theme, FrameSvg, DataSource, etc.)
    • Plasma Components (containing a basic QtQuick widget set)
    • QtExtras (containing components missing in Qt, such as MouseEventListener)
    • PlasmaExtras (containing additional UI widgets for better integration, such as animations, text layout helpers, Share-like-connect integration, etc.)
  • Making scriptengines (such as the Python scriptengine) only export QObject-deriven classes to the QML runtime (needs investigation right now)
  • Port of widgets away from QGraphics*, also necessary for some QML code

Plans for KWin Plasma Compositor

Plasma Compositor refers, in a Wayland world, to the compositor used for Plasma workspaces, which is essentially KWin in disguise as Wayland compositor.
In KWin, we benefit from an ongoing effort to modularize and clean it up architecturally. For most of its UI, KWin already supports QML (Window decorations, tabswitcher, etc.). Some mechanisms which currenty work through XAtoms will need to be ported, the API impact of that will likely be quite limited for application developers.
The strategy for KWin is to port KWin to Qt 5, then make it possible to run KWin outside of an X server on top of KMS, using the graphics hardware more directly. The next step is to use KWin as compositor for Wayland display servers. The dependency of X11 can be removed once it is not needed anymore to provide compatibility with X11 applications, or can possibly be made optional.
Milestones for KWin (Martin Graesslin) (updated with further clarifications, thanks Martin):

  1. KWin on Qt5 (work in progress, planned for 4.11): KWin will not depend on Qt 5 as of 4.11. The idea is to have KWin in a state that we could compile KWin with Qt 5/KF 5. But as it is unlikely that KF 5 will be allowed dependency for 4.11, we will not see a KWin on top of Qt 5 even if we achieve that goal. It’s a weak goal as we cannot release on it anyway.
  2. on top of KMS (planned for 4.11): KWin in 4.11 will still run on top of the X-Server. This is mostly about adding a proof-of-concept. Whether that will be merged into 4.11 and compilation enabled will be seen once the code has been written. So in this case it will at most be an additional very hidden (env variable) mode for testing.
  3. KWin as Wayland compositor (planned for 4.12): Again only as addition. As of 4.12 we will still be targetting X-Server as default. If we succeed we might add an option. But this pretty much depends on the state of Qt 5/KF 5 and QtCompositor. If any of those dependencies is not ready to depend on, the code might exist, but will not be released.
  4. no X11 dependency (planned for the distant future): There are no plans to drop X11 support. But we want to have the possibility to build a KWin without X for new targets like Plasma Active. For the desktop there are no such plans.

Plasma Workspaces

The porting strategy of the workspaces is to port plasmoids and containments to QML, in order to make them ready to run on top of the new infrastructure. In the case of C++ and Python, Ruby, JavaScript and “Web API” applets, it means rewriting them in QML. For portability and maintainability reasons, pure QML widgets are preferred. For some complex use cases, that can not be easily done in QML, we ship a combined C++ QML applet. For Plasma2, the only way to do the UI is using QML. QGraphicsWidget based Uis will not be supported anymore.

Once we have a working libplasma2 and a useful set of QML Plasmoids, we can think of running an entire workspace in QML and on top of QtQuick2, either on top of X11, or with KWin’s plans in mind, on Wayland.

Porting status of important widgets to QML / Plasma Quick needed for the workspace:

  • Taskbar (close to first review, target: 4.11) (Eike Hein)
  • Folderview (work in progress) (Ignat Semenov)
  • Desktop containment (second revision close to review, target: 4.11) (Sebastian Kügler)
  • Calendar (work in progress, target: 4.11) (Davide Bettio, Sebastian Kügler)
  • Kickoff (about to be merged into master, target: 4.11)
  • KRunner (work in progress, target: 4.11) Aaron Seigo, Aleix Pol
  • Done: System tray, pager, notifications, device notifier, battery, lock/logout, weather, Wallpaper, Containment support
  • Open:
    • Digital Clock
    • Icon
    • Picture Frame
    • others from kdeplasma-addons
    • and more (see wiki)

Conclusion

KDE’s Framework 5 project is well underway. It will allow us to move to a more modern graphics rendering engine, make our development platform more portable, and make it easier to reuse solutions KDE has built. The work does not happen by itself, however, yet it is time-critical. With Qt5.0 being released, 3rd parties are porting their code already. These people will only consider using KDE’s technologies if they are actually available — and that means we need a Frameworks 5 release.

So is this going to be KDE 5? The answer to this question is still “No!”, for a number of reasons:

  • KDE is the community, not the software
  • Frameworks 5, apps and the Plasma workspaces are not one singular entity. These parts are only released together (which might change in the future), and cobbling them up under one name really is really not helpful. (3rd party developers will think we’re only targeting Plasma workspaces, Plasma users will think you’ll only be able to run “KDE apps”, potential users of applications will assume that you can only use them inside Plasma workspaces — all of them untrue, all of them taken right out of my daily experience)
  • Within the Plasma team, we tend to use the abbreviation PW2 to refer to the next generation of Plasma workspaces. It stands for Plasma Workspaces 2, and it will probably be named differently in the future.

So, now you’re fully up to date on the status, isn’t it time to get cracking?

Tags: , ,

31 Responses to “The Road to KDE Frameworks 5 and Plasma 2”

  1. tosky says:

    > So, now you’re fully up to date on the status, isn’t it time to get cracking?
    I have unfortunately to say that it’s time to plan an alternative desktop shell which does not depend on OpenGL.

    • sebas says:

      You are running one right now. :-)

      • It’s also quite important to note that KWin with OpenGL enabled is currently the only window manager that doesn’t impose a performance penalty if you’re using other OpenGL applications, even with a relatively old graphics card. David Revoy had this to say:

        21.01.2013-15:39 Now I can keep kwin compositing activated. Its also the only ‘compositing’ I can use while painting ( Gnome3/Cinamon/Unity lags )
        21.01.2013-15:40 I’m happy, because I like fancy effect, transparent menu, and drop shadows.

        In other words, KWin on OpenGL is pretty good!

    • Well, then plan to switch away completely from Linux because Wayland itself depends on OpenGL.
      Maybe Haiku would be for you?

      If I understand the facts correctly, nothing by KDE will depend on OpenGL. Only QtQuick2 does and you could just write another back-end for that.

      • Rsh says:

        Wayland since recently allows to run purely on software rendering utilizing pixman library.

      • mgraesslin says:

        Wayland itself depends on OpenGL.
        It doesn’t. Neither the protocol nor the reference implementation Weston, which just got a software rendering backend.

        But to make it clear: having a dependency on OpenGL is nothing bad, but something good. Someone has to do the painting, why not letting it be done by hardware which is designed to do it, instead of running it on the CPU, which is not designed to do painting.

    • suy says:

      I’m no super-expert, but from what I’ve read, this is a wrong assumption.

      Qt4 has the “-graphicssystem” switch that allows it to use a different rendering backend. One of them is OpenGL, and other is a built-in software rasterizer that does everything on the CPU, and thus doesn’t require special support from the system.

      Qt5 relies directly on Mesa, and Mesa has a software rasterizer as well, and the tests showed that Mesa’s software rasterizer is faster.

      I see the situation of KF5 the same way. Instead of using Qt’s software rasterizer (if there is no OpenGL support, which normally is), is pushing it down the stack to where it really belongs.

      Maybe I’m missing something?

  2. DavidB says:

    Nice to see KDe stay fresh, but I think it suffers from always being to fresh. That is you keep changing the API’s in a major way every three or four years. The down side of this is that the code base never really stab. lizes as the code rewrites are bound to introduce new errors and bugs. All these code rewrites means no company, be they FireFox, Google, etc are never going to write a native KDE application because the code base is never stable.

    I think cobbling all the parts together is very helpful as it really gets you out of a dependency and version hell. Where one library update can cause small ripples that migrate into big waves as you move up the stack. As a user and a developer I’d rather see one library update then to see several small updates each with their own release schedule.

    Anyway, thanks for all the work you have put into KDE 5. I hope to see you prove my opinion wrongby release the best KDE yet

    • sebas says:

      The individual libs in Frameworks 5 will still be released at once, so your point on syncronicity are moot.

      API changes outside of Plasma are rather minimal, it’s enough to recompile in most cases, which is necessary for Qt5 anyway.

    • Ravi says:

      I agree. Why don’t Firefox/Pidgin/Thunderbird/Xchat (and numerous other examples) develop primarily for KDE. Was it Qt’s license that they went for GTK and now we are stuck? Was it KDE4? Unless KDE/Qt is first preference for third party major FOSS applications we would be stuck.

      P.S. I am seeing that not a lot of applications are being written in Qt/KDE and looks like its gaining ground..

      • sebas says:

        I’m not sure it’s true, there are hundreds, if not thousand of apps written in Qt. Those that are not still integrate excellently with the Plasma Workspaces, thanks to standards and theming.

        I personally care more whether an app is Free software or not, and not so much about the toolkit used.

    • squack says:

      KDE 4.0 was released in January 2008. KDE 5 will be out probably by next year. January 2008 to 2014 would be 6 years, not 3. The changes from Qt 4 to Qt 5 are smaller than those from Qt 3 to Qt 4, and so will the changes to KDE. I think it’s just the right time for something fresh.

  3. Petr says:

    Thumbs up d(^_^)b. Keep up the good work. I love KDE software. It’s my main and only desktop.

  4. Alex says:

    I hope Frameworks 5 doesn´t end up like KDE4.0

    • sebas says:

      It won’t, as it’s a much less intrusive change than 4.0. Also, much of the 4.0 grief came from Plasma not being ready, yet we chose to release platform, apps and workspaces at the same time. There’s no need to do this with F5, so we can release things as they mature.

  5. Martin Gräßlin says:

    Adding a little bit of context as I fear that this will be spread in the wrong way:

    KWin on Qt5 (work in progress, planned for 4.11)

    KWin will not depend on Qt 5 as of 4.11. The idea is to have KWin in a state that we could compile KWin with Qt 5/KF 5. But as it is unlikely that KF 5 will be allowed dependency for 4.11, we will not see a KWin on top of Qt 5 even if we achieve that goal. It’s a weak goal as we cannot release on it anyway.


    on top of KMS (planned for 4.11)

    KWin in 4.11 will still run on top of the X-Server. This is mostly about adding a proof-of-concept. Whether that will be merged into 4.11 and compilation enabled will be seen once the code has been written. So in this case it will at max be an additional very hidden (env variable) mode for me to test.


    KWin as Wayland compositor (planned for 4.12)

    Again only as addition. As of 4.12 we will still be targetting X-Server as default. If we succeed we might add an option. But this pretty much depends on the state of Qt 5/KF 5 and QtCompositor. If any of those dependencies is not ready to depend on the code might exist, but will not be released.


    no X11 dependency (planned for the distant future)

    There are no plans to drop X11 support. But we want to have the possibility to build a KWin without X for new targets like Plasma Active. For the desktop there are no such plans.

    Sorry sebas, had to add those things, as I am afraid of certain attention grabbing news channels :-)

    • sebas says:

      Thanks for the clarifications, I’ve added them inline in the article, reducing the risk of misinterpretation further. :)

  6. TheBlackCat says:

    “For some complex use cases, that can not be easily done in QML, we ship a combined C++ QML applet.”

    Does this mean it will no longer be possible to do plasma applets in combined QML+python/ruby? What about data engines, will scripted dataengines still be supported?

    Also, what about the panel containment? I don’t see that either in your list or the wiki.

    • sebas says:

      We are currently researching how language bindings for Ruby and especially Python will work. One thing is pretty sure, the UI will be done in QtQuick for all of them.

      I’ve added the Panel containment to the wiki now, thanks for the note.

      • vrm says:

        Please get rid of applets written in python, ruby, perl etc. I have nothing against these languages but it is important to have consistency/performance. I have had mixed experience with using python/ruby applets ( though lately their Q has been better). please stay with C++/Qtquick/QML.

        Thanks.

    • QML in interpreted languages is difficult by the way it works. However, the PySide people had found a (LGPL’d) solution: Simon Edwards, the PyKDE4 maintainer, is looking into how to port that to PyQt (and thus benefit PyKDE4).

    • Aaron Seigo says:

      the UI will be done entirely in QML. there is no sensible way to combine it with another language mucking with the UI.

      however, business logic (models, dataengines, services, etc) and custom QML Items will probably be possible in other languages. it’s already how we inject C++ powered code into QML, and that seems like the best path for languages such as python to follow.

  7. Alex says:

    Did you mean “Epochs” instead of “Epics”?

  8. juanr says:

    Keep up with the excellent work guys. A bright future awaits us.

  9. jk says:

    very informative post, thanks!
    KDE community is clearly the way to go when the competition don’t let you do how you like and dumb-down apps or add crapware.
    While I’m sure the desktop will take up less and less memory, I’d like to see some usability work a bit everywhere :)
    success!

  10. Paolo says:

    Thanks for the explanations!

  11. Christian says:

    Maybe you should try to get kmail2 running smooth again like kmail1 (imap,setup, remove broken and slow akonadi) and amarok usable again with mp3 streams… I have the impressions everything gets only worse with every change kde integrates.

    • sebas says:

      I could suggest the exact same to you, and it’d be equally (un)reasonable.

      Being a KDE developer doesn’t mean I’m suddenly responsible for your pet bugs. You can hire me (or someone else), though, and then I’d be happy to work on whatever application you want me to. Pushing your personal agenda is generally done by pitching in, not be spewing comments from your armchair.

      Independently, try the newest’ upcoming kmail, and you’ll realize that we work on that aswell, feverishly. Those things are not exclusive, but complementary.

      Finally, do not put the blame on people already working on it. Put it on those that don’t, especially if the latter group includes yourself.

  12. rued7ger says:

    hej sebastyan,

    you could do what you want: MAKE IT _QUICK_ AND _USABLE_.

    Because, kde4 is usable a bit… but is taking too much space, from my MbPro9,1 away!

    Whats next – is that a real SLIM-THEME – eG, like here now running, on aptosid-thanatos, fluxbox – is needed.

    so my favs would be:

    #1 QUICKR USE (eG make SANE defaults, instead of this 2 seconds popUP pauses)
    #2 THEME LIKE MOS is needed !!! (make more cool themes integrated into the KDEF|_|N!)

    so i hope the 2 most important achievment goals are clear, they could be through configuration and extensioning achieved quickly.

    what’s THEN next ?

    MORE USBALITY IN FAVOR OF VIRTUAL MACHINING….

    eG VIRTUALMACHINE-KDE….

    byby

    .rued7ger

    http://a.pictureupload.us/4124097905106d81eb9083.png