Tag Archives: active

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

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.

Workspace sprint


Last week I was among many other KDE fellow hackers at the Workspace sprint in Pineda de Mar, It was a really awesome location (and company, of course;).

But is not all fun and play: what we have produced while there? What it’s a bit different from other times, is that it wasn’t a coding sprint, but rather was a very needed moment of taking a step back and reflect about the future.

We are in a transition period from a technological point of view: Qt5 is coming and the KDE frameworks effort is helping to redefine the whole developer story around our tecnology… but this is another story 🙂

This is the ideal moment to see where we are now in term of what we offer to the user, and how the whole workspace is perceievd as a whole. The first important thing is indeed exactly realizing and knowing where we are now, having a big picture from different sides.

At this point we can have a defined and realistic vision on where the workspace should head in the next years, and how to get there.

To get to this comprehension on where we are and were we want to go we are starting to use several classic tecniques of design, such as personas (hello Carla and Raj) and role games that help to identify problems (speed boat) and current or future features (Product tree), of which Sebastian and Kevin already explained it in length.

Looking at the problems of the boats and the Product tree, among the other things two stick out: Activities are a feature that really stands out of the pack: nobody else has it, but in order to be really a game changer has to be expanded a lot and be way more “natural” to use.

Also, workflows that spread across multiple devices are becoming more and more common (they are very important for Carla and Raj); our device spectrum effort is the right thing to do, but has to be more integrated in the core development process of everything we do as a community, and has to look more integrated (communication and marketing goals).

Other wiki pages and documentation on what has been going on those days will come up over the next few days: we’ll keep you posted.

Maliit and Plasma Active


Until now Plasma active had an on screen keyboard that served us well, but due to its implementation had some limits that couldn’t be easily overcome.

However there is a Qt based virtual keyboard project that is very promising: Maliit

It’s the one that was used in the Nokia N9, and already made a good progress since the version used there.

To have a good user experience on Plasma Active it should be well integrated, both as in look and behavior with the rest of the environment. Luckily Maliit is transitioning itself as well to the use of QML to write the user interface, making very easy to switch to a platform specific UI while all the logic stays untouched (I must say I’m quite impressed by this input method framework).

This is the result of just some hours of work towards a keyboard interface that uses Plasma UI components, and hopefully it will be in the next Plasma Active release.

OGG version



This year with basysKom working on Plasma Active has been very productive, I got to work with really amazing people and I really think we produced something really good.

As I said it has been a very positive experience and I’m looking forward towards future contributions by basysKom and all the other people involved to the Plasma Active project. But things change, and riding, embracing (and provoking) changes is a sign of good health they say :p

Just a little heads up, I’ve now joined Coherent Theory, that means that yes, I’ll continue to work on Plasma Active on the time being, and on the immediate, I’ll give my little contribute to make the Vivaldi release as good as possible 😉

Plasma Active resource browser


Sadly I didn’t have much time to blog lately, but luckily today i found some time to do a screencast like the good ol’ times.

What’s shown here is an application that will be pretty central in Plasma Active 3: it’s a file browser (or a Resource browser, it can actualy be about much more than files). Basically this will be the central point to manipulate stuff in Plasma Active.

You can browse all the resources by type, by date, with a timeline representation which can have a zoomed level of detail, so browse by year, by month, by day.

You can select files with a two fingers gesture and then via drag and drop you can move them between the internal storage and a removable device such as a microsd, delete them, or tag them (think about the Google+ circles ui)

OGG version

The ui is all built using the Plasma QML components, keeping a coherent look&feel with everything else, the general feeling of the ui is aiming to be quite natural, with animated, and real-material feeling surfaces, with a plausible phisical disposition, like the main area that can partly slide in/out to reveal the contents hidden under it, namely the sidebar of controls such as tags and timeline.
But yet is not trying too hard to mock some real object: mobile uis that have things like a wood texture background really go too far and besides being completely incoherent one to another,

Plasma active device profiles documentation


The thing we always stressed out in Plasma Active is how the system is designed to fit a whole device spectrum, even if the first two releases are explicitly about tablet devices (and in the near future this is not likely to change 😉

But how? it’s pretty obvious that one user interface doesn’t fit all for sure. Some devices, like mobile phones could share let’s say the 60% of the QML UI written for the tablet, some other, let’s say set top boxes could need something radically different.

The Plasma Active shell is actually something that doesn’t provide any user interface at all, but instead provides some basic features in the logic: manages the user Activities and loads the plugins that will provide the actual user interface, assembled like a LEGO to fit the user experience of a particular form factor.

About user interface plugins: the central parts are Containments and Applets, that are familiar from Plasma Desktop, a new one is a package format used to distribute stand alone QML files sets, and a very important one in the Plasma Active shell is the Home screen.

The Home screen package is a set of qml files that behaves the basic behavior of a Plasma Active shell, such as how Containments are managed, and manages other pieces of user interface such as the activity switcher, the top panel, the application launcher and the recommendation overlay. So by changing this it’s possible to change a lot of the behaviour of the Plasma shell (a particular device could also require a different plugin for the main containment, as they are different between Plasma Desktop and the tablet version with its browser of Nepomuk resources)

To make easier for developers that are interested in new form factors to heavily customize the look and feel of Plasma Active, I’ve put together a wiki page that describes how to proceed writing a new homescreen, and what is the API used in the communication between the shell and the QML part.

Plasma QML documentation


Just a brief heads up. As you know, from now on the recomended way to write plasmoids will be using QML only, and using the new components api for common widgets such as buttons, sliders etc.

What’s cool about this API is that is as compatible as possible with Symbian and Harmattan(N9/N950), so porting to and from those platforms just became a tad easier (That’s especially important in the perspective of Plasma Active).

The documentation of those components just landed on api.kde.org, and can be seen here.

Other useful resources for QML plasmoids:

A big thanks to everybody that helped writing the documentation, to Antonis that helped with the script for the generator and Allen that helped with the setup of the infrastructure to api.kde.org 🙂