Components towards a new plasma

Software

One of the biggest new features in Plasma that will be released together KDE Plasma Desktop 4.8 is the new shiny set of QML components, that over the next releases will gradually replace the old simple widgets like pushbuttons lineedits etc.

This is one important step towards a cleaner, easier to use and easier to write user interface, an important step towards Plasma2, where the UI will be completely done in QML, using a fast OpenGL driven scene graph, meaning prettier effects and most important always fast and smooth graphics using more what a modern gpu can actually do.

Here is a video of an example plasmoid (you can find it in the kdeexamples repository, is a good way to learn the api) that shows just a collection of what the available components are.

OGG version

This is one of the things that are starting to percolate from the work that is being done in Plasma Active and is starting to benefit the desktop as well.

Of course common UI components can’t be really common between the desktop and a mobile device, or between different mobile devices such as tablets and phones, so what about that?

We have a complete series of components targeted to be useful to build widgets for the desktop (as shown in the video above), designed to be as indistinguishable as possible from the old C++ based widgets, so it will mix perfectly in the rest of the desktop. The Device notifier widget is completely rewritten in QML using some of the components for 4.8 and even if it uses 100% new code (modulo the dataengines) it looks and feels exactly the same, there is just a “something” about its smoothness that comes out as a pleasant unexpected thing while it’s used, even if it’s difficult to exactly point the finger at.

So how does the very same widgets gallery plasmoid look when loaded in a Plasma Active two tablet?

OGG version

The touch specific set of components is used and the plasmoid itself besides using those touch components, adapts itself to the fact of being loaded as a fullscreen application on a tablet and changes its layout accordingly.

Some of those components are pretty universal, especially those without any graphics or input such as Page and PageStack, that manage the life cycle and transitions effect of dynamic pieces of the user interface.

Some components are a bit more specific, but not dramatically different: a button or a text field will look an behave in a very similar way, but for instance we don’t want mouseover effects on a touch screen, and maybe we want the touch area a bit bigger than the actually visible button area for a better grip, but here we still smell at least a partial code sharing.

There are then the ones that we want a flat out different implementation: for instance we want a desktop-themed, independent window for context menus (that is, a QMenu) on the desktop, while we want a more plasma-looking, finger friendly thing on a touchscreen, but still the very same exact api.

We have a series targeted to the current Plasma Active tablet profile uses the 90% of the same code as the desktop version, but everything that needs to be different is different, for instance there we have no mouse over highlight, bigger sizes and hit areas, scrollbars are read only scroll indicators visible only when actually scrolling.

14 thoughts on “Components towards a new plasma

  1. BajK

    Awesome ๐Ÿ™‚ So this will also get rid of Plasma’s reaaaaaaaly laggy and slow resizing of things? i.e. if a Plasmoid gets resized, it’s … urgh! Or is this more an X limitation?
    And you still don’t have a mouseover effect on the scrollbar ๐Ÿ˜›
    I wished that Plasma widgets looked more like Oxygen widgets, so we don’t have two sets of widgets doing the same but looking foreign to one another.
    That slider-checkbox (how is it called?) looks nice ๐Ÿ™‚

    Anyway, awesome work, as always ๐Ÿ™‚

    Reply
  2. Kjetil Kilhavn

    KDE is the future, or at least it has the potential to be the future. However, as with OS/2 there’s no future if there’s no backing from vendors. I hope someone offers KPads or PAPads soon.

    With regards to touch area, I think it would be a good idea to make it configurable. Some people have more shaky hands than others. Some people use a setup with large icons while others use a setup with small icons.

    I can see that in some dialogs it could pose a challenge, but that would probably indicate the author or designer relied too much on physical instead of logical layout when creating the dialog. In other words, a good hint that another shot at it could be needed.
    It’s kind of the same problem that we have on the World Wide Web. While it was originally intented to be content-centric there were soon some which focused on designing their pages – making them less accessible for several minorities (e.g. people who need large typefaces or can’t see at all).

    Not to mention, how well does Captcha work for those with disabilities… ๐Ÿ™‚
    I tried the option

    Reply
  3. aseigo

    “So this will also get rid of Plasma?s reaaaaaaaly laggy and slow resizing of things?”

    it will help with somewhat as QML performs better than QGraphicsProxyWidgets, but we are currently still painting to a QGraphicsScene and that has some limitations (and yes, x.org, or rather its drivers and at times Qt’s support for x11 also gets in the way at times).

    this QML work, however, will eventually free us to move to QML SceneGraph after we move to Qt5 which is openGL accelerated and very fast as a result.

    we are also working towards moving to wayland, though this a ways off, which will allow us to move to a more modern architecture there as well.

    Reply
  4. Katu

    Is “Plasma2” something that we will see in KDE Plasma Workspaces 5.0? And what is the fate of non-QML widgets like: Google Gadgets, Mac OS X Dashboard widgets, SuperKaramba widgets, and non-QML Plasmoids in it?

    Qt5, Wayland and Plasma2 based KDE Desktop is something that I just can’t wait to see.

    Reply
  5. Alejandro Nova

    Same thing I asked before in Martin’s blog: where can I find these QML components to test them? I really want to test the QML Microblog component, but I don’t know where it is.

    Reply
  6. Stefan

    Is it intentional that the content area in the demo app can be moved horizontally? Having it flicking in that direction looks rather annoying (plus flicking is unusual on a desktop form factor).

    @Kjetil: +1 on configurable touch area – A talk at DS11 mentioned that touch area should be configurable in today’s UI toolkits.

    @BajK: +1 on “Plasma widgets should look more like Oxygen widgets”

    Reply
  7. Aaron Seigo

    “Is “Plasma2″ something that we will see in KDE Plasma Workspaces 5.0”

    libplasma2 is being developed in the frameworks branch and is the foundation for all of this. so, yes. ๐Ÿ™‚

    however: we have not yet put down a plan for when the first Plasma Workspace release that uses libplasma2 will become available.

    “where can I find these QML components to test them?”

    in the kde-runtime (in the plasma/declarativeimports directory) and in plasma-mobile (in the components directory) git modules.

    Reply
  8. katu

    If KDE Plasma Workspaces 5 will be based on libplasma2 that is part of KDE Frameworks 5 then should I conclude that the release date of “KDE SC 5.0” is uncertain? Or is it possible that we will have something like KF5 based KPW 4.10?

    Reply
  9. rachel

    i bought some [url=http://www.lolitaclothingstore.com]lolita dresses[/url] recently, now i recommend a website to

    you, there r some [url=http://www.lolitaclothingstore.com]lolita costume on sale[/url] and do a fast delivery.

    Reply

Comments are closed.