plasma active workshop wrapup

What can I say other than "that was a very, very fast four days in Darmstadt". I had expected to have the time and energy to blog more during the event, but that was obviously not to be. There were only three people working on the actual code there, but we managed to make over 60 commits over the course of the event, not counting backports and similar janitorial efforts. That isn't a huge rate of commits given the people who were there, however, though it is certainly respectable. So what else were we doing?

The first thing we did was review all open bugs for Plasma Active, turned our draft agenda into a kanban board on the wall and then torture tested the user interface on both MeeGo and OpenSUSE to identify issues that need addressing. We sorted and prioritized these items into the kanban and got to work on them. I will be spending some time today creating new bugs.kde.org reoprts for the items that remained on the wall at the end of the event. We focussed these efforts on the main part of the tablet shell: activities, recommendations, the running-applications peak area and the application launcher. We had an "other" category as well, and it become rather well populated, but we want to make sure that the core components work very well in our first release.

One outcome of this was that recommendations are getting too much work done on them this close to release to include the recommendations UI by default in Plasma Active One. The recommendations system will remain in place, so when the UI is revealed there will be things you can immediately use it with. However, we just didn't feel that we had enough time to ensure the quality of it when a major code drop happened just a couple weeks before release. The recommendations are, thanks to Ivan, working better than ever and proving more and more useful. They will be the key feature addition to the tablet UI in the next release, in fact.

This decision was one consequence of us clearly defining and examining the release engineering needed to get Plasma Active One out. We have a new release manager, Javier (who also works at Basyskom), who will be providing additional oversight on that process. Improvements made in the code are being reviewed so we know that they are really done (or not), tagging dates have been set (release tag on the 3rd of October) and packaging details were sorted out. We cut down the number of branches in git specific to Plasma Active to zero, allowing people to build Plasma Active using standard branches of KDE modules (KDE/4.7 of kdelibs, kde-runtime and kde-workspace; master for plasma-mobile and kactivities). This meant we had to adjust our packaging as well, which got done thanks to the tireless efforts of, among others, Maurice (aka "Pirate Moe": he does the best pirate "arrrrrr" I've heard in a long time).

We put together plans for a website that will support the release to be unveiled on release day, along with a messaging plan that includes writing, screenshotting, filming (video-ing?) and reaching out to the press. We also came up with a naming scheme that we will use for at least this and next year that is wonderful simple: Plasma Active One, Plasma Active Two, Plasma Active Three .. I'm sure you see the pattern. ;)

The first release is still scheduled for October 9, 2011 (9-10-11) and we will be doing our next release prior to Christmas so that people can have an early gift from the Plasma team and play with it during the December holidays that are traditional in many areas of the world.
It wasn't all about the technical side of Plasma Active either. We worked on plans for how to bring more effectivity and formality to our business ecosystem development around Plasma Active, for instance. We will be sharing more on that later in the year.

Finally, we also looked into the future and asked ourselves what we would like to work on in the coming year. A major take-away for me is that we don't want to concentrate too much effort on simply playing around with the base tablet shell. We like the design of it and it works very well in terms of driving an activity-centric experience. Once we've (re-)integrated recommendations and a couple other small UI bits (such as re-introducing the category tag cloud in the launcher), we'd like to shift our focus slightly to the workflows we want to see enabled. Since we had not one but two interaction designers at the workshop, they did some extensive story-boarding for a few target workflows. We also gathered requirements for applications we want to see fulfilled for use in Plasma Active and will be spending more time on meeting those goals in future.

Some of these tasks will improve the Plasma Desktop and Netbook experiences as well as they are not tied to or only applicable to tablets. Things like having an application-neutral mechanism for recording (and accessing) your online accounts, better workflows for transfering information to and from removable devices (or online services), sharing and synchronizing Activities (both between devices and people), no-config cross-device cooperation (assuming they all have Plasma on them), Share Like Connect plugins and more elegant application interfaces are efforts that will land on all of the Plasma workspaces in tandem .. but that's the future, and we're still in the "now" that includes making it across the finish line for Plasma Active One.

To that end, I have a bunch of bugs.kde.org forms to fill out, new images are being worked on, more testing is underway and a heck of a lot of documentation and public communications writing is going on. The #active and #plasma channels on irc.freenode.net are going to be busy, as will the active@ and plasma-devel@ kde.org mailing lists. See you there :)

Read More

plasma active workshop: day 0

The last couple of weeks have been ridiculously busy. Or, if you prefer (and I do): ridicubusy. On the personal side of life, I managed to squeeze in a two day paddle-and-camping trip the other weekend, played dinner host to Lawrence Krauss (made some of my favourite dishes, and one new one (for me, anyways): egg yolk ravioli), co-hosted a "Ready, Steady, Cook!" evening at the house along with S. All of that was enjoyable, and great breaks between the long hours of working on Plasma and general KDE "stuff".

A lot of what I've been working in the last two weeks has been involved writing source code, but working on community, technology roadmap and business issues. I've managed to get some good hacking hours in, too, but not as much as usual as I've been paying more than the usual attention to these other, also-important areas.

Some of what I've been working on will (if all goes well) get to the next step this week. A half dozen or so of us are congregating again in Darmstadt, Germany to collaborate on Plasma Active issues. We'll be focussing on getting to a high quality Plasma Active One, what we wish to do after that, our plans for libplasma2 and Frameworks 5, the next iteration of UI implementation concepts as we fully realize the Contour concepts, hardware related issues and the business case around it all. All in four days. I don't expect to get much sleep.

I'm the first to arrive at the Basyskom offices, who is sponsoring the workshop, so I'm about to start turning our draft agenda which Fania (Contour's UI designer) put together into a set of sticky notes for use in our kanban board. (This is the part of the blog entry where Kevin Ottens gets all happy and excited. ;)

With Sebastian, Marco, Martin, Fania, Eva, Stephan (Binner and) Werden), Thomas Pfeifer, Karlheinz and Javier all around, it's going to be an excellent few days and we'll keep the world updated via blog and microblog (and mailing list, and wiki, and... ;)

Ten is a good number of people, though I had half-hoped that with the public announcement on the plasma-active mailing list and having published it on sprints.kde.org there would have been one or two others wanting to join us. For those who find what we're doing in Plasma Active exciting, intriguing, interesting and something that wets their appettite: I'd be very interested in hearing from you what would make for an exciting, engaging Plasma Active themed event that you would Not Want To Miss(tm), and what would enable you to move from spectating excitedly to participating fervently.

Read More

easy building with git split modules

Since the beginning of the git migration there was one issue that suffered for lack of resolution due to competing needs: to split or not to split the repositories? On the plus side of splitting the repositories, we get smaller repositories that are more focused on individual projects making it easier to fetch and work on just what you want. On the plus side of keeping the repositories more "monolithic" is ease of following development since you don't have to `git pull` and build a bajillion tiny repos in the right order and as new projects arise they magically appear in the repositories for you. The monolithic repositories is also how we've done things in the past and so keeping some continuity, at least for a transitional period, would have been great.

For better or worse, more and more repositories were split up. To my personal frustration, not much attention was paid to these issues by those working hard on creating all those small repositories. They would say they were already too busy with what they had to do, let someone else address the problems that were being created ... and I ended up simply not following the development of many of these repositories anymore as it was too much work to do so.

I refused to give up hope, however, and kept pushing at this issue. Until we had a solution, I was not going to close my eyes to the problems. See, I'm one of those silly, silly people who want to have their cake and eat it to. Or at least be able to watch someone else eat it. Cake that nobody eats just seems like a waste, doesn't it? And I'm a bit of a food voyeur: I enjoy watching people tuck into something really tasty to see their reactions and hear their opinions. *cough* Ok, maybe I got carried away on that analogy, but you get the point: I wanted pink fluffy unicorns dancing on rainbows.

Fortunately for all of us, there are people working on solutions to this precise set of challenges. The solutions have gotten much better in recent times and I figure that since I did a lot of pushing and prodding for us to pay attention to the issues, now that we have solutions coming of age that it is only honorable and right that I should help recognize those solutions and spread the word about them.

Eventaully, I'd like to see KDE eventually adopt one solution as The Recommended Way To Build Stuff. This would mean reworking the content on Techbase and whatnot. That's work for the future ... let's see where we are today!

The solution that most catches my eyes and heart right now is kdesrc-build. It's been around for a long while now with many, many users ... but with the git migration and some of kdesrc-build's new features that lets it integrate with projects.kde.org, it has earned one more: me. It has allowed me to once again follow all of KDE development on my system without spending too much of my time tending to git and make.

The key features of kdesrc-build for me are:

• It is simple to use: there is rather good documentation and it ships with a sample config file


• It integrates with projects.kde.org to get entire "modules" of git repositories, such as "kdeutils" which is actually a dozen or so individual modules, without you having to do anything special .. just like the old monolithic repos!


• It automates the entire process into a single command; when I wish to update kdeutils, I type: kdesrc-build kdeutils. That's it. Of course, I could have it run through everything it knows about by just typing kdesrc-build

There is currently a first-run install-and-setup helper being created and development in general continues, so this is not only useful now but growing more useful all the time.

For me, setting it up was pretty easy: copy the sample rc file to ~/.kdesrc-buildrc and then change a handful of options. In particular, I changed kdedir (I install outside the normal system path so I don't disturb the OS-provided packages), qtdir (ditto), git-repository-base (a matter of just uncommenting the correct line for someone with a commit account) and make-install-prefix (I use sudo) and build-dir. The defaults are pretty much perfect for someone just following development and installing into their home directory for testing, which is probably the right thing to optimize for.

So, if like me, you want those fluffy dancing unicorns ... I very much recommend grabbing kdesrc-build and using it. It eliminates the pain points of the split repositories in a jiffy.

Huge, huge thanks to Michale Pyne for putting so much effort into this tool.

Small but important update: Tom Albers noted in his blog today that we have Eike Hein and Ben Cooksley to thank for the projects.kde.org side of the magic that kdesrc-build uses. Cheers to those guys as well! :)

Read More

the on-screen keyboard

We have an on-screen (or, if you prefer, virtual or software) keyboard for Plasma. It can run independently of the shell by way of the plasma-keyboardcontainer application (which we use in Plasma Active) or the Keyboard Plasmoid that comes as part of the kdeplasma-addons repository.



We've been working on may improvements to both the code and the user interface in the last few months. These include improving how it works with a hardware keyboard, being able to move it around the screen on a device, better performance, features like caps- and num-lock (by double-tapping the respective buttons).



There is much more we'd like to do with it, however. If you go to Plasma Active's open tasks page you can find a number of tasks open for the keyboard. This includes things like adding arrow keys to it (these are already supported in the code, we just need to enable them, in a nice way, in the tablet layout), adding locale support so people can easily get to their ü's and ç's, providing copy and paste functionality and more.



These are all bite-sized projects and the code is easily accessible in the Plasma Addons repository under applets/plasmaboard. The stand-alone shell is in the Plasma Mobile repository in the virtualkeyboard directory.



If you're looking for an easy way to get involved with Plasma development that will help Desktop, Netbook and Active simultaneously, look no further. This is a really nice little project to get started with, and we're happy to help you get your legs in the code. :)

Read More

more on Active strategy

We get a lot of questions about Plasma Active, and I'd like to address a few of the more common once in this entry.

Openness

We do all of our design and development in the open. We have the plasma-mobile repository that holds things specific to the Active shell. The rest of our code can be found in the kdelibs, kde-runtime, kde-workspace and kdeplasma-addons repositories.



Design is done collaboratively on the active at kde.org mailing list, #active on IRC and occassional VOIP/video calls. The core team gets together in person every few months as well to sync up, and we hope to grow those over time.



We're very open to people taking our work and making something different with it as well. git and our general open door policy makes this very easy. In fact, we hope that over time people making various sorts of devices, from tablets to set top boxes to phones to netbooks, will do just that. Differentiation with compatibility due to a common framework.



We're also very open to 3rd party applications and are hungry to see to more touch-friendly F/OSS applications join us in building up a truly open device ecosystem. Your applications can help define what tomorrows devices are capable of.

QtQuick / QML

While the bulk of our interface work in Plasma Activfe is being done with QtQuick technologies such as QML, this is not a requirement for 3rd party stand-alone applications. We recommend QML, but it's not a requirement. We feel it is unrealistic to expect many applications to suddenly jump into the QML world today. Many can be made touch-friendly and device ready with fairly minimal changes to the existing code base. Still .. QML is pretty impressive stuff, and you may want to check it out! :)

Plasma Desktop / Netbook

What we learn about using QML in Plasma Active will eventually impact future releases of Plasma Desktop. We're already using components in both directions (from Active to Desktop and vice versa), and this is something we want to expand and continue.



However, we do not believe in the "one interface that runs on both your desktop and your tablet". We believe in code reuse, in component-reuse (and, where beneficial, drop-in-replacement), compatibility and interoperability; but we also believe that a tablet interface and a desktop interface are not, and should not, be the same thing. The use cases and form factors are just too different.



We have no plans of bastardizing Plasma Desktop into a watered-down attempt at a tablet interface that also sort-of-makes-sense on a laptop. We feel this only produces interfaces that perform OK but not great on either kind of device. We want interfaces that work great on each sort of device. This is why we designed Plasma to be so flexible: we can afford to have different interfaces, and trivially keep them compatible with each other, without pouring gigantic amounts of resources on it.



So those who are concerned that we're going to do something nasty to the desktop interface: breath easy. We will continue to improve and work on new ideas on the desktop, as we did with Folder View and Activities, but we're also respectful of how people (including us) use our laptops and desktops.

Read More

Plasma Active entering beta

At the beginning of this year, the Plasma team was itching to extend Plasma's coverage of the device spectrum. We already had Desktop and Netbook interfaces, and while maintaining and incrementally improving those, we wanted to show case the possibilities of Plasma by creating a full fledged touch interface for devices.



After being shown the concept of Activities, Eva, founder of Basyskom (who is now a major supporter and investor in our efforts), had an epiphany as how they could be applied to a touch based device like a tablet. She christened the concept "Contour". OpenSLX was looking for a new halmark feature to help expand its appeal and so we found a home for packaging efforts and OS.



We also wanted to start working with the newest QtQuick technologies without disturbing the Desktop or Netbook interfaces with our experimentation. It all came together at the right time and Plasma Active was born.



Our goal was to create an innovative object of desire, one which people will want and, once they have it, build a personal connection with over time and through usage. We also knew it has to be 100% open, from planning through to development, and we gave ourselves just six months to come up with the first version of it.



After months of effort, Plasma Active has gone "beta". We're currently a little more than a month away from the first release, and so starting this month we are focusing on polish, integration and fixing defects. So how does it look? Judge for yourself from this quickly-made five-minute video of Plasma Active on an ExoPC device running packages that are just a few days behind our upstream development:

Even though we haven't even reached our first release, it's already quite usable. Many people have been installing and enjoying Plasma Active since, as one can see in any number of blog postingss recently, such as John Layt's and Sune Vuorela's from today. I've also been seeing more and more tweets and dents about it, and the IRC channel (#active on irc.freenode.net) is getting fuller by the day.



We've been able to make these strides because we did not start from scratch. We started with the Plasma framework that builds upon Qt's and KDE's libraries. The component-based approach has allowed us to re-use components and rework what was needed, allowing us to expend a minimal amount of effort to achieve an interface that is radically different from what we deliver on the Desktop and Netbook. They are completely compatible, however: what I run on my Plasma Desktop, I can run on the tablet. Activities also are compatible and can be used across the different Plasma shells. I was doing this just the other day during development while running Plasma Active in a window and switching between activities: it showed the activities I'd created using Plasma Desktop and when it switched the activity, so did Plasma Desktop!



Plasma embraces diversity, and this is how we have been able to create something that looks so different from the Desktop and Netbook interfaces without having to go through a painful and expensive "write everything from scratch". What we have written has also at times benefited Desktop and Netbook comonents, and many of the components in Plasma's tablet UI are actually straight from those more traditional interfaces. What we did write custom has mostly been done using the highly time efficient QtQuick framework.



Above all else, this shows how Plasma interfaces can be reshaped into nearly any sort of form one would want without suffering rewrites or incompatibilities. What we have now is a Deskotp, a Netbook and a Tablet interface which are all 100% compatible with each other and share the overwhelming majority of their code with each other.



Development continues at a fast pace as we head towards Plasma Active One in September. Today, unified browser history and plugin support(yes, that means flash) was added to the WebKit based browser and numerous bugfixes made their way in as well. Those following development are greeted with a slightly better experience every day when they update.



How can you get on board? You can run it on a normal laptop PC, of course, but you don't get the full experience. So we recommend snagging yourself an ExoPC device (WeTabs can be found rather innexpensively online in Europe, for instance) and following the instructions on the wiki here. The Balsam live image was just updated yesterday and new packages come streaming in through OBS for openSUSE installations quite literally every day. We also have MeeGo packages which are not quite as advanced as the Balsam / openSUSE ones, though we're working on that, too.



You can also contribute with testing, documentation and code. There are many tasks still open, many applications that could use some love and we're also looking for things like a high-quality introduction video that you can play on first-start that shows you the basics of the interface.



Beyond the shell itself, many of the KDE applications such as Calligra, Kontact and Marble are being "Activated" with touch-friendly UIs and you can use all the apps that are in the normal repositories as well. We're hoping to see even more applications get improved interfaces for touch and, in fact, I believe this to be one of the biggest opportunities for contributors to get involved. The KDE games, for instance, are 99% of the way there: they work beautiful with touch ... if only they'd lose the menubars (and in some cases the toolbars too). Okular makes a rather good eReader already, but it too needs adjustments to the chrom. These little bits of work would help catipult these apps from desktop-only to be desktop, netbook and tablet champions.



I'm excited for October and our first release. We've been showing the tablet at various conferences (and BBQs, pubs, cafes, offices and other such places ;) and the response is universally positive and, more importantly, curious and inquisitive: people want it when they see it. One of the responses we get at conferences all too often is, "Where can I get one of those?" Well ... we're working on that, too. :)

Read More

tracking what happens in your DataEngine

Whether you are writing or using a DataEngine it can often be very nice to see what the heck is going on in there. Today I had the need for doing just this while making some improvements to the Contour activity switcher in Plasma Active. So I whipped up a rather small but very useful (as it turned out) class called DataEngineTracker. You simply hand it a DataEngine and an option QObject parent and it will print out every source that comes, goes or gets updated.



For lack of a better place, I plopped it into the kdeexamples repository so that others (and the future me ;) can easily include it into their project (DataEngine, Plasmoid, application, ..) and see what a given DataEngine is doing. It's BSD licensed, so it can be used pretty much anywhere.



In today's case with Plasma Active, it showed up an unintentional update was happening on the activity thumbnails for the switcher every second. If you had a lot of activities, this added up quite a bit. We've also killed some other performance issues and the polish is really coming together in general now in all those little ways that one probably won't even notice in the final release .. but certainly would if they weren't there. ;)



On a side note, kdeexamples now contains over 7,000 lines of code. Sweet.

Read More