Tag Archives: kde4

KDE on improv, now with videos

I’m finishing the images of the OS that will be shipped by default on the Improv. As soon they are finished they will be available for download, alongside recipes on how to build new ones from scratch.
So at this point, I tought it was a good time to take some videos.
The default os, will be a kind of “tasting plate” for developers, it will be possible to try many combinations of software.
By default it will start with a normal console login, so very fast and ready for “small server” duties.
By going to graphical mode (init 5) it will start the SDDM login manager, from which several sessions will be available:
It will be possible to chose between OpenBox or a full KDE Plasma Desktop or KDE Plasma Active sessions (the latter two being completely independednt saving their settings separately).
Here is a video showing the 3 environments running on the Improv (the little board itself is visible in the bottom right corner of the screen)

Another important thing that is available there is Qt 5 (at the moment 5.1, upgradable in any moment newer packages will land on Mer)
This will give a very convenient development environment for Qt5 and QML2 based applications, to test their performance on a mobile/ARM based device.

Active, images and devices


As I wrote before, we are trying to make PA4 as stable as possible, and as well as it was noted by some people, this involves also having images for a wide variety of devices.

What I’m doing, is kindof even another step: making the image creation as easy as possible, so that is possible for people to contribute easily in the creatoin process of those images, (especially images for previously unsupported devices).

In Mer, that is the base of Plasma Active the OS images are created from an instruction file called kickstart. you can find a source repository that creates kickstart files for plasma active here:

git clone git://anongit.kde.org/plasma-active-kickstart.git

Then, what you have to do is installing a Mer SDK, following the instructions here. This is very easy, is more or less uncompressing a tarball and running a shell script inside it, and should work on any distribution.

Then, from inside the SDK chroot environment, go where you downloaded the git repo (your home is accessible from there) and do:

mer-kickstarter -e . -c latest-devel/plasma-active-latest-devel.yaml -o plasma-active-latest-ks/

it will create a kickstart for each of the supported devices in the plasma-active-latest-ks/ subdirectory, then:

cd plasma-active-latest-ks/
sudo mic create livecd plasma-active-i586.ks -o . --pkgmgr=yum --arch=i686 --logfile=plasma-active-build.log

And an iso file with the same name as the kickstart file will be created. Different devices may need different image format, such as “raw” instead of “livecd”

Right now just a few devices are supported there, what I want to achieve is to support there all the device types Active has been successfully ran on.

One thing I must say, the code in that repo is derived from the Nemo project (another Qt based project built on top of Mer) so also a better sharing of bits and pieces for device adaptations with Nemo would be awesome as well.

Help make Plasma Active 4 shine



Plasma Active 3 was released on 15th October 2012, and since then, work on the next version has not stopped for a minute, now the work on Plasma Active 4 is well on the way.

Another important release at the horizon is the KDE Plasma Desktop shell 4.10, due in February.

We believe our desktop and mobile products are closely interrelated, both from a technology point of view and from a continuity of the user experience, therefore Plasma Active 4 will be based upon the KDE 4.10 release. This will mean that PA4 will automatically gain some of the features of 4.10, at least from the technology platform point of view, but means also another important thing: ease of setup.


We are planning to release it around the end of March, and since some hardware is approaching as well, this release is more important than ever.

Plasma Active 4 will have a number of important new features over PA3, there are countless small improvements, and few features that will be really visible, including:

  • Faster and more usable web browser
  • Improved usability of the on-screen keyboard
  • Numerous improvements in the File browser application: faster, more usable and scalable to very big amounts of data
  • Device-wide ownCloud integration
  • “Developer mode” on the device, to more easily work with it
  • More user friendly ui for setting alarms
  • Better notification
  • New applications
  • Community support for new devices


But I want to know more!

This is where you can make the difference: it’s very important that the new release will have an user experience as smooth as possible. The work for new features is coming to an end (even tough you are still in time to present a work plan if you want to work on a particular one). But is starting an even more important period: testing, stabilization, bugfix.

There are many ways to help in making the release shine: it may be just installing an image and testing, it may mean getting random people to test and register the issue they had with it, it may be participating in the discussions on IRC or the mailing list, it may be setting up a build environment, and start hacking.


Starting hacking on the components of Plasma Active is easier than ever, because as i said, PA4 will be based on KDE 4.10, that means everything specific of Plasma Active can be built on top of the development packages of KDE 4.10 from your distribution of choice, while having the active workspace and active applications running from git from your machine in matter of a minute.

From a packaging point of view, is ridiculously easy as well, as all you have to do is to install the Mer sdk, that is completely self contained, can be dropped on top of any distribution and doesn’t really “touch” your system

If you are interested, drop in in IRC, on the #active channel of Freenode, or join the malinglist active@kde.org

Time to refresh some air


In the last entries I posted some screenshots of some upcoming features in the Plasma Workspace in 4.10, and they shown also a glimpse of another thing: a new default theme, on which I was working on since a while together with Nuno.

The new default theme landed today in git and it will be in the Plasma Workspace 4.10 release (disclaimer: the wallpaper is an old included one, the new default will be presented in a while ;)):


It’s the typical case of a radical redesign, in which everything changed, in order to seem that nothing has changed, just a general feeling of feeling more “right”.

The key design principle is to make the whole appearance “lighter”. Most graphical elements that didn’t have an actual “functional” meaning are now removed, as well as gradients (a pattern that says “3D”, usually reserved for indicating interactivity) on all elements that are not clickable.

Plasmoids looks completely flat now, the taskbar has now an element around only the active task, and the shadows of the items are different as well. On a related note, now all the popups will use KWin to draw their shadow, just like the panel. This means better layout and better integration with other windows.

widget gallery
widget gallery

New QML components: Know thy dialogs


Today part of “what to expect in 4.10 in QML components”: Dialog. The Dialog components have been introduced in plasma since sone time, and are documented in the usual page. The components that may be used to create a dialog are:

  • Dialog: unsurprising name: it creates a Plasma themed window with space for a title, a content and buttons. You have to create all of them, you’re on your own, but provides the window management and methods such as open(), close(), accepted() and rejected(). You usually don’t want to use this, unless you want some strange custom things in the titlebar area or in the buttons area.
  • CommonDialog: is a Dialog, but provides a titlebar and the buttons, you want to use this in the 90% of the cases when you want to display custom content in a dialog.
  • SelectionDialog: presents the user a list of items to chose from, useful to create menus when you want to modally ask “what of those items do you want?”
  • QueryDialog: probably the most useful: is a simple dialog with text and two buttons. Used for things like confirmation dialogs like “are you sure you want to delete this item?”. It displays a text and two buttons, that default as “Ok” and “Cancel”, but their text is customizable.

It’s a while this API exists, but in 4.10 there was an important change in its look and feel in 4.10: Now if it’s possible the dialogs looks “inline”. It will be done on the same window as the plasmoid (i.e. on the “desktop”) and if provided with a visualParent property, it will have a comic balloon tip pointing to it. As usual, an image is worth a thousand words:

Dialogs on desktop

But what about if there isn’t enough space? For instance the dialog may be displayed from a Panel, where is impossible to have an inline dialog. Fear not, in this case the dialog will become a separate window, still working everywhere:

Dialogs on panel

An “inline” behavior for dialogs is preferred because in this way questions are semantically and visually grouped with the object they belong to, and most important the desktop layer must not “interrupt” the user, it’s just background information.

The switch between an inline behavior and an external window is completely automatic, as usual, something that the plasmoid should never have to worry about.

New QML components: IconItem


Last post was about a new QML component available in Plasma workspace 4.10 with an important design pattern that comes with it: Lazy loading everywhere when possible.

Next couple of posts will be about other new and old components and the UX concept behind them.

A very important thing in Plasma is to have extremely coherent elements all across the screen, both in graphics appearance and behavior. The fact that two things together in the screen are done by two different plasmoids is something that shouldn’t really matter to the user (it’s a bit of a fail the very moment they even notice, actually). I’ll go in a future blog entry on why seamlessy melting into the environment is absolutely preferable to coming out with “clever” ideas that stick out, even if it seems counter intuitive.

Today: IconItem. From 4.10 there is a new element available in org.kde.plasma.core It’s used whenever you need to represent an icon in a plasmoid (or an active application).

This describes semantically an icon: as everything in plasma you should only describe it, and not care at all how it looks (that’s the task of the component, of the themes, of the final platform and of the global settings). Also, as common in QML, it’s just a painter, doesn’t have any event management whatsoever (so you will do it in a MouseArea for instance if needed).

To use it you just have to do:

import QtQuick 1.1
import org.kde.plasma.core 0.1 as PlasmaCore

PlamaCore.IconItem {
    width: theme.iconSizes.dialog
    height: width
    source: "go-previous"

And that’s it. A PlasmaCore.IconItem can load:

  • It can load: freedesktop spec icon names (like “go-previous”, or konsole”). It is the preferred way
  • QIcon instances (useful when the data comes from C++, such as a QStandardItemModel)
  • QImage or QPixmap instances (again. useful pretty much only when the data arrives from a c++ part)

Some behavioral properties:

  • If the icon name has been provided, it will try to load the “best” icon it can find: it tries first a plasma themed monochrome SVG icon from the theme. If doesn’t find it, it then falls back to the classical oxygen icons.
  • For small sizes, (from 16×16 to 64×64) it renders the icon to the nearest “right” size for which there is actually a n image for it on the disk, without trying to stretch it: no more blurry-looking icons! This is also the behavior for all panel icons in 4.10, so your panel will look way sharper.
  • If you set the property enabled to false it will look grayed-out with the same effect as all the disabled icons around KDE applications.
  • If a mouseover highlight effect is needed, set the property active to true (also a property binding like active: mouseArea.containsMouse is fine). It will have the same highlight effect as all across KDE applications.
  • State changes, like enabled/disabled or active/normal or icon changes, will have a short fade animation, that is coherent with the highlight animation of the icons in the panel, like the launcher.

So you should use it always when you have to represent a simple icon in a plasmoid. It is always preferable to the QIconItem component in org.kde.qtextracomponents (the latter should be used only when you can’t really depend from plasma).

You should not use it when your icon is actually meant to be a standalone clickable button. in this case you should either Button or ToolButton from org.kde.plasma.components. For instance, if you icon is in a delegate of a ListView and is the main “decoration” for the delegate (not a small button on a side), IconItem is the way to go, regardless if the delegate itself is clickable or not.

Internally, both Button and ToolButton of org.kde.plasma.components use IconItem to load their (optional) icon, so you are ensured a consistent look and behavior.

Let’s finish with a screenshot of an example where this new IconItem component is used: the system tray.

KDE Plasma Workspace 4.10 will have a system tray completely rewritten in QML (a lot of kudos to Dmitry for this!) and looks like this:

new system tray

Don’t see any difference? yep, that’s the point 😉 It looks exactly the same without losing any feature, it just behaves better, its layout is more reliable and the code is an order of magnitude simpler.

Btw, in this post, as well the last post by Aaron, there is also a little taste of something else… different.

Lazy loading QML


What is one of the most important things while writing a QML UI? the answer is pretty easy: KISS.

There are several reasons: the first is of course a reason that is pretty valid in any UI in general: the more an interface is simple, the less visual elements there are, the less redundancy, the more elegant and easy it looks (attention: it does not mean less features, it means just better design
in their representation)

And second, of course the more objects are on the screen, the more memory is taken for their representation, sometimes a non negligible quantity.

Another thing that is very important is to actually load your interface only for the things that you are actually showing right now on the screen, anything that is hidden, or can be shown just eventually, should be instantiated only just before actually showing, otherwise you are paying in startup time and memory for some objects that may even never be actually shown to the user.

A typical example is a tabbar with maybe 10 pages, if those pages aren’t performing an important background task (like loading an html page) why bother loading them?

I’ve just added a new very simple QML component in org.kde.plasma.extras: ConditionalLoader.

It works pretty much like a standard loader: you specify a source component and it instances it, but just when a certain condition is satisfied, so for instance:

 import QtQuick 1.1
 import org.kde.plasma.components 0.1 as PlasmaComponents
 import org.kde.plasma.extras 0.1 as PlasmaExtras

 Item {
     PlasmaComponents.TabBar {
        PlasmaComponents.TabButton {
             text: "foo"
             tab: fooTab
        PlasmaComponents.TabButton {
             text: "bar"
             tab: barTab
        PlasmaComponents.TabButton {
             text: "baz"
             tab: bazTab

    PlasmaComponents.TabGroup {
        id: tabGroup
        PlasmaExtras.ConditionalLoader {
            id: fooTab
            when: tabGroup.currentTab == fooTab
            //source can be a path name as well
            source: Qt.createComponent("Foo.qml")
        PlasmaExtras.ConditionalLoader {
            id: barTab
            when: tabGroup.currentTab == barTab
            source: Qt.createComponent("Bar.qml")
        PlasmaExtras.ConditionalLoader {
            id: bazTab
            when: tabGroup.currentTab == bazTab
            source: Qt.createComponent("Baz.qml")

In this example (simplified, without anchors and whatnot) the content of the tabs is in separated files, and they will get loaded only when the tab will become the current.

It may be used also to do other stuff, like in PopupApplets to load some things only when the popup gets open for the first time, or in delegates of listviews to load extra ui parts when the user clicks on an item, or whatever many other uses.

Active three


Today we have a new release of Plasma Active: quite some time passed since the last release last year.

OGG version


Plasma Active 3 has several new applications out of the box, to reinforce the philosophy of “useful by default”.

  • Add Ons: an add ons store, where both the client and the server side are free software: right now are available a collection of wallpapers and all the thousands of ebooks from Gutemberg. Different kinds of content like more books and apps will come shortly.
  • Advanced file management: in mobile devices often the files are walled behind the single applications or cloud services: while is fine to have also that possibility, you should be more in control of your files. Plasma Active by default comes with an advanced file manager that lets you manage your files with timelines, tags and other advanced semantic features (thanks, Nepomuk 😉
  • Alarms: not much to say here, it was a must for a mobile device 😉
  • News reader: a convenient touch interface to browse your favourite rss feeds.

Incremental improvements

Compared to the Plasma Active Two release running on the same device, there is a significant improvement in stability, boot time, apps startup time and rendering performance.

Base OS

A quite visible one is that the official release is now based on a different OS: welcome to Mer.

Mer continues the effort of MeeGo, but in an more open, community-oriented way. It’s a lightweight Linux based OS with a high accent in offering the possibility to build customized final distributions, with adaptation for specific hardwares or specific end user software.

Many still remember what pain it was to set up correctly the old scratchbox based build environment for maemo, (or pain common for many embedded development environment for what matters) In Mer setting up a development environment is matter of probably 10 minutes or so.

The high customizability of the base OS of Plasma Active also means that is ideal to build highly customized verticals for the enterprise environment.

Notifications, let the redesign begin


So, it seems it’s that time of the year again… the plasmoid used in KDE Plasma Desktop to display notifications and the progress of transfer jobs started to really show its age, due to some bad limitations in the old QGraphicsview code to handle complex layouts, so it appeared quite buggy and not so smooth to use. Yes, I’m aware that sometimes it started to dance resizing itself several times in a row, and there wasn’t much to be done on that regard… Until now 😀

The fact that there is some research/development being made to build a new backend for notifications that will support many new features, more “modern” to be actually useful with the applications that are so heavily “communication” oriented(both desktop clients and web stuff), that became essential part of out workflow.

The story begins more than a year ago: we needed a way to display notifications on Plasma Active, and obviously the desktop applet used back then wasn’t enough.

Since we would have to rewrite it in QML anyways, we started it, at the beginning as a thing used only in Plasma Active.

Here below is the status that will be shipped together Plasma Active 3, in about 2 weeks (more on that later 😉

WebM version

Then, as it became more and more feature complete, it was obvious that it could have replaced the one used in the desktop quite easily.

But wait, we have different input methods so we need two completely different things otherwise one won’t be usable on the other platform, right?

Wrong 😉 what we need is a different UI, and not even dramatically different: we need it adapted for a different input method and yet still familiar, the actual code difference needs to be very little.

In QML plasmoids, we can specify some files that will be used only in some platforms, so the system will automatically pick the most suited one. Also the basic component used (buttons, scrollbars etc) while having exactly the same API on all platforms, they can have a radically different behavior (or even, a completely different implementation).

Here is the plasmoid that is going to be merged and shipped with our next iteration of the desktop:

OGG version

While it looks very similar, there are some important differences:

  • Different theme/look (that was easy;)
  • The desktop version has scrollbars, the touch version works by flicking and has scroll indicators that automatically appear/disappear
  • The touch version has way bigger hit targets
  • The desktop version has mouse over effects, the touch version doesn’t
  • The text in the notifications can be selected with the mouse in the desktop version, and there is a right mouse button menu that allows to select/copy to clipboard
  • Instead, with an horizontal drag on a notification on the touch version, it will be moved, and if “thrown” outside the window, it will be deleted.

Difference in code? a couple 100-something lines QML files that are chosen either one or the other, that’s it.

The desktop version has more or less the same functionality as the old version shipped with 4.9, the changes are mostly about making the ui a bit simpler.

Also, this new notifications plasmoid is all about the user interface. It has been designed to be as easy as possible to change (or add a new one) the underlying notification system, so it will fit pretty well in the new system that is being researched right now.

Note about QML plasmoids and dataengines


There is quite a lot of work going on in plasma land at the moment.

For PlasmaWorkspace 4.10 you may expect an overhauled visual appearance and an overhauled user interface on some plasmoids.

The two weather plasmoids and the pager were rewritten in QML by Luis as part of his gsoc, while others are in the works.

The Notifications and jobs plasmoid is in the works, solving many behavioural bugs that were a limit of the previous architecture (more on that later;)

A Kickoff replacement is on the works as well, and if everything goes allright another important one will arrive for 4.10.

This is made possible by the contribution of the people, I’m seeing a renewed interest in working on plasmoids, also due the new architecture that significantly decrease the learning curve.

But, there is always a but 😉

There is a small problem I seen in some converted QML plasmoids: sometimes the needed data arrives from a Plasma dataengine. there is a nice system to map that data directly to a model usable in a QML ListView, Repeater and so forth, DataModel from org.kde.plasma.core

This is a (strong) simplification of the device notifier plasmoid:

PlasmaCore.DataSource {
    id: sdSource
    engine: "soliddevice"
    //hpSource is a datasource connected to the hotplug engine
    connectedSources: hpSource.sources

ListView {
    id: notifierDialog

    model: PlasmaCore.DataModel {
            dataSource: sdSource
    delegate: PlasmaComponents.Label {
        text: i18nc("@info:status Free disk space", "%1 free", model["Free Space Text"])

The keys of the dataengine are directly mapped to the ListView model, so directly accessible to the delegates via the “model” variable, or directly as their own variables.

However, due to a limitation in QML, if the dataengine doesn’t immediately do a setData() of a particular key, or a key is not always available, it won’t be mapped as a role in the delegates, if you encounter this roadblock, feear not, you can still access the data with something that in the above example would map sdSource.data[“DataengineSource”][“Free Space Text”]

When possible tough use the model mechanism, since some nice optimizations are planned for it 😉

One of the things I wish for plasma2 is a formal specification of dataengine available data in a way that would avoid situations like that and most important nice documentation may be extracted from 😉

Click here to lend your support to: KDE Randa Meetings and make a donation at www.pledgie.com !