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.

Let me talk briefly about one of the goals we have about Plasma Active, of which today’s release of Active One is just a little baby step in this yet important direction.

We think that looking at different devices as isolated worlds, needing completely different “Apps” and UX stacks for each kind of device it’s pretty limiting, and it’s not the way who uses it (aka “humans”;) thinks.

What we believe in, is that computing devices (doesn’t matter if it’s the laptop, a tablet, or something running in a washing machine) should exist in function of helping the people accomplishing the task they want to do, no more, no less, devices shouldn’t be something complex, hard and therefore “harming”, but should just be extensions of the user harm, of the user mind, just tools, and in every situation, the best tool for the best job.

The line between the devices should be as blurred as possible, what we should target on is the task the user wants to accomplish, a task (or workflow, if we want to use a more trendy term;) a task is composed by many actions, many subtasks, and for each one the perfect tool may or may not be the same device, in the same way that may or may not be the same application.

If I take photos in a vacation I need a camera, when I get back I need a big desktop to view, organize and eventually edit the photos, if I want to quickly view them or show them to my friends, I need the device more appropriate compared to where I am: it could be a mobile phone as small as possible, a tablet if possible, or if we are in the living room, a big flat screen TV.

The need of applications that show a familiar, yet device optimized user interface everywhere becomes evident. why was never really done? just a technical detail missing, now we have it; if used well, QML does an amazing job at that kind of “gapeless” customization.

As evident becomes the needs of perfect synchronization, the need of sending not only files, but metadata and pieces of applications across devices, and the need to have interface as natural and “chromeless” as possible.

That’s one of the goals we’re pursuing with Plasma Active. The KDE community can be a leader in this small revolution, a ground that no one of the other mobile offerings ever adventured into, neither open or proprietary.