Next Iterations of the KDE Workspaces

In this post, I’ll try to provide an overview of the results of the work we’ve done during the Workspace sprint in Pineda de Mar, Catalunya, Spain. The sprint is still going on, unfortunately I had to leave early to attend a friend’s wedding. Before going into any details, a few thank yous and credits are in place: Aleix Pol and Alex Fiestas for being excellent hosts organising this sprint (including picking this terrific location which allowed us to concentrate 100% on our processes and 0% on the beach), KDE Spain for sponsoring our food, the KDE e.V. (and its donators!) for sponsoring travel expenses and providing organisational backing, Kevin Ottens who took a sizable slice of time out of his vacation account in order to facilitate meetings, enabling group dynamical processes and generally being a good moderator, Björn Balasz for chipping in time and providing his background in psychology and usability and of course open-slx, my awesome employer.

Activities central: One focus that we have been working on in Plasma quite extensively is organising your documents, contacts, applications, files and other digital assets into Activities. Activities provide a contextual way of organising your devices. Activities usually enclose these resources into personal context which might include locations, contacts, documents and any other resource we’re able to express in terms of semantics. (So pretty much all. :))
We’ve identified areas where we can improve the activities workflow. Switching between Activities and getting an overview can surely be improved. There have already been some ideas floating around, and some smaller and larger improvements are in the pipeline to see the light of day in one of our future releases. In some parts, we’re transplanting features we have matured in the Plasma Active user experience into the desktop. The Plasma Way: Share code across devices, investigate workflows across apps and device borders. (So a workflow which we want to enable may actually involve using more than one device — we want to make especially these patterns a lot easier, intuitive and fun to use. There’s a few real challenges in there, although many parts involve someone “just sitting down and doing it”.

Personas: I’ve dedicated a separate blog entry to Carla and Raj, our brand new personas, so I’ll kindly refer you to that.

Social networks and messaging: Carla’s and Raj’s lives involve talking to people across different channels. We want to enable these patterns by providing deep integration of messaging and social networks into the desktop. While we likely will not ever support every single feature of all social networks, we definitely want things like native notifications for messages, and being able to keep tabs on the going ons around you. Technologies we’ve been working on in the part years and which are coming to mature now will be a great help in creating a nice user experience here: Akonadi, Telepathy being at the forefront of double-plus-useful frameworks here.

Along with the integration of more social services into the workspace, we also want to enable cross-device workflows using online services. Examples for getting your data across devices are ownCloud, but also commercial services like FlickR. I think we are in the position to put Free software solutions first, but not excluding proprietary services, but enabling Carla and Raj to mix and mesh whatever they uses. In this, we need to pick up the user where he or she is now. We’re not going to switch users to Free software users if we require social disruption in their lives. :)

Something I found particularly exciting was the call by a few participants to reinvigorate Project Silk. The idea is to make the web, web apps, -applications and -services first class citizens in the desktop. This can range from the introduction of a site-specific browser to deeper integration of online content and services: think of FlickR integration in Gwenview, caching data from online sources, providing native UIs for services that are otherwise a bit cumbersome to use, and much, much more. I’m surely hoping we’ll see a surge of improvements in this area. I’m also happy that Richard and I documented our ideas quite well when we came up with them in 2009 at the Desktop Summit in Gran Canaria (coincidentally also Spain, at least technically ;-)).

There’s almost too much exciting new ideas that it’s hard to report about all of it without choking your feedreaders or webbrowsers, so I’ll just mention a few more telegramme-style. Feel free to ask in the comments if you have specific questions, or just head over to the mailinglist where you can discuss with the whole team involved.

  • As base for identifying needed improvements, we will concentrate our thinking on which workflows we can enable for users. This first line of identification will be thought about without a specific device in mind. Much more so, workflow can and often do include different devices. We want this to be at the heart of our designs.
  • Virtual desktop will remain what they are, orthogonal to the principle of Activities, We do not plan any sweeping changes here, in order not to break engrained workflows. Nepomuk synchronisation across devices is still a very challenging problem. It needs more design and research work to define an achievable scope.
  • We’ve proposed a few changes to KDE’s release rythms, basically decoupling the releases of workspaces, applications and (in the future) KDE Frameworks. This is basically a continuation of KDE’s effort to implement branding closer aligned to how we work and what we produce; currently under discussion.
  • Notifications will likely receive a rework in order to make them more activity aware, and to display insensitive information on a lock screen, just to name two examples.
  • Everybody agreed that stability and quality are key for users. We will avoid disruptive changes, but concentrate on making existing tools better, and new features not get in the way of existing workflows. A few changes in our processes have also been planned,
  • Clemens of Blue Systems attends the sprint as well, it’s good to see new faces participating and supporting KDE. We’ve had very interesting conversations about all kinds of topics.
  • Maybe the most important thing was the sharing of the Plasma vision with a wider team of contributors. It strikes that Plasma lately has been moving so incredibly fast that we built up a backlog of communication, some of which we managed to knock down in the past days, but it surely will take some time until all ideas, concepts and processes are ingrained into everybody’s brains. The first steps for this have been taken, however.

As you can see, that’s a lot of stuff we have carved in sand in the past days. It will need refinement, and consolidation, more design, ungodly amounts of hacking and surely won’t all be implemented in a whim. It does however give everyone a good idea where we’re going, and what the steps into that direction are. Exciting times ahead. If you’re looking for more sprint results, I’d also read Marco’s blog about it.

Saying good bye was relatively easy this time around, as most people attending the sprint will also be at Akademy, which starts in two weeks in Talinn, Estland. The next Plasma sprint is planned in September in Switzerland. The plan is to mostly work on libplasma2, QtQuick2 and Frameworks 5 in order to technically pave the way into the future of the Linux workspaces.

More WACkiness

An example WAC app running in Plasma

After Marco had added initial support for WAC apps to Plasma, at open-slx, we spent a few cycles on taking this to a next level. WAC apps are apps written in HTML5 which are shipped as packaged websites with everything needed included in the package. On top of the normal webbrowser APIs, WAC apps can access a set of API calls that allow access to various aspects of the underlying system, device and network information, contacts, hardware such as camera, accelerometer, location sensors, etc.).

Most of the hard work is already done by the excellent webkit. The parts needed in Plasma and KDE are support for loading the package format, and allowing access to certain system APIs. Marco has written an AppletScript Plugin, which basically wraps the WAC format into a Plasmoid so it can be loaded into any Plasma Shell (Plasma Desktop, Netbook, Active, MediaCenter, etc).

Implementing the WAC-specified APIs turns out to be quite a bit of work. I have started on the DeviceStatus API, and on my laptop, HTML5/WAC apps are now able to access system information such as software versions and battery status. The complete WAC API is quite big, so right now we only support a small subset. The basics are done, and with growing support in this API, we’re able to run more and more apps on Plasma devices.

Plasma asking the user for permission to run a certain app

In the screencast, you see how WAC apps are running inside Plasma Desktop. One interesting thing I’m explaining is the permission model, so I’d like to go a bit more into details about this. WAC apps have the concept of so-called features. The app can check which features are available on a given platform, and then provide or remove features. Plasma’s equivalent to this concept are extensions, which maps a bit, but not too differently. I’ve added a translation mechanism between those two, so what the app is now asking for is access to specific Plasma extensions, very much like our JavaScript Plasmoids.

Everything is running inside a sandbox (in our case a webkit container inside Plasma), so it is quite easy to restrict everything beyond the browser’s DOM API. When working on the permission model, I reflectd about how the user actually handles these permissions. Many people seem to complain that even if the app announces which APIs it wants to access, the user still does not really have a choice beyond all-or-nothing, so most people end up blindly OK’ing whatever the app wants. The code for WAC in Plasma is set up in a way that we can allow access only to certain bits of the API, disallow access or — and that’s the catch — fake access. Fake access means that we tell the app that we support certain APIs, but we will only deliver empty or bogus data, so the app still works, but our address book is not in jeopardy of being sent to some blackhat in a far away country.

Watch on YouTube

Plasma Active Balsam Updates Available

I’ve compiled an update to the Balsam Professional Plasma Active packages in the last weeks, they are now are available for your upgrading pleasure. While the packages work very well in my testing, they are still only development snapshots, so if you’re happy with your current Plasma Active, and you need to be absolutely sure everything keeps working, I’d advise not to upgrade. In all other cases, you’re in for a good performance kick, a lot of bugfixes and a few new, but important features.Instead of boring you, my dear audience, with a long piece of text, I got out my webcam and recorded a screencast of these packages running on my viewtab (an Atom-based 10 inch tablet). Lay back and watch.

Watch on YouTube

In the screencast, I’m showing the general workspace UI, as well as a few new apps and features, file browsing, microblogging, news reading workflows, which we’ve been improving lately.

The packages work fine on wetab and exopc tablets, and most likely also on other Intel-based tablets. Builds for various ARM flavours are available throught the Mer project. As Balsam Professional 12.1 is compatible to openSUSE, they will also work there. If you want to install the packages in your desktop, be advised that this might mess with your desktop sessions, so that’s essentially at your own risk.

The Balsam Packages are made available by open-slx and built and served from our Open Build Service.

Plasma Active: Crunching towards One

Plasma Active aims at creating a desirable user experience for a spectrum of devices, based on a fully Free software stack, developed in the open. The first release is planned for October. In the following article, you can read about the latest status and recent improvements made.

One our way to our first release (begin of October as it currently looks like), we’re in serious make-it-work mode, crunching bugs left and right and filling in gaps of the workflows we want to suppport in our first release of Plasma Active. As we’re a month away from that, it’s a good point in time to give an update of our progress towards Plasma Active One. So where do we stand today? What has been the progress lately?

An Activity as web launchpad

My overall impression of the state of Plasma Active is very positive. We’ve made some tremendous progress, and are now at a point where we’re confidently calling it a beta. If we continue at this rate, Plasma Active One will be a very interesting first release, and a lot of fun to use. The basic functionality is in place, the focus is shifting from filling in gaps in the UI towards performance and interaction improvements, and bugfixes. In ten days, we’ll be meeting at the Basyskom offices to finish Plasma Active One, plan the release process and communication bits around it and think about what Plasma Active Two will look like.


Contour, our semantic workspace has seen a number of UI flow improvements, better visual hints and ergonomy enhancements. Switching between activities is much faster now, and it has become easier to add Bookmarks and applications launcher to the Contour activities right now, and a few bugs in the wallpaper handling have been fixed. The top panel now drags a lot smoother. Contour feels solid, performs well and really starts to work nicely for every day use cases. I’ve been starting to use the Activities more actively, it serves as a very useful tool, and brings a very innovative concept to the tablet. Most importantly, it adds real value, while not getting in the way. Mad props to basyskom for working with us on this integral part of Plasma Active. The Contour workspace offers resources such as documents, bookmarks and applications), connected to one Activity. As an Activity, you can think of “Planning a trip”, where you’d collect your ticket receipt, bookmarks of the hotel, your reservation) for example. The Contour shell shows those resources, and you can extend this with Plasma widgets which provide additional information, or small apps inside your activities. Activities also serve as launchpad for apps and the webbrowser. On the left, you find the recommendations panel, which are “magically” (based on real science!) provided by the system based on their relevance to the current context. The recommendations are non-intrusive, but turn out to be quite useful during normal usage.

Kwin compositor

We’ve integrated a few performance fixes in KWin now. One fix is especially interesting, as Kwin now skips disabled plugins entirely in its frame rendering cycle. This makes a noticable difference on a desktop system, but it really pays off in Plasma Active, where we’re using only a very limited number of effects.
We have experimental Balsam packages that use OpenGL-ES for the compositor, which fare nicely in my stability tests. Martin has been making kwin a real winner.

Keyboard Improvements

The virtual keyboard now works in more applications, some would not pop up the keyboard when needed, which makes konsole for example pretty tedious to use. Fixes for Kate, Konsole and Calligra have already upstreamed.
Getting at the ‘second layer’ of keys in the keyboard is also much easier now, as double tapping shift acts as ‘lock’ here. There’s also a good bunch of performmance improvements in there, so typing also feels more swift. It’s now also possible to quickly move the keyboard to another screen edge, in case it hides interesting information beneath it. Aaron has been bugsquasher No#1 here.

Webbrowser's history and bookmarks

Web Browser

The Active Webbrowser has seen a bunch of improvements which make it a lot more usable and enjoyable. New features include that opening windows is now fixed. I’ve implemented sharing cookies across the whole system (using KDE’s cookiejar), uses KIO for loading (and caching) the page content, remembers passwords and completes your text input from the browser history and your bookmarks. KDEWebKit makes all this very easy. Marco fixed Flash support, so watching youtube on your Plasma Active tablet is now possible as well, in that area we’ve successfully surpassed the iPad. ;-)
I’ve borrowed the Adblock implementation from Rekonq, so the browsing experience a lot cleaner now, which is especially important on mobile devices where you might be short on bandwidth (blocked ads are not even loaded at all), the screen space is often more limited, and animations used in banners are an unnecessary drain to the battery. The browser is maturing. Features such as Share-Like-Connect extend the web browsing experience naturally to the overall workspace, which also serves as a launchpad for the webbrowser as you can see in the first screenshot. On top of all that goodness, Marco has created a purty icon for the Active browser.

Recent Screencasts

Marco has published an interesting blog with a movie showing Share-Like-Connect, on of the new concepts we’re delivering with Plasma Active.

OGG version

Aaron explains and demoes the overall concepts of Plasma Active and Contour, its semantic workspace.

If you’d like to read up on the general ideas of Plasma Active, our wiki pages provide an excellent starting point. For our German-speaking audience, the Plasma Active section on the open-slx Wiki is a good place to share experiences and ideas.

Personal wishes go out to Maurice, our tireless Meego-Ninja who broke a finger in a bicycle accident, and Fania, Contour chief-design princess who got married.

Plasma Active on OpenGL ES

The past weeks, I’ve been working on getting Kwin, the window manager and compositor in Plasma Active (and Plasma Desktop ;) to work on top of OpenGL ES instead of OpenGL. After some updating of packages lower in the stack, especially Mesa and parts of Xorg, we now have working OpenGL ES support on our hardware. Today, I’ve finished packaging it as an option on top of our Plasma Active packages. These packages in the :Devel subsection of the KDE:Active repository in the OBS run on top of Balsam Professional and openSUSE 11.4. We will give this some more testing and improve a few things, in order to move to GLES by default. OpenGL ES is very interesting as this is an API often used on mobile devices, so I’m glad that I can state that we’re ready for this. This of course needs proper support in the drivers, something we can not always solve by ourselves. I have been running this successfully on two Intel Atom-based tablets.

Contour showing the Froscon activity

All the props of course to to our Akademy-award winning window management and compositing hero, the one and only Martin Grässlin. He’s been working on OpenGL ES support (and a lot of other features to make kwin “ready for the future”) for quite some time already. OpenGL ES support in kwin has been introduced in the recent Plasma Desktop 4.7 release, a few weeks ago.

So, is it much different? Nope, it’s very much a thing of underlying technology. There’s no noticable performance improvement, but it runs stable and well. Given that OpenGL ES support has only very recently been introduced in kwin, it’s already surprisingly good. There is probably still a lot of room for improvement, which is something we can investigate now and easily test much better.


In the screenshot of the Contour shell of Plasma Active, you can see that I’m all set up to go to FrOSCon tomorrow, where I’ll be presenting the ideas and demoing the prototypes, hoping to get some feedback on concepts, and give some understanding of the challenges and opportunities we face in this exciting endeavour. And of course show some serious bling. :) If you’re in the area around Bonn, drop by.

KDE:Active:Devel introduced

The past week, when working on the Mesa packages for Plasma Active, I might have caused some headache since I broke the compositor in Plasma Active with a few packages I uploaded for easier deployment on test devices. It was not more than an annoyance, because kwin gracefully falls back to non-composited mode in case of graphics problems. In order to get a bit more stability into our deployment process, I’ve now set up a subproject called KDE:Active:Devel under the KDE:Active project on the Open Build Service (OBS) which we use to build the Balsam packages. As we’re moving, development-wise into the stabilization phase for Plasma Active One, this makes testing new things a lot easier, just by switching to the same package from the :Devel branch. Conversely, this means that if you install packages from the :Devel subproject, you should really know what you’re doing. On the bright side, it’ll be easier to keep regressions out of the packages that are deployed on most users’ machines. Contour showing the Froscon activity

Along with these changes, I’ve updated all the packages to the latest state of the art, and worked a bit on our documentation, as we keep getting very good feedback about this. Among the most wanted fixes we’ve introduced is a patch by Aaron that makes konsole usable with the virtual keyboard, making another very powerful tool usable on Plasma Active. I’ve also fixed up some default configuration options, polished up the contour packages and made that used by default. (Those who have plasma-tablet-config on their machine will have to replace it with “plasma-contour-config”, though.) This is another pretty big move, as we now basically regard the contour shell stable enough to make it into Plasma Active One. It’s also very, very shiny I must say, the usual disclaimer about alpha software notwithstanding.

OBS makes it rather convenient merging changes back and forth between these branches. In general, my impression is that OBS works very nicely as a collaboration tool, and solves a very complex problem for us, the “how do we get our code onto the device”. As an aside, it also makes it very easy to build packages locally, so for even shorter development-deployment cycles, one can build locally and rsync packages onto the device. With the right kind of script setup, that takes a lot of the pain away, that development for mobile devices often brings with it. The KDE:Active:Devel repo can be used directly by developers to upload their latest sources in order to deploy them to their testing machines, and we can pull working versions in from there. Rocking.

Installing Plasma Active on the ExoPC (“WeTab”)

If you own an ExoPC, and you’re eager to know how to get Plasma Active, our new workspace and set of applications for consumer devices to run on it, this blog article will help you get going.

Note: Plasma Active is in alpha state right now, it is basically usable, but you will find many rough edges. You should not try this unless you consider yourself an early adopter, or if you mind fiddling with bits and pieces. We are working towards an end-user ready product, but we’re not yet there.

Plasma Active

What to pick?

There are a few different options to choose from, I’ll quickly explain which to choose under which circumstances.

  • MeeGo: Works well overall, but is lacking in key areas, for example we do not have a UI to connect to wireless networks yet, and as the device doesn’t have Ethernet (and cables are lame on mobile devices anyway). You can work around this with a trick Marco explains.
    Choose this option if you want to run and develop for MeeGo
  • Balsam Professional: Download the Balsam Professional live images from open-slx. This live image provides a fully functional live system without too much hassle.
    Choose this option if you want to try Plasma Active
  • openSUSE: Install Plasma Active on top of openSUSE 11.4, it uses the Active packages created by open-slx (me, my employer), but is a bit more laborious to install.
    Choose this option if you want to run the full experience on your ExoPC, or track progress and hack on Plasma Active

I will explain here how you can get to a state-of-the-art Plasma Active, using what will eventually become the Tablet Edition of Balsam Professional. Balsam Professional is, unlike openSUSE, focused on end-users and the user experience on consumer-level devices. Balsam Professional is based on openSUSE, so you might well be familiar with many of the tools already.

What you need

  • An ExoPC, or a WeTab
  • An empty USB stick of at least 700MB
  • A USB keyboard and possibly a mouse

Note that the installation is possible to do by keyboard only, but a bit more comfortable if you have a mouse available. As the ExoPC does only have two USB ports, one of which will be occupied by the installation medium for the first part of the setup, you either need a USB hub, or a combined receiver for mouse and keyboard. If you don’t have a mouse or the means to plug one in, don’t worry, it’s not really hard to do. In this case, I’d recommend to install the updated kernel package from the KDE:Active repo as soon as the base installation is done, as that makes the touchscreen work, from that point on, you won’t need a mouse anymore.
The process should take you about two hours, you might get it done quicker, but should be able to get it running within, say, one evening.

Getting started

The following points provide a detailed guide to installing Plasma Active and the Contour shell onto your ExoPC, using openSUSE. This process is also explained on the wiki, check there for the latest updates.

  1. Install openSUSE 11.4: Download this image, Use “dd” to write it to a USB stick, or use the excellent imagewriter tool to handle this for you. after this step, you should have a bootable installation medium in your hands.
  2. Insert the USB stick into your ExoPC, boot it and install openSUSE 11.4 onto the machine. It’s wise to enable auto-login, and possibly the SSH server during the installation, since this makes your life a bit easier later on. You need a keyboard for this.
  3. Set up the repositories for Plasma Active:
    zypper addrepo --refresh \ kr47
    zypper addrepo --refresh \ plasma-active
    zypper modifyrepo --priority 90 plasma-active

    The last line increases the priority (lower value means higher priority) for the Plasma Active packages.

  4. Update your KDE installation to the 4.7 release, this pulls in the dependencies needed for Plasma Active. At this point, you still have a traditional desktop, you now update the KDE stack to the 4.7, and get a few updated packages as well (among them Mesa and a new kernel which is needed to make the touchscreen work and brings much better performance):
    zypper dup

    Accept all vendor changes.

  5. Make sure the 3.0 kernel is installed (“zypper if kernel-desktop”), if not install it with
    zypper in plasma-active:kernel-desktop  plasma-active:kernel-desktop-base
  6. Install Plasma Active packages on top. This will install the contour shell, some apps and configure your system to run Plasma Active, including tweaks to the defaut configuration that make the whole system more touch-friendly and suitable for mobile use cases.
    zypper in plasma-contour-config

    After this step, you have Plasma Active on your system.

  7. Reboot to boot the new kernel, the Active shell will start automatically. If you get a black screen past login, use a keyboard and ALT+F2, “konsole” to get a shell and try starting “plasma-contour” by hand. If the command is not found, as root, do “ln -s /usr/bin/plasma-mobile /usr/bin/plasma-contour”.
  8. Install additional packages, such as Calligra Active (package “calligra-active”) Kontact Touch (package: “kdepim4”) or the kdegames4 suite. Bringing you a nice collection of useful software.
  9. Hop into the #active IRC channel on, tell us about your experiences and help others gettting started as well. =)

On Tuesday at 14:00 UTC and on Friday at 12:00 UTC, we will organize online install fests on #active ( where we can help you with installation issues, and where you can share your experience with others. Of course you’re free to drop by and hang around at any time.

New Plasma Active Window Switcher

Last week, Marco and I have integrated a new window switcher into Plasma Active. We had designed and started to implement this rather central component of the shell during the Tokamak sprint a couple of weeks ago, now it finally made its way into Active, so you can update your system to the latest packages and enjoy it. (In order for it to work correctly, you’ll have to delete your plasma-tablet-appletsrc file, as we do not update these automatically at this stage of development). The new window switcher works very well, and is quite snazzy on top of that. It also contains an application launcher! I’ve recorded a small demo video showing these new features.

Window Strip

The idea is to have a non-modal interface, which means that the window switcher does not block, but allows to interact with other applications that are currently in focus. For this, we use a panel which can be dragged down partly or completely from the top, revealing a strip of windows that is horizontally flickable with the finger. This way, it works for only a few windows, but also scales quite well for those that want to have more apps open at the same time.

The implementation is a bit hacky, but only in the background. It is in fact a combination of QML and KWin’s compositing effects. We are basically catching move events, "polishing" these into a more straight stream of events which we then pass to KWin, asking the window manager to paint thumbnails of the windows at a given position. While we didn’t know if it would work at all when we came up with this design, luckily it turned out to be nice and very usable.

App Launcher

The new panel also has an app launcher, which allows you to launch an app. As the user might potentially have lots of apps installed, there’s a "tag cloud" which lists categories of apps (you tap on one and it shows only apps in the category), and a search field you can use to find apps. (There’s a theming problem which affects readability in the tag cloud, we’ll fix that shortly.) As the number of apps available might not fit into the available screen space, you can flick the apps grid horizontally to reveal more apps.

These features have already been merged into the KDE:Active packages on the Open Build Service, and you’ll be able to try them on your device with the next Balsam Professional Live image.

What do you think about these new pieces in the UI?

Plasma Active Updates

During the past weeks, we’ve been kind of silent around Plasma Active. This doesn’t mean we’ve just been sitting on our lazy bums, but that we’ve poured a lot of work into various aspects of the Plasma Active user experience. Let me details these changes to give you some idea of where we are. But first off, …

What is Plasma Active?

Plasma Active shell with widgetsPlasma Active is a KDE project building a touch-friendly user experience for the device spectrum. You can compare it to the KDE Software Compilation, Plasma Active provides a workspace and applications. The first focused target devices are tablets, such as the ExoPC, also known as WeTab. Plasma Active builds on top of KDE frameworks such as the Plasma libraries and the Nepomuk Semantic Desktop, offering a touch-friendly interface taylored to use-cases of the specific device. Components of Plasma Active are re-usable across different devices, bringing many well-known apps to new devices. The user interface used on a specific device can differ across devices, making sure it fits the devices characteristics and use-cases.

How is Plasma Active developed?

Plasma Active is fully community-developed and builds on existing KDE frameworks. Re-using technologies such as Plasma, we already have quite some usefl apps to run on Plasma Active, more apps are relatively easy to write or to port to Plasma Active. (I’ll explain more about this in a later blog.) One very nice thing is that Plasma Active by design is “ultimately hackable”, it uses components that many people know already, many aspects of the system can even be directly changed on the device by opening it’s QML files with the description of the user interfaces.
Plasma Active’s development happens in KDE’s Git infrastructure, communication can be followed on the mailinglist, our IRC channel (#active on is welcoming and open for everyone. This doesn’t mean that there’s no commercial investment in Plasma Active, or that it’s impossible to participate in Plasma Active as a commercially interested partner, it’s just that the foundation is in the hands of a Free software project — KDE — leveling the playing field for everybody else. Two good examples for commercial partners in Plasma Active are basysKom and open-slx. BasysKom contributes design and development effort into the Contour shell, which forms the basic workspace for Plasma Active. open-slx (my employer :)) invests into development of Plasma Active core components, system integration, packaging, testing and deployment. As such, we continously work on turning Plasma Active from Git Repo into something end-user ready — which is also our mission, we want to bring Plasma Active to the masses. For this, we’re releasing regularly updated Live Images of Balsam Professional running Plasma Active, and we’re working hard on making these images also installable. You can test those images in a virtual machine (you’ll want one that supports composited graphics, such as Virtual Box), or directly on the device. The Balsam Professional Live Image boots out of the box on the ExoPC / WeTab, and we’re working on support for more diverse hardware.

To keep track of our different focus points, we’ve created a map of the different “tracks” we follow with our development.

Where is Plasma Active Today?

System-wise, the current status is that we have a bootable live image (Balsam Professional) with a touch-friendly shell, a bunch of apps that can be used. Boot performance is a bit on the slow side right now (but improving, there are some changes to the boot process planned), runtime performance is pretty good already, as you can see in the videos that we’ve posted already. At open-slx we are working on refining the image in terms of preconfiguration, performance and so on. We’re also quite close to making the image installable, so you can easily install it once (as dualboot on your device, if you wish) and then keep tracking Plasma Active development just by updating your packages regularly.

During the Meego conference in San Francisco, basysKom demoed parts of Plasma Active and the Contour shell. A video has been recorded which gives a good idea of which direction we’re going:

On the software side, we’re working on a bunch of different things

  • Resource visualization: As we’re using Nepomuk as the underlying data structure, we’ve implemented data-driven widgets that represent “Things” in the Nepomuk store. These can be local files, online resources, but also abstract things like tags, for example. These “Resource delegates” as we call them form basic building blocks of your assets in Plasma Active.
  • Web-browser and web-integration: As “The Web” is one of the most important use-cases for Plasma Active, we’re spending quite some time now on making this work really well. After shopping around, we decided that our best bet on the web-browser would be a touch-friendly version of Rekonq, using QML. We’ve already made some progress towards that direction, but we’re not there yet.
  • Share-Like-Connect: Share-Like-Connect will bring ubiquitous (just *had* to use this word once ;)) social networking and sharing to Plasma Active. I’ll not go into details here since this topic is way too awesome, so we’ll dedicate a separate post to it.

From my personal point of view as a user, I must say that Plasma Active is becoming a rock star. It’s already quite usable for surfing the web, reading news or email. It is not stable software yet, more comparable to an Alpha state (there are quite some bugs left to be squished, and it’s not feature complete). Our progress is very noticeable, however, which is promising for our first targeted released end of September.

More info…

If you’d like to know more about Plasma Active, or follow its development, the following resources are interesting:

What’s new in Plasma Active?

We’ve been busy bees in the growing Plasma Active team, so it’s time to post some progress updates. In case you forgot, Plasma Active is a KDE project to create a desirable user experience for the device spectrum, with its first focus to create a system suitable for tablet computers. In my first post about Plasma Active, you can see the basic shell running on a 10 inch Viewsonic Viewtab. In this post, I’m using a Wetab to demo the current state of Plasma Active. The Wetab is one of our test devices. It’s a nice target device since it’s Intel Atom-based, which makes building Plasma Active a bit easier, and thus shortens our development-testing-deployment cycles considerable. The Wetab can currently be gotten from German Ebay for 219€ + shipping, so it’s also quite affordable.

Back to the software, though. Our focus in the past weeks has been two-fold, we’ve done a lot of “small fixes” which greatly improve the user experience. The other class of changes is less visible at this point, but still fun and exciting.

Virtual Keyboard Layout

new virtual keyboard layout The virtual keyboard is using a layout that is more suitable for tablet computers, containing more characters on the first, easily reachable “page” of it. This makes text input a lot less annoying (let’s face it, touchscreens are not ideal for typing as they lack haptic feedback, so it can only become so good). There’s still a bunch of things that would make the keyboard better, and of course it has its fair share of bugs, but it basically works and isn’t too annoying, either.

Top Panel and Window Switching

We’ve also done some work on the top panel, holding access to network, power management, the calendar and a bunch of other things. While the panel would slide out a bit in our early versions to make the hit area bigger, we found that this intermediate step is not necessary, we increased the default height of the panel a bit which works nicely. The panel is still meant to be slided out, but for a different purpose. We will be putting a strip of window previews in there, replacing the current appswitcher sitting in the top left corner. Most pieces for the new panel-and-window-switching mechanism are already in place, but it’s not finished yet.

Snazzy new Activity Switcher

New activity switcher in Plasma Active During Tokamak, Marco has merged a new, snazzy Activity switcher into Plasma Active. This activity switcher offers a wheel-like interface which you slide in from the right. It has previews (or rather post-views ;)) of your activities, and you use a small slider on those previews to switch to an activity. (These activities right now provide spaces for different sets of widgets, but will be given more meaning thanks to the Contour project, which develops a semantic workspace framework for Plasma Active. As all the parts necessary to make basic activity handling in Plasma Active work, we’ve decided to merge this new switcher already, since the “old” one was really very basic, and wasn’t quite so intuitive, due to lack of visual feedback (i.e. previews).

Try it!

open-slx has created a new Plasma Active image, which can be run live off of a USB stick, you can find the latest version here (spot the plasma-active.current.iso). There are also openSUSE and Meego packages available (the latter being a bit less mature, but we’ve made really good progress in the past days.)

If Plasma Active has spawned your interest, or you would like to find out how you can get your software to run on and integrate well with Plasma Active, get in touch with us, either on IRC, or via our mailinglist. You can find more information on the Plasma Active pages on communitybase.