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.
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.
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.
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.
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.
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.
The last line increases the priority (lower value means higher priority) for the Plasma Active packages.
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.
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
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.
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”.
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.
Hop into the #active IRC channel on Freenode.net, 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 (Freenode.net) 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.
MeegoExperts has done an interview here at the Desktop Summit in Berlin with Fania and Marco. The video explains concepts and user experience in Plasma Active‘s Contour Shell. Have a look yourself to learn about this next-generation user experience for consumer devices, based on our beloved Free Software stack.
I’ve been to the Desktop Summit in Berlin for the past few days, we’re now around the middle of the event, after the conference, before the workshop and BoF sessions, so I thought I might share some thoughts I’ve gathered in idle moments in the past few days.
Boredom and Diversity
Last night, the build system BoF was planned, a team session where we look at the way how we develop our software. I have to admit that to me, this is quite a boring (but nevertheless very important topic). As it also affects the way we release software, I’ve put my release team hat on and joined the session. I was a bit afraid that since it’s not the most sexy topic in the world, that little people would show and we end up with incomplete or broken ways to release the KDE SC, and KDE Frameworks in the future. My worries were ungrounded as quite some people showed up and we made good progress on all the topic we talked about. (If you’re interested what we talked about, keep an eye on the kde-core-devel and kde-buildsystem mailinglists.) What struck me is that in KDE, there’s enough people who feel responsible, even for boring topics. When I shared my (ungrounded) concerns with Stephen Kelly, he looked at me with this empty expression on his face and told me “but that’s exciting, it’s the way we build our software!”, and given his enthusiasm, I believe him (even if I don’t exactly personally share his excitement). Diversity makes us strong.
Collaboration and Sustainability
While during the last desktop summit, in Gran Canaria, there were really two co-located conferences, and for my taste we missed some opportunities to sit together with our GNOME peers, this aspect is much better this time around. I’m not sure wether it’s because we all figured out that we have to work more closely together, or if the setup of the conference enables us to work together more closely, I just see it happening. In fact, we sat together with a bunch of GNOME guys until late last night, discussing challenges the Free software ecosystem faces, and possible solutions to these. We focused on these shared challenges instead of the diffferences in our approach, and the differences in our community. We did think much more as one community, than as two.
Active Central
My current focus in KDE is of course Plasma Active, and our team of designers and hackers is fully using opportunities this event gives us to get the word out about Active, and establish it as our answer to the Freedom needs on consumer devices. Just like Matthias set out 15 years ago to conquer the desktop, to provide a Free, coherent, integrated and complete set of applications for users of desktop computers, we are setting sails to also reach this goal for a wider spectrum of consumer devices. We held a bunch of presentations during the conference track already. Martin Grässlin kicked that “Plasma Active track” off, talking about Kwin and Wayland, me doing a more general overview, then Marco and Fania explaining concepts behind Active’s Contour shell, and finally Ivan having us peak into how Nepomuk smartens up our devices by closely listen to what we do. The feedback so far has been fantastic, and I think we’re a step closer to reaching our goal of unifying our efforts regarding consumer devices, such as tablets, smartphones, media centers, and whatever will be invented.
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?
I’ll be travelling to two conferences this summer, where I’ll be presenting and demoing Plasma Active to the audience. Those are FroScon and of course the Desktop Summit to be held in Berlin.
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 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 active@kde.org mailinglist, our IRC channel (#active on irc.freenode.net) 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? We’re back to tacky K-Names? Don’t worry, just using the K to reminisce us of our roots. :-)) The Platform 11 sprint in Randa is now in full swing, while relatively little code is being written by the 24-ish people here (and the occasional visitors from one of the other 3.5 sprints happening in the same building, at the same time), we’re very, very busy. It’s basically work until collapse, sleep and start again. Kevin is applying his kanban magic to manage the sprint and get everybody focused and synched. Kanban Magic means that we’re using a wall and a lot of post-it notes with tasks and topics on them, and we move those post its through different stages indicated by swimming lanes on the wall, froom waiting through design, review to done. The first note has just passed the review stage and is now in done state: our first accomplishment. :-)
As we’re working on issues central to how we all (KDE and Qt hackers) develop, I’m sure you’re impatiently waiting for results to pour onto the Internet. While our first focus is on personal interaction and using the facetime and “high personal bandwidth” to solve hard problems, you can get at least an overall impression of the direction of our work, as we’re tracking our results on the wiki.
What is really good and healthy to see is the number of different stakeholders (sometimes represented by the same person wearing multiple hats). This way we can make ‘reasonably sure’ that we take different point of views into account, and find solutions that work for us all. One might expect that this results in endless discussions, but in practise, most of us are on the same page, and where we’re not, we’re taking the time to sync up and see how much common ground we have, and how we can take advantage of that. There are people from up and downstream, from subcommmunities and companies, and people that all have different stakes in the KDE platforms and frameworks.
A big thanks goes to those who made this sprint possible: first of course to all the participants who are focused, motivated and working hard to produce good results. Then of course to Mario and his excellent team of volunteers who make sure we’re fed, warm, safe and taken care of. There is a number of sponsors without which this sprint would not have been possible, those are the Raiffeisen bank, Swisscom and openSUSE who generously chipped in to get us all together for a focused meeting to improve our foundations. Thanks to you all! We are certainly justifying the energy, passion and resources made available to us by working very hard to produce good results!
Tonight I’ll board a sleeper train which will get me to Randa, Switzerland by tomorrow morning. I’m travelling to that small village in the Swiss Alps to participate in the Platform11 sprint.
What is this platform11 sprint about? (Randa’s trainstation only has 2 platforms, one towards Zermatt, one towards Visp. That’s probably not it.) The wiki page about the sprint makes it more clear, however:
To examine the current state and near future of the KDE Platform (kdelibs and kdebase-runtime), particularly as it relates to the growing usage of it in new contexts such as mobile or on Windows and MacOS and its traditional usage as a set of conveniences and consistency creators for KDE application development. The sprint will aim to create an actionable, multi-year roadmap for kdelibs and kdebase-runtime and will examine issues of modularity, topicality and the inherent dichotomy between the KDE Platform as an application development framework (similar to Qt) and as a stand-alone platform to target (similar to, e.g. Windows, MacOS, etc.)
To me, this sprint marks an interesting point in the lifecycle of KDE 4, as we are now rethinking the structure of our platform.
Platform or Frameworks?
Last week, we had an interesting discussion wether the development libraries KDE software bases upon are called a platform or frameworks. I personally prefer to think of it in terms of frameworks, because that has a less exclusive nature to it. A platform sounds very much monolithic, while frameworks give a modular impression — and indeed, one of the goals of the Platform 11 sprint is modularity of our "platform".
Plasma Active and Platform11
One of the goals for me for participating in Platform 11 is to make our development frameworks more suitable for building non-desktop systems. There have already been efforts that work into this direction for quite some time (the platform build-time profiles come to mind, or recent work on libplasma2), but we haven’t yet had a focused meeting where we sat together to discuss our platform as a whole. That will likely mean a bit of restructuring in our libraries, deprecating some overly old stuff, and examining where we’re lacking a consistent API for modern needs. Geolocation comes to mind here, and rumours are that there’s an exile-kiwi coming with plans to Randa.
Last night, during dinner Kim asked me what I’m looking forward to in Randa other than technical and community bits. My answer was “watching the mountains”. As I’m living in the Netherlands, mountains are not a normal thing in sight, and the magnitude of those Swiss Alps keeps astonishing me. I’m also looking forward to those idle moments staring at the mountains.
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
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
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.
As we’re working on issues central to how we all (KDE and Qt hackers) develop, I’m sure you’re impatiently waiting for results to pour onto the Internet. While our first focus is on personal interaction and using the facetime and “high personal bandwidth” to solve hard problems, you can get at least an overall impression of the direction of our work, as we’re tracking our results on the 
What is this platform11 sprint about? (Randa’s trainstation only has 2 platforms, one towards Zermatt, one towards Visp. That’s probably not it.) The wiki page about the sprint makes it more clear, however:
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.
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 