Plasma Active: Calligra Active

(Note: This post is about Plasma Active, a community collaboration to bring KDE software to consumer devices. To learn more about Plasma Active, read this blog post.)

Today, Plasma Active is proud to announce our first Active App, or rather our first Active App suite. While interacting with what are generally referred to as "office documents" isn't what we may think of as "sexy" it's a very important set of functionality.

For Plasma Active, we've joined forces with Calligra which is a suite of office applications which uses the KDE Platform and has an active mobile and consumer electronics effort.

Calligra Active is currently in alpha, but this refers primarily to the touch interface. The file format compatibility with Open Document Format and Microsoft's Office Open XML is some of the best to be found in a mobile form factor. The Calligra team is currently working on a transition of the interface to QtQuick, but Plasma Active is already including the current mobile-targeted interface in the operating system images.

As you can see in the video above, there is already quite a bit of functionality, the performance is quite good and the rendering fidelity is solid. There is much work to be done between now and our fabled "9.10.11" date later this year in October, but the team is hard at work as can be seen at the recent Calligra development sprint which was attended by over 30 developers.

The focus on consumer electronic devices, quality software and a can-do community-driven spirit married with entrepreneurial efforts makes Calligra a perfect fit with the Plasma Active initiative and the entire Plasma Active team is excited to have them join us.

While speaking earlier this week with Inge Wallin, Marketing director at KO GmbH, about Calligra and Plasma active he noted that "[as] the main commercial vendor behind Calligra, we are happy to see Calligra developing so quickly. We have seen the business around the Calligra suite expand a lot in the mobile space during the last year, and the reason for that is its unique properties: flexibility, being light on resources and a very clean code base. Our goal is to make Calligra the default choice when it comes to free office applications in the mobile space. Engaging with Plasma Active is one more step towards realizing that goal."

If you would like to track Calligra development, install Plasma Active and track its development as we include new development snapshots every two weeks.

What will be our next Active App? Find out in two weeks time! Early next week we'll have updates on Contour and a recap of this past week's Plasma Tokamak 5 developer sprint and what this means for Plasma Active (spoiler: a lot of polish and new features).

To participate, join us on irc.freenode.net in #active, on the active and/or Plasma mailing lists and put Plasma Active on a touch-friendly device.

Read More

a typical day at Tokamak 5

We just finished our daily progress meeting here at Tokamak 5 where we take turns moving our (self-)assigned sticky notes on the kanban window into the "Done" category. We each share what we've done the previous day, what we're working on now and what (if any) blockers we've encountered.

It's fairly amazing what gets done given that we're only a dozen people. I was live blogging on identi.ca the things that were done yesterday during the meeting and here's the list that resulted:

• New release management system and a git workflow we're going to try over the next three months in Plasma has been agreed upon and documentation has begun for it. This was the result of a couple of hours of presentations and discussions and many more hours of work prior to and after that session. The goal is keep a low barrier to entry given we're using git but to also use a more manageable set of processes.


• KConfigXt meets QML! This paves the way towards pure QML config dialogs while keeping the crunchy XML goodness of configuration data described by KConfigXt.


• Bookmarks can now be easily stored in and retrieved from Nepomuk, allowing them to be easily shared between applications (not to mention more metadata) and presented in more useful ways. There's a GSoC to integrate this work in rekonq which is a nice coincidence. :)


• The existing Nepomuk DataEngine has been turned into a base implementation with task-specific DataEngines, including a bookmarks one, built on top. This is pretty easy as the task-specific ones essentially define the Nepomuk query and little else.


• Some new activity templates: desktop icons and search and launch. Now when people ask for a traditional desktop icon style, we can just point them at the activity manager (which is now easy to see thanks to the new activities button in the panel which appeared yesterday). The photos template was also vastly improved.


• Activity templates can associate and start apps now as well.


• Activities in the activity manager can now be associated with a template instead of actually be created. This allows creation-on-demand of such activities (so they will match, e.g., screen resolution and app availability better) as well as preventing them using any resources at all unless launched.


• The calendar as seen in the clock Plasmoids now has a two-pane design with events in the right hand pane. This was inspired by the approach in GNOME shell, which we thought was pretty nice. :)


• The mobile and tablet widget explorer was improved for usability and readability


• The mouse cursor no longer is visible when used Plasma Active is used on a touch device, as one would hope and expect.


• KWin now tracks and (more importantly) exposes recently used window ordering which will be used in visualizations in the various Plasma shells.


• Plasma Active panel interaction was partly implemented so we can have a nicer workflow for application switching, launching, etc on such devices.


• Different panel geometries depending on screen size


• A panel per screen on multi-screen setups


• Default wallpaper string no longer appears in libplasma, is now 100% controlled by the metadata.desktop file in the theme (and/or the theme fallback), preventing the need to patch libplasma by downstreams

Today's work is already well underway. There is no stopping this locomotive. We are fueled by great food (yesterday pizza, today a green curry feast), great drink (teas, coffees, juices, beers) and passion. Lots and lots of passion. :)

Read More

Tokamak 5, Day 2

Yesterday, in defiance of the weather reports, the day was sunny and reasonably warm and set the stage for a very productive day 2 here at Tokamak in the Netherlands. We held four design sessions in the morning: 2 on libplasma2 (specifically the dual topics of isolating QGraphicsView from the core code and using Qt Components), one on plasma-desktop defaults (a button to show the activities, an auto-hiding pager when virtual desktops drop to one, some default launchers that track the default file manager and web browser, and much more) and one on a new first-boot screen designed with OEM style installs in mind.

Several dozen individual tasks were placed on our large kanban window before we were done and then we spent the afternoon working on implementations. Today we have a nice neat pile of sticky notes in a variety of colors in the "Done" column, and a few more in the In Progress from the night before.

Today, after everyone's finished with breakfast and we have a short status update, we will take on another set of topics into the design meetings and start the process of creating and migrating tasks anew. I expect the topics to include the tablet shell design, another libplasma2 topic and KActivityManager (which just moved into kdelibs/experimental!) and SLC.

Unfortunately the weather is not nearly as nice today for us: it is already heavily cloudy and there is a slight chill in the air. We also won't have the grace of Adriaan's pancake cooking mastery to fill our bellies this evening, so we'll have to improvise something new.

Read More

tokamak 5 begins

Yesterday was the first day of Tokamak 5. What's this "Tokamak" I speak of? It is what we call the Plasma development sprints that we hold approximately twice a year. We gather anywhere from 10 to 25 people involved in various aspects of Plasma development together in one place for a week to work on the pressing issues of the day. They let us knit our core community together more closely, find paths for the bigger challenges we face and get a fearsome amount of work done.

This Tokamak is being held in Nijmegen in the Netherlands. Sebastian Kugler is our host and the weather has been fantastic thus far. On our first day, people took turn giving presentations about things like QML, Plasma Active, libplasma2, Share/Like/Connect, syncing and more. We set up a kanban board in white grease pencil on the large front windows of the apartment to organize and track our progress over the rest of the week. We finished the first day with a celebratory BBQ in the back yard .. followed by more presentations. :)

We have people from Plasma, KWin, Solid and various other KDE libs bits here, giving us a nice set of skills and interests to put into play. It's a smaller Tokamak this time compared with the last one which had 25-30 people in attendance, and this is intentional. We wish to focus on a very specific set of tasks surrounding libplasma2 and Plasma Active.

I don't expect to get a whole lot of sleep over the next week, but on the upside we should get a hell of a lot of work done, and we'll keep you all updated as it happens via our blogs and the #tokamak hashtag on identi.ca.

Read More

undertow

I've had the opportunity to swim and play in some reasonably big surf. In doing so, I quickly learned about undertows and rip currents, two products of wave action that create strong flows of water along and away from the shoreline. When the waves get bigger, the power of these phenomenon also increases.

When riding waves, at some point you'll inevitably fall in and get pulled into the roiling chaos (which has a beautiful quietness to it); if you're in the right place at the right time, you may end up at the mercy of the currents produced by the waves tossing tons of water forward that now wants to go back out. Often the only thing you can do is hold your breath and let it take you for a bit of a ride, as the power in those currents is far more than you can generate by swimming. Eventually you'll pop up somewhere and then you can start making your way back in.

A few of us have been working on creating a (hopefully big) set of waves, which we announced last week as "Plasma Active". The announcement was really just the first set of waves arriving at the beach: perfect for surfing and picking up all kinds of speed. However, I've been sort of caught in the resulting rip current since Friday. :) All the forward momentum has created a ton of activity for us and right now I'm in "holding my breath and going with the flow" mode. ;)

I was hoping to write a summary piece today covering some of the high level strategic aspirations of Plasma Active, such as providing a visible rally point for people working on device-oriented projects within KDE and how we want to fill some of the gaps that remain for us in the MeeGo ecosystem. However, it is already 17:00 and I still have hours of work ahead of me. That blog entry will have to wait.

I will, however, quickly note that:

• We will be announcing the first Active App next week, the first of many!


• Contour continues to develop, and the OS image track is similarly moving; so these will follow on nicely after the Active App announcement.


• Plasmate has seen renewed development and is polishing up nicely. We have a new contributor who has popped up recently, and both Sebastian K. and myself have been plonking away on it. I need to do a screencast soon! :)

So progress continues, the reason you can't hear more from about it right now is that I'm quite firmly beneath the water. ;)

Read More

Plasma Active: Vendor Interaction

Foreword

This is the final entry in a series of five posts covering the various tracks in the Plasma Active initiative. In this closing article, we look at the track that aims to help bring out work to actual hardware.

On Monday, I will be writing a quick overview of some of the "big picture" goals and aspirations represented in Plasma Active, and on Friday of next week I will be sharing a preview of a new interaction feature that I've only referred to cryptically as "SLC" so far. Today, however, I hope you enjoy the outline of the fifth track in Plasma Active: Vendor Interaction.

The Big Challenge

There is an old, and odd, question: "If a tree falls in the forest and nobody is there to hear it, does it make a sound?" We could perhaps rephrase this for software: "If we write a program and no one uses it, does it matter that it was ever made?" There's obvious personal pleasure in the creative process itself, but if those of us working on Plasma Active are being honest with ourselves, we are making software to be used. To make our efforts mean as much as possible, we need to get it into people's hands.

We can distribute it over the Internet and hope people will download and install it on devices they have bought from the store, replacing what was already on those devices. Some will do just that; in fact, some have already started doing so with Plasma Active! However, the number of people who will do this is really quite small. It's an amazingly valuable group of users and contributors, but we'd like to see this thing go a lot further than the True Believers.

The best answer is to get it on devices that sell into the retail market and which, hopefully, do well in doing so. As with did with the operating system layer in years past, we could sit back and hope someone will come along. Historically, a few have. Remember the first EEE PCs? It's very hit-and-miss, however, and not sustainable. At least, that's what experience has taught us.

So we need to help things along.

Building A Fulfilling Business Community

Alongside the technology tracks, we are keen to create an entrepreneurial support, collaboration and partnership zone for those involved with Plasma Active. There are two primary motivations for this.

The first one is probably obvious: without a variety of support services and products available, the odds that a company that is creating a consumer device will choose Plasma Active plummets.
We can offer a certain amount of comfort by using well known technologies like the Linux kernel as well as by being compatible with software stacks with other backers, such as MeeGo. There remain a lot of gaps to fill, however, and we intend to fill them.

Being able to contract to experts in the technology, retain tech support services, engage with open marketplaces and know the legal standing of the technology being offered makes it easier for a vendor to adopt a software stack. If a consumer device vendor wishes to "go it on their own", that's great, but we realize that such companies will be few and far between. For the rest, we want to help support your efforts.

The second reason for purposefully crafting a business community stems from a desire to have a personally rewarding and ultimately enjoyable working environment. "It's just business" isn't good enough, and we want to build a business community alongside Plasma Active that is as open, innovative and intriguing as the technology itself.

We have big goals to fulfill and maybe even enough resources to meet them if we successfully grow the number of participants in Plasma Active. While there's always an element of luck and good timing to these things, planning is a huge part of determining success as is the atmosphere within those processes happen.

Those of us involved with Plasma Active wish to work within a positive, optimistic, energetic environment where ingenuity and problem solving are as natural as breathing. We feel that if we create such a positive space (and we can!), we'll not only enjoy it more but we'll also achieve more. We want to be able to share that positivity and sense of adventure with future partners as well. Using Plasma Active for your device or contributing a great piece of technology to it should an exciting and even inspiring experience, as all great journeys end up being.

As more companies become active within Plasma Active, we want their existence to be beneficial to the entire community, including those participating with non-monetary incentives, open source style.

In short, we want the business interests to not only amplify the efforts of each other but to create a space where we all wake up in each morning eager to dive in yet deeper and push yet further.

The Plan

For the vendor track of Plasma Active, we will be announcing various services and products that support Plasma Active in the market. These announcements will be backed by companies that are involved, either today or in the future, with Plasma Active. This track has the fewest milestones of all the other tracks and that reflects both the time and effort it takes to put these things together. Software code can be written slightly quicker.

We will then endeavor to make potential Plasma Active hardware partners aware of what we have to offer, both technologically as well as in terms of business services. We will be looking not only at the "big boys" who sell millions of units per year, but will also be engaging with smaller vendors with the hope of helping them realize innovative and competitive products. There's a big market out there, and we see a lot of opportunity.

The announcements of services, products and outreach efforts will not be tied to a fixed schedule like the rest of the tracks. The vendor interactions track will follow a more punctuated
equilibrium due to the nature of the game.

As a side note, one reason it was decided to make this a separate but clearly stated track was that we wanted to be up-front about people having intentions to be entrepreneurial with Plasma Active, but we also recognize the need for those aspirations to be a parallel thread to the technology itself. The Plasma Active product must be something great technologically, visually, etc. regardless of the business interests. The Plasma Active community must be a level and equal playing ground for everyone involved, whether they have a monetary motive, a non-monetary motive or a mix of both. It's a fine balance, but while business can play an important role it must be done in deference to the community and the technology. We felt having a clearly stated separate track for these endeavors would communicate that clearest.

How You Can Get Involved

First and foremost, we want participants that focus on Plasma Active as a product and a community. For those who are participating who have relevant business associations or wish to scratch their entrepreneurial itch, we'd love to talk with you about how we can make that happen.

I can't stress enough how important it is to us to populate the business community around Plasma Active with positive, forward thinking people who value openness (while respecting confidentiality when needed) and who believe foremost in fair dealings.

If those two paragraphs describe you, in the words of Barry White, "let's get it on". Ok, maybe not in the way Barry meant it ... but we can always add more milestones. There is still lots of room at the Plasma Active partners table.

Read More

Plasma Active: Operating Systems

Foreword

This is the fourth in a series of five daily blog entries covering the various tracks in the Plasma Active initiative. Today we'll be looking at how we plan to distribute the fruits of our labor for use on devices. As we will discover, this is rather new ground for a KDE initiative. It will bring many challenges, but also open new opportunities.

A Missing Link

KDE produces a large quantity of software which traditionally have been aimed at use on laptops, desktops and workstations. Getting our software out to users was fairly straightforward: we released bundles of source code every so often, operating system projects and vendors came along and turned those into binary packages and make them available to their users. KDE has been a wonderful toolkit from which people putting together operating systems can assemble the desktop shell that suits their target audience.

A few years back people started looking to new fields of opportunity: Windows, MacOS and mobile. We don't have participation from the vendors behind either Windows or MacOS so KDE people have had to integrate, build and distribute binaries themselves. This has had mixed results, and really highlights the challenges a community like ours must climb over when the OS vendor is missing from the picture.

Mobile has been another kind of story. At first, we essentially waited on OS groups to do as they did with the desktop: pick up KDE software themselves. This "build it and they will come" approach gave sporadic successes, but it became evident this wasn't going to deliver the results we wanted.

We experimented with pro-actively engaging with operating system vendors. It was difficult to get some vendors to even look up from their own navel long enough to consider the benefits of an active partnership. When we did manage to clear that hurdle the results tended to fall on hard times quickly. (The netbook image, for instance, simply stopped building and there was essentially nothing we ended up being able to do about it.)

We also worked directly with operating systems with a clear mobile focus, including the companies behind MeeGo. The process and politics were often a difficult match for the distributed, agile, community-centric nature of KDE. Where we did find promising footholds, we were still firmly at the mercy of the decision making of others.

It became evident that it was time to be better masters of our own destinies and simply do it the KDE way: community and engineering efforts. With the operating systems track, Plasma Active aims to build an active, direct path to getting our software on an operating system that can be used on consumer devices.

The Wheel That Exists

The last thing we wanted to do was to reinvent wheels and delude ourselves into thinking we could become a full operating system provider ourselves. That wheel has already been invented many times over, particularly in the Linux world. We want to create a diverse ecosystem that retains choice while bringing us a moderate level of predictability to the results. We need to have a clear and powerful voice in how the technology we work so hard on gets put together, and we're going to "stand on the shoulders of giants" to get there.

We have started by working with OpenSLX who produces a (physical) box release of OpenSuse. They have experience in rolling out operating systems to consumers, including providing access to telephone support and creating first-class documentation. Just in time for the Plasma Active wheels to start turning, OpenSLX has rolled out a new product, Balsam Professional, and packages for Plasma Active will be delivered on top of it.

With the packaging and build services provided by OpenSLX, we can provide live, installable disk images for users and developers to download, put on a USB stick and boot on their device from.

By using an existing operating system stack we will avoid taking on that whole set of tasks ourselves. By becoming directly involved, we will be able to ensure it goes in the direction we need it to progress in.

Embracing Existing Initiatives

While this may sound grand, we are also realistic and humble: in a world of robots and 2-D block people, we don't believe there is need or room for more entries to the Linux-for-devices party. We'd also like to take advantage of investments, communities and momentum that is already there.

To that end, we intend to be MeeGo compliant. While the user interface and application selection will be very much driven by Plasma Active, we wish to keep the OS familiar to those working with MeeGo now and compatible with their software.

We currently do not have plans for Android, but that's only because we don't have people yet in the Plasma Active community to work on that. We'd be very happy to see an Android based release as well, so if you are interested in making that happen, please join us and let's get that happening.

MeeGo gives us a great starting point, however: it's the most friendly stack technology-wise for our needs, our friends at Qt and several other groups within the KDE ecosystem are already involved with it and it is openly developed. These are all strong arguments in MeeGo's favor for our needs.

What About Other Operating System Choices?

This does not in any way impact how we approach the traditional desktop or netbook form factors. We are quite happy with how our existing relationships and partnerships work there, and the desktop is not the focus of Plasma Active.

That said, just as we hope that Active Apps will bring increased continuity to the world KDE applications aiming for use on devices, we hope that having a role model operating system that showcases how Plasma Active can be delivered on a device will inspire other operating system projects.

The Plan

Every two weeks, an updated image for download and use will be posted for your enjoyment and use. The frequency of releases should help explain all the dots on the OS Platforms track image at the beginning of this entry. The basic idea is that in each two week cycle a Contour milestone pre-release will be tagged, Plasma Quick will progress and a new Active App (or set of them) will be announced. A few days later, a new OS image will be made available containing all the new hotness.

These bi-weekly images will be pre-releases that bridge the chasm between "the software is out there somewhere" and "it is now running on my device". As such, the target audiences for these builds are:

1. early adopter users wanting to watch it unfold and help us with testing and feedback


2. developers looking for an easy path to getting Plasma Active on their device

Initially, the images will be for Intel architecture devices and we will be actively testing on the following devices:

1. ViewSonic Viewpad 10
2. WeTab
3. Lenovo Ideapad 10

We have plans to broaden the catalog of devices over the next six months and will be announcing those additions as they come on-line. As the list of recommended devices grows and changes, we will be keeping track of them on the Plasma Active Devices wiki page.

We have a target date in September 2011 to make a first release of the full stack. This will trail the release of KDE Platform and Plasma Workspaces 4.7 by a few weeks, giving us a stable but fresh foundation to launch with.

By bringing together the strands of Plasma Quick, Contour and the catalog of Active Apps together on top of Balsam, we begin to close the loop between developers, users and devices. Ultimately, we wish to provide something to both show to and offer vendors who wish to build exciting, modern devices around. That's a topic for tomorrow's blog entry, however.

How To Get Involved

There are a lot of tasks that remain open here, even with the concerted efforts of the OpenSLX team already being applied. There are packaging tasks, configuration validation (oh, multitouch, thou art a heartless mistress!), hardware support issues to identify and find solutions for, testing to be done, etc. There is a serious amount of work here and we hope to grow this aspect of the Plasma Active community over the next six months.

To follow our progress across Plasma Active, get one of the recommended devices (or if you're more adventurous, something else) and follow the installation instructions.

Be sure to grab new releases as they roll out and give us feedback! You can find us on irc in #active on irc.freenode.net and on the Active mailing list.

If you'd wish to get involved with Plasma Active by packaging software, bringing Plasma Active to new devices or platforms, testing, etc. raise your voice and we'll find a home for your efforts in Plasma Active. We will continue to keep track of open tasks on the wiki in case you are looking for further inspiration.

Read More

Plasma Active: Active Apps

Foreword

This is the third in a series of five daily blog entries covering the various tracks in the Plasma Active initiative. Today we'll be looking at a concept we call "Active Apps". Where Plasma Quick is mostly (though not entirely) about infrastructure and Contour is a project with a Plan(tm), Active Apps is where we are really looking to the broader community of developers, designers and dreamers to help Plasma Active achieve its full potential.

Go Go Gadget Active Apps!

Having an operating system that boots into a shell which provides a basic interface to the system is a good start, but it isn't enough to provide a full, exciting experience.

People want all sorts of functionality on their devices, ranging from getting directions from a map to reading eBooks to playing games to .. and on and on. Whether it's a tablet, a set top box, a laptop, a phone .. it doesn't matter these days: we expect similar (if scaled) access to functionality across the device spectrum. Plasma Active needs to meet these needs.

That's a tall order for the relatively small group people already working very busily on the other tracks of Plasma Active. Fortunately, we're just the tip of the iceberg that we call the KDE community.

If we look through the catalog of KDE software titles, we find mapping software, and office suite, messaging apps, document viewers, games .. and on and on. Many of these projects are working on touch friendly versions for use on devices such as tablets and phones, but there is isn't much in the way of coordination between the projects or a clear path to accessing the results in an installable operating system image in a timely fashion. Other projects are wanting to add more device form factors to their targets, but aren't sure how to proceed exactly. Still others may be simply waiting for an open ecosystem to emerge to start working on that application they've been dreaming about for months or years now.

The Active Apps program will provide a collaboration and support zone for all of those working towards the common goal of making an amazing device experience. Combined with practical testing and deployment infrastructure, we hope to provide fertile soil for existing and new mobile-focused projects.

Of course, in a perfect world we'd be able put all the existing KDE/Qt software on top of Plasma Active right now, walk away with a smile on our face and call it a great day for consumer devices. This isn't a perfect world, and there are things that prevent us from doing that.

Giving Definition to "Active App"

We can divide KDE apps into one of three general categories:

0. Touch friendly, stable apps with a device-appropriate resource footprint


1. Apps that work Ok with touch, but have some remaining issues such as relying on menubars or dialogs with lots of little widgets


2. Apps that are essentially unusable on the devices Plasma Active targets due to a mix of resource requirements, touch friendliness, completeness, etc.

We are looking for applications in the first category for inclusion in Plasma Active. A definition for what makes an app "Active" was started to allow us to identify candidate applications and give developers working on them something to aim for. In general, Active Apps should be touch friendly, power friendly, perform well, stable, designed in a way to cover as wide an arc of the device spectrum as possible and integrate well with the overall platform.

The Active App definition is, however, in a very early state right now. It needs to mature into something we can all use as a clear guide to creating Active Apps. Reaching a "first release" of the definition is therefore the final goal of this track.

To accomplish that, we need the input and involvement from as many people working on Qt and/or KDE based software who are targeting consumer devices. That participation will help turn the definition into something clear, consistent, robust and reflective of the real world. As such, the definition will remain an open, living document for the duration of the Active Apps track.

The Path We Build Together

If you look at the diagram of the Active Apps track at the start of this entry, you'll notice that there are a lot of milestones on the route. Each "stop" on the route represents an announcement of a new Active App inclusion. That will make at least one new Active App every two weeks.

Contour is our first "Active App", and we are also talking with the Marble, Caligra, Kontact and Rekonq teams (and probably others by the time you read this :). We still have plenty of functionality gaps to address and a lot of stops on the track left open, however.

So if you are working on an application that you'd like to see on consumer devices (tablets, set top boxes, etc.) that fits or will fit the Active App goals, we would like to start working with you and your project for inclusion as an Active App. This is perhaps one of the easiest and most effective ways for software developers with existing projects to make an impact on Plasma Active and its directions.

Approximately one week after each new Active App announcement happens, a new installable image (something I'll be talking about in more detail tomorrow) will be available with the current state of that application included. This means that not only will Plasma Active grow every fortnight with the fruits of Contour and Plasma Quick, but as a user or developer you will be able to watch the suite of included applications bloom with each spin of the operating system.

How You Can Get Involved

If you are working on an application or Plasmoid that you'd like to see become an Active App, if you'd like to help define what "Active App" means and/or if you'd like to help test (or just enjoy watching it grow), here's how to join the Plasma Active team and start participating:

• Read over the Active App definition page. Bookmark it, subscribe to changes by hitting the "Watch" tab, be ready to revisit it from time to time as it grows and is refined.


• Join us on the active at kde.org mailing list and/or in #active on irc.freenode.net. Join the conversation, challenge the existing ideas and add new ones to the discussion.


• Tell us about your application and how you see it fitting into Plasma Active, and we'll all work together to schedule its inclusion and work together on making it more "Active".

If you are unsure if your app is "ready" for Plasma Active, it won't hurt to ask for feedback and start a discussion. We have many months, several sprints and conferences and a major KDE release day in the summer between now and the first Plasma Active release. During that time work on making your app "more Active" can happen. There will also be more development cycles to follow this one that wraps up in the fall. In other words, don't sit on the fence pondering ... jump on the train today!

Read More

Plasma Active: Contour

Foreword

This is the second in a series of five daily blog entries covering the various tracks in the Plasma Active initiative. This entry covers the Contour project, which you can read more about on Eva's blog as well as Marco's. I recommend reading those entries in addition to this one.

In The Beginning...

The Plasma team has been working on the idea of "activities", which allows you to topically group related widgets, windows, documents, etc. essentially since the initial Platform 4.0 release. It is a unique feature that no other production desktop offering provides and for people who use their laptop or desktop for more than one specific thing, they can be a very compelling feature.

Sebastian Kügler explained the idea of activities in detail to Eva Brucherseifer, who is the CEO of Basyskom. She also served as President of KDE e.V. for a number of years, so she is no stranger to KDE. Eva thought about it and began to realize the potential for this idea if applied to mobile devices. She envisioned an alternative to the application centric device paradigm: a context centric interface. Activities would be the doorway through which your mobile life would be presented, organized and interacted with. Thus was born Contour.

Here's a preview of the current status of the project (and note that these are not mockups, but functioning implementations):

Donwloadable OGG format

Our First "Active App"

The decision was made to implement this activity-centric interface using Nepomuk for storage and retrieval of data and Plasma for interaction with the results. After some initial interface and technical design work, a basic implementation was crafted to see if the concepts that looked so tantalizing on paper would transition clearly to the small screen. Thankfully for all of us, they did.

It was only natural that when we got together to start the Plasma Active initiative, Contour would become the first of what we would come to refer to as "Active Apps". These are applications which fit the goals of Plasma Active developed by teams of like-minded individuals. I'll be talking more about Active Apps and what defines them tomorrow.

Contour's role in Plasma Active is simple: it provides a unique and innovative aspect to the user experience, and will be part of the default tablet reference system. For more detailed information on the "how"s and "why"s of the design, check out Eva's and Marco's blog entries linked to in the foreword as well as this wiki page outlining the Contour vision.

Developing Contour

One thing you may notice about the Contour track in the Plasma Active milestone map is that there are a lot of "stops" along the line. In fact, there is essentially one milestone scheduled for every two weeks. A scrum style development methodology is being applied to the development of Contour and a new (pre-)release will be offered at the end of each two week cycle.

The developers have mapped out their feature and stability goals for each of these cycles. This detailed road map will be published and managed in the open as a means to guide the project through a brisk six months of development.

This is exciting for a few reasons. Not many KDE projects use such a development methodology so it's an interesting experiment to see how it meshes with our culture. If it works, we may see it spread to other projects as well.

This approach will also offer users and potential Plasma Active developers the opportunity to try out a new revision of the software every two weeks. No longer will you have to choose between building it from sources yourself or waiting months between final releases. To find out how we'll be making this process as easy as can be for you, be sure to check in on Thursday's blog entry about the operating system track.

For those who just want to watch rather than try it out first hand, the development team will be posting a progress update blog entry with each cycle.

Getting Involved

If you think the idea of a fresh interface for touch based devices that takes full advantage of Nepomuk and Plasma is a great one and you'd like to track or contribute to the Contour project, here's what to do:

• Get a device that suits Contour (I'll be making some recommendations in Thursday's blog entry) and be sure to download the bi-weekly preview releases (a how-to will appear in Thursday's blog)


• Read the content on the wiki pages for Contour


• Subscribe to the Plasma Active mailing list


• Join us on irc in #active on irc.freenode.net


• Put your imagination goggles on and buckle up! It's going to be a wild ride..

Finally, a word of "Thanks!" to Eva for the insight, commitment and support; to Sebastian Trüg for the Nepomuk ninja flips, Marco for wielding Plasma like a magician and Fania for her design expertise. They are a great bunch to spend time with and such a breath of fresh, positive air when working alongside them on a project like Contour.

Read More

Plasma Quick Redux

There were a few questions on my blog entry about Plasma Quick, and before I move on to discussing Contour I'd like to quickly address them here.

What About The Desktop?

More and more components used on the desktop will be written in QML. It's simply an easier and more designer-friendly way of achieving the results we have been aiming for. However, we will not be engaging in a re-write of the desktop shell in QML. In fact, it's quite likely that plasma-desktop will remain using QGraphicsView (via a support library that will ship alongside libplasma2, if all goes well) and that the usage of OpenGL, compositing, etc. will not change in the foreseeable future. The plasma-desktop shell works, we have more pressing things to do than break it. ;)

So while the desktop will benefit from the work we're doing in Plasma Active, it won't be hugely changed by it. We will also continue to refine and add features and increase the stability and performance of plasma-desktop. This is about expanding our scope, not shifting it.

How Can This Run On Small Devices?

People often get confused when they see a device that is quite a bit lighter in terms of resources than their desktop system happily running a Plasma based interface. The reason for this is easy: the desktop shell has a lot of requirements, such as a complex task bar and large wallpapers, that we just don't face on mobile.

In Platform 4.6, you can also compile libplasma without a variety of library support, such as KDE Webkit (falls back to plain QtWebKit), KNewStuff, Solid, KIO, etc. On the desktop building it this way would be a travesty, but on mobile devices where these library may not bring any benefit, we can trim them away. We plan on increasing this kind of modularization across KDE's libraries.

In combination, this allows us to make mobile interfaces smaller, footprint-wise.

Is OpenGL Going To Work Reliably?

As with footprint, people often use the state of the desktop world as a reference point when pondering how something like extensive use of OpenGL is going to work on a given device. This is highly misleading.

The graphics stack on F/OSS as used on laptops and desktops is not in the best of places. Running composited desktops sometimes works beautifully, sometimes doesn't work at all, sometimes sorta-kinda works ... it's a mixed bag. Why the variance? Simply because there are so many combinations of hardware and software, not all of which are equally supported and/or tested.

In the device world, it's a completely different story. The hardware and the software stack are, in the out-of-the-box configuration, both completely defined by the vendor. The idea is simple: pick a bit of hardware that meets the needs of performance and power usage, ensure there's a reliable driver for that specific piece of hardware. When the variables of "which card?", "which kernel?", "which driver version?", "how is it configured?" are removed, it's possible to get a device which performs reliably.

The desktop experience can thus not be compared with any meaning. Due to this, we do not provide fall-backs to non-composited environments. This lets us trim more code, decrease testing requirements and generally focus more on a single experience rather than a chameleonlike one.

How Can Interpreted Be Faster Than Natively Compiled?

It can't; at least not if you take the same code verbatim and run it through an interpreter and compare it to an identical but compiled to native machine code version. This, however, is not what we're doing. There are two reasons why moving to QML can and will improve the experience.

QML gives us a fundamentally different way of describing a user interface. Due to that difference, the painting can be handled very differently. So it isn't the same code at all, but very different code with very different results. More on this in a bit, however.

The most important thing to keep in mind is that very little time is spent in the QML or Javascript code. The overwhelming bulk of executed code is good ol' C++ compiled natively. The heavy lifting is done in C++, the light bits, such as describing the user interface or defining how the data is connected to the interface, go into the top layer of QML and Javascript. It hardly matters if the code responsible for 1% of the execution time is twice is slow. ;)

That said, there is ongoing work to optimize both the Javascript interpreter (part of the WebKit project) and QML itself, both of which are producing promising results. So a situation that is already just fine may get even better.

Why Not Make QPainter Use This Scenegraph?

As I mentioned earlier, QML provides a fundamentally different way of describing a user interface (declarative) compared to the traditional (imperative) Qt painting system. The important difference is that the scene graph needs full control over the painting and be able to know when something is going to paint, where it will paint and how. QML allows the scene graph access to this information. In contrast, the traditional Qt painting system puts the application code in the driver's seat and, as a result, there is only so much that can be gained by using OpenGL to render a QPainter based interface.

The different approach of QML allows a different kind of approach to rendering the interface that is well suited to a scene graph rendered on the GPU as much as possible. While the traditional painting system is just fine for traditional applications, driving visually appealing interfaces with multiple animations and transitions, particularly on low power hardware, requires something like QML to perform as well as possible.

Hope that answers some of the questions :)

Read More

Plasma Active: Quick!

Foreword

This is the first in five daily blog entries about the various tracks in the Plasma Active initiative. Figuring out which order to present each of the tracks was an interesting exercise. In the end, I decided to start from the middle and work our way out to the "edges". Also, keep in mind while reading each of these blog entries that all of the individual tracks are happening in parallel, and working towards a common end point!

Without further ado, I give you ...

Plasma Now

The Plasma library was designed to provide a generic construction kit for user interfaces made up of a "shell" (e.g. plasma-desktop or the Plasma KPart) and individual, interchangeable components we have come to know and love by the name of "Plasmoids". The idea has been to lower the cost of creating new primary interfaces while simultaneously increasing the amount of code, both at the data and the user interface level, that can be shared. A strong separation between visualization and data is encouraged right at the API level and has been a big part of achieving these goals.

With an emphasis on components and data separation it was only natural to explore writing components in non-compiled languages such as Javascript, Ruby and Python. In KDE Platform 4.6.0, Plasma gained support for QML, Qt's declarative interface language, as well as the ability to have device-specific interfaces in the same package. (Side note: Microsoft recently announced they were going to do exactly the same thing: one package, multiple interfaces. If device vendors had been using Plasma, they'd had that feature as early as last year.)

This is Plasma today. Plasma Quick aims to take what we've learned and accomplished and push it up a notch.

Plasma Quick

The Plasma Quick initiative aims to take libplasma, which is the underlying infrastructure for Plasma based applications, and make it an even better solution for devices that it already is. The focus points are simple:

• Performance


• Stability


• Device spectrum thinking


• Innovative user interaction patterns

The work done in Plasma Quick will inevitably also improve the desktop and netbook offerings (hooray for code re-use!), but the focus is squarely on the goals of Plasma Active: extending KDE's offerings for consumer devices. The result will be "libplasma2".

The "Quick" in Plasma Quick

In Platform 4.6 and newer, Plasma supports writing components in QtQuick's QML. One tantalizing thing QML holds out is using an OpenGL accelerated scene graph for all rendering. Having seen this in action, the results are impressive. To put it mildly. Think "better performance on a mobile device than on the typical desktop running the QGraphicsView equivalent". To get to the point that Plasma can use this scene graph, however, we need to have everything in a given shell done in QML.

This implies not using QGraphicsView. What we are planning to do is to put the QGraphicsView implementation in a second support library so that we aren't forced to rewrite plasma-desktop, plasma-overlay (aka Widgets-on-Screensaver) and plasma-netbook or the hundreds of Plasmoids people have written. libplasma2 will then rely on ScriptEngines for things like QML (as it currently already does) and allow us to write QML-only shells (as Plasma Tablet and Mobile already are) and take advantage of the OpenGL scene graph wherever we can.

Additionally, by promoting QML+Javascript to the top of the preferences stack of Plasmoid implementation languages, we will further encourage the division of labor between interface designer and software developer while making it faster to come up with fluid, modern interfaces that scale between devices.

A Whole Lotta Details

We've been collecting notes on the various changes we wish to make in libplasma2. There are a lot of details to take care of and therefore a lot of work. The first big in-person discussion and coordinated development push on libplasma2 will happen at the end of this month at Tokamak 5. Between now and then, we are continuing to collect stories and prepare things for the work to come.

If you look at the libplasma2 wiki page, you may notice that there's very little talk of new API (what we have is working pretty well, after all) and instead a lot of talk of improving what is there. Things like making DataEngine implicitly shared so that we stop passing around pointers and start passing around references or merging the various Package classes. These are the sorts of things that usually come to light only after extensive usage; these are the details that become evident after the broader strokes are laid down and well tested.

There is a lot of low-hanging fruit in there, and once libplasma2 opens up (probably later this month) there will be all sorts of great "junior level" jobs.

Newness, Too!

We'll also be introducing some new interaction patterns, including one I'll be blogging about next week that we've taken to referring to as "SLC". (Can you guess what those letters might stand for? ;) These won't be added directly to libplasma2, but be offered as components and D-Bus services. So there will also be some "new shiny" in the Plasma Quick track as well.

Somewhat Unsexy, But Unstoppable .. Like a Freight Train

We're well aware, however, that the Plasma Quick track is mostly "unsexy" plumbing work. And we like it that way. We want to improve this bit of "middleware" so that it improves as a construction kit for shells and an app creation platform. We don't feel the need to shake the whole world up at this level in the stack, however. There will be enough of that elsewhere. Plasma Quick's purpose in life is to make the exciting work happening in the other tracks possible and easier.

As can be seen in the roadmap picture above we're aiming for 7 milestones in Plasma Quick. The first will be an early release and announcement of "SLC". The second will be our work at Tokamak5 where the Plasma developer community will lay out a firm roadmap for libplasma2 implementation work. Further milestones will be time based cyclical releases. I expect the first couple to be a bit longer (e.g. ~3 weeks) as we move some big pieces into place, such as the separation of Plasma QGraphicsView, and then we'll move into higher gear and sync up with Contour with 2 week development windows as we work on things like QtComponents for Plasma, SLC, etc.

The goal is to have a well tested and tight libplasma2 ready for the auspicious October 9th date, or "9.10.11".

How You Can Get Involved

If you'd like to be a part of the next big iteration in libplasma, check out the code in kdelibs/plasma and kde-runtime/plasma. Join the plasma-devel mailing list, visit us in #plasma on irc.freenode.net and introduce yourself. (We don't bite, promise! :) Read the libplsama2 wiki page. Then start tossing your questions, thoughts and ideas around. There are no wrong questions or bad ideas; we do challenge ourselves to come up with the best ideas we can as a group, and we do that by examining the ideas we all offer with great scrutiny.

Bring your spirit of adventure, your positivity and your get-stuff-done attitude. This is a track for software developers who want to do exciting things that lie "just under the covers".

Tomorrow: Contour

Tomorrow, I'll be writing about Contour. In fact, there will be two others writing about it as well, including one of the interface designers in the project which will give us all an opportunity to "meet" her. This is a track that combines software development, interaction design, graphic art and writing, so it offers more opportunities for participation relative to the more traditional software project that is Plasma Quick. This is also the first of the Truly Exciting(tm) tracks in Plasma Active for end users.

Until then ... keep Plasmating! ;)

Read More

active routes

Both Sebastian and Marco have now blogged about Plasma Active, and we're working on getting more presentable information on what we're working towards put together.

In a nutshell, Plasma Active is about getting the KDE Platform with Plasma providing a compelling user interface ready for and available on hardware devices outside the usual laptop and desktop form factors. While we continue to do a pretty good job on our traditional turf, we have work ahead of us if we wish to realize the dream of covering as much of the device spectrum as possible.

Plasma Netbook was one important step in that direction, and it helped us understand how much further we needed to go. Projects such as Kontact Touch, Marble To Go, Caligra Touch, KDE Games for mobile (among others) are raising facing many of the same challenges. We need a reference, from top to bottom, that provides an installable image with a common build of the KDE Platform, great integration between selected applications and a primary user interface that is relevant to the hardware (e.g. touch centric) and great to use. Ultimately, we aim to create an active, open, non-exclusive ecosystem around KDE software for consumer devices and work on getting those devices into your hands.

Our immediate goal is to lay the foundation for an open, active and inclusive initiative with as many participants as possible to work towards this common end. With the help of community members like the Sebastians (Trug and Kügler :) and Marco as well as companies such as Basyskom and Open SLX we have made a start on working towards this vision.

We have divided the current work up into five concurrent tracks, each of which represents a different aspect of what is needed to meet our goal. We are working to coordinate all of these paths and make sure they are working together. Over time, we may add more tracks, but for now we have our plates full.

During the first meetings where we discussed this set of ideas, I was reminded of a train system, with different tracks carrying different trains with various cargo on a sharp time schedule to arrive at a common destination. This became my personal internal visualization of what we were setting out to do, and so I eventually sat down a drew it out:

Those "stops" on the lines aren't arbitrary, either. They each represent a specific interim goal or an announcement we plan on making. Some of these stops will be well advertised in advance, such as the September release date for Contour, others we'll reveal over time. We're trying not to overwhelm with information on the one hand, and we have details to work out for some of the other milestones before we can commit publicly to the details. We should have new information and progress to show every single week and there will be lots of opportunities for others to join in as well.

Over the next five blog entries, I'll cover each of the five current tracks, what the plans are, how you can get involved and how it fits in with the Plasma Active vision.

1. Plasma Quick (Monday)


2. Contour (Tuesday)


3. Active Apps (Wednesday)


4. Operating Systems (Thursday)


5. Vendor Support (Friday)

p.s. I'm not an artist, so the image looks fairly .. er .. lack luster in the artistic accomplishment category. ;) If you'd like to help bring it to life, the source SVG is right here.

p.p.s. I've whipped up a little Plasmoid that shows the latest Plasma Active related news and the progress of each track as we go. It fetches the data from plasma.kde.org and is still a work in progress. In fact, it even revealed a small bug in libplasma I fixed and which will be in the next 4.6.x release as well. I'll continue to refine it and will do a proper release of it in coming weeks. It will, however, allow those who wish to follow us in to do so in a fun and convenient way. :)

Read More

sounds familiar? well ...

This is a follow up to my blog entry from yesterday that quoted two sources talking about communities. If you haven't read it, do so now, otherwise what follows will make very little sense. ;)

Here's the "big reveal": those quotes were talking about studies of isolated human communities that have remained outside the influence of states and which exist (or existed at the time of study) somewhere between being hunter-gatherer societies and being integrated into a modern socio-political power.

The first quote (the one with bullet points) was from a presentation by Dr. Charles Efferson on research done in the New Guinea highlands in search of an answer to the question: how does cooperation evolve if it is seemingly at the expense of the individuals involved in cooperation and, when people don't, those who enforce consequences? Dr. Efferson is an evolutionary ecologist who studies "behavioral dynamics associated with the social transmission of information". In describing the behavior of tribe members of New Guinea, he could just as well have been describing many Free software projects.

The results presented in the talk were fascinating and, at least for me, a little counter-intuitive in places. It's hard to argue with hard science, though, and the numbers seem fairly clear: cooperation evolves through group-selected psychology, and it happens in the culture rather than the genome. For those interested, the slides to his presentation are here, but be warned that a lot of the content he presented is not on the slides themselves. The main experiment and its findings are well documented in the slides, however.

One really interesting aspect of the results is that the behavior of individuals was apparently driven by deep ancestral (evolutionary) psychology rather than the in-the-moment explanations and rationalizations provided by the participants. The state of the social evolution in these communities coupled with their histories caused the repeated (and repeatably testable) exhibition of behaviors in a scientifically controllable manner: and it consistently demonstrated strong in-group vs out-group bias. Ok, no big surprise there (the surprise is in the group selection bit), but to see it so starkly ... ...

The second quote in yesterday's blog entry was a series of highly abridged paragraphs from a book entitled "Rethinking social evolution: the perspective from middle-range societies" by Jérôme Rousseau published in 2006. In it he maps out the evolution of societies and the tension between self interest and cooperation, based largely on several decades of research involving "middle-range" societies spread across the globe from Canada's arctic regions to Lowland South America, from the highlands of New Guinea to those of Malaysia. There are no hard conclusions (in the scientific sense) in the book, but it attempts to provide a base for further research and examination. (Apparently, he's doing computer simulations based on his collections of real-world data.)

It wasn't the conclusions of the quote sources, interesting as they are, that caused me to write this blog entry, however. It was that the communities being described in both cases behaved analogously to many open source communities, and that those communities were in a fairly early state of social evolution. This probably shouldn't have been surprising: both are made up of people and at particular states of social evolution.

What does this mean for us working in the trenches of Free software, tending to and caring about our communities and those in them?

First, it seems to me that Mark Shuttleworth's observation of tribalism last year was more than a little "on the money" in a very literal sense. When we look at real world tribes, we can find analogs for the dynamics we see in Free sotware. It's an odd sensation to realize how our communities which are based largely on readily available computer-based "instant" global communication echo far more "traditional" contemporary cultures that many would identify as "primitive" technologically, socially, etc. But there it is .. we're all people. We can learn from this, from each other, from the people living in the highlands of New Guinea and our own culture's historical movements into more complex structures.

Second, we can probably measure with reasonable accuracy where on the social evolutionary continuum open source communities are, which seems to be: pretty far from the start but a long way off from being truly sophisticated.

Thirdly, we are dealing with patterns of behavior which we likely owe to our ancestors far in the past and which are, for at least certain kinds of interactions, highly resistant to rationalization.

Realizing where we are can be a great asset in trying to get somewhere we might identify as being "better". The perspective it can give us might allow us to choose our pathways with more insight and foresight. It also perhaps can grant us some new humility in terms of how far we've come together thus far. Finally, it may give us pause when we try and justify our reactions and positions with rationalizations, because that's all they might be: rationalizations but not reality. Instead of attempting justification (we're all clever and many are clever debaters), perhaps we can instead step back and ask the more pragmatic question of, "Is this ultimately leading to the results we want? If so, how do we make more that? If not, how do we change the pattern of behavior?"

I wonder if and how we (humans) can become more aware of the large scale social systems we are a part of, learn from the last few thousand years of experience that we're slowly piecing back together (thank you science, once again!) and in doing so improve both the path taken and the destination arrived at in our shared journey to large scale sustainable communities.

The more I learn, the more I understand how much there is left to learn, how much growth I personally have left to do, and how long the road we might share stretches out before us. The beacons of history and scientific endeavor string out beacons above us like stars marking directions to destinations that lie over horizons which we can not see beyond from our earthly positions. Raising our eyes to these signposts, we may navigate with greater purpose to ends which we can still but hope for.

Read More

sounds familiar.

This sure sounds familiar (slightly edited):

• "Because daily life remains largely outside the jurisdiction of [corporate]-supported legal institutions, social preferences, local norms, individual reputation, and group affiliation are the main forces that govern social [interactions].


• Because of the [meritocratic] system, shared group affiliation is an especially strong cue associated with reciprocity and reputation.


• [Projects] have a long history of conflict with each other, which suggests that ancestral conditions may have been particularly favorable for cultural group selection."

Here's another slightly edited excerpt, albeit abridged for brevity to turn several pages into a few "bare essentials" paragraphs:

"Accountable reciprocity [..] brings about new forms of cooperation, and calls for new ways to manage conflict. The most fundamental result of accountable reciprocity is a reduction in individual autonomy. Membership in groups becomes a central feature [..] This calls for more complex forms of political organization in order to manage the group's resources. At first, leaders have little power; their main role is to limit conflicts, given that people can not [easily create and sustain forks] when problems arise.

[..]

Because [projects] control the product of their labour, and because community membership is stable, it becomes possible to invest in more complex forms of organization. As people try to protect and enhance their own interests, they are motivated to bring about new regularities from which they expect to benefit. For instance [..] it becomes important to develop strategies to manage membership. In so far as communities keep people together, it becomes imperative to manage conflict in order to prevent community fragmentation. [This] can be realized in a huge variety of ways, which is the reason for the variability of middle-[sized communities]. Gender roles may be more or less contrasted; [seniority] differences may be more or less hierarchical; leadership may be diffuse or concentrated, more or less inclusive.

[..]

Greater complexification is possible only by constructing structures beyond the [individual projects, and this is accompanied by] a continuum of increasing marginalization, whereby an increasing proportion of the population plays a minor role in decision making. [(Coverage of some posible strategies omitted.)] These communities are the precursors of complex [aggregations], in which several communities are integrated into a [single entity].

[..]

Strong [project teams], stable local groups, and some form of local leadership emerge from accountable reciprocity. They are the backdrop for other social structures that may become salient in middle-range [communitites]. [..] Because social stratification derives from political practice, it is at least in part a consequence of conscious choices; social actors are in a position to select alternatives on the basis of their perceived self-interest and their power."

I reflected on the state of Free software communities when reading the above along with their context. It all seemed insightful and relevant to the dynamics we experience. Where did these quotes come from, and what were they getting at? That's tomorrow's blog ...

Read More

just another day in paradise

What a week that was! Yesterday I did what I probably should have done on Tuesday: I slept. And I don't mean just through the night, but also through half the day. I've always been one of those people who recover best when sick while sleeping (as a child, sleeping over 24 hours at a stretch when sick wasn't unknown), and I was shaking a frustrating cold last week. Of course, instead of sleeping I was in Darmstadt.

We came away from the meeting with a huge task list, a lot of information and no less than five concurrent roadmaps for five different aspects of the meta-project we have been putting together. We're getting our notes in order, milestones settled a bit more firmly and initial documentation put together still, however. Sebastian will be blogging later with more details on this, so I won't get into details here.

There are two things that, while certainly not project definers, have caught my interest in special ways. The first is that due to the combination of schedule and complexity of the project (in terms of the number of individual efforts that are coming together for this) we are employing some more rigorous project management techniques. In particular, we will be using the scrum method with two week "sprint" intervals. The planning and organization of this will be done in public, and we're evaluating F/OSS scrum management tools. While not particularly new for software development, for our F/OSS projects it is. I'm particularly interested in seeing how well it meshes with the KDE culture.

The other interesting atribute is the scope of things. This is about KDE software, yes, but it's also taking the operating system and middleware stack on as well. We certainly are not doing an "OS from scratch" thing, but this may be the closest upstream KDE projects will have participated in what will end up being a download-and-try-or-flash image.

Outside of being brought into this project as part of a really great team, I've been kept "slightly" busy with other things as well. Today was the first day of my "intensive" German language course; 3 hours a day for next 3 weeks (at which point Tokamak interupts ;) at a waaay too early in the morning hour. Well, for me at least. After that, my work day starts.

This evening I'm attending the Linuxtage install event at ETH here in Zurich. I have prep work left to do still for Tokamak 5, where Plasma Quick will be a big part of the discussion. This is joining the growing list of events coming up, which now includes the X Free Software Workshop at the Polytechnic University of Catalonia at the end of June.

I was also on the Frostbyte Media's Froscast podcast this weekend. The show is an edited down version of an epic multi-hour conversation we had ranging from accessibility to what's new in the 4.6 releases and beyond. The host is an absolutely terrific fellow as well, and it was a joy to be his guest.

The tram is about to arrive at the building where the install fest is at, so I should wrap this up.

Read More