aseigo

open beyond licensing

2012-01-31T14:43:00.002Z

Use The Source!

When I first let the world in on our "little" project to create an open tablet there were some who wondered openly about the licensing of the software. It's an important question that deserves a clarifying answer:

We are not using the OS (Android, in this case) provided by the hardware manufacturer. We are also well aware that some of the people in the hardware supply chain are violating the terms of the GPL. This was amazingly frustrating for us and caused significant delays as we went in search of GPL friendly vendors. We found that in the market of affordable device makers in China, they just don't exist. There's a cultural as well as legal hurdles that have led to this unfortunate situation, and I personally think Google has a lot to answer for when they allow such companies open access to their app store while they must be aware of the license violations that are going on. So it's an unfortunate situation, but we're problem solvers, we're bad-ass Free software developers who see a problem and bang on it until it falls over, right?

We decided to go with Mer, the community continuation of MeeGo, as our base OSS. With the amazing help of the Mer community, we have been able to bring up a non-Android, built-from-source kernel on the device and even boot into Plasma Active. There is still work left, and we still do have some binary drivers, but this progress is already one massive crowbar that's prying open the doors that have been shut on the world of ARM based devices.

We're not the only ones working towards such a brighter future: there is Luc Verhaegen's work sponsored by CodeThink on the Mali 400/200 GPU driver being announced as FOSDEM; there is the Rhombus-Tech project that is working on a GPL kernel with Allwinner for their products such as the A10 (a chipset we'd already been looking at for (near) future devices). These are all awesome projects, and I'm happy to be a small part of this growing wave of effort. Simply put: we need open devices, and this is how we're most likely to get them. Hopefully in the future it will become "the way it is done" by all vendors out there, but it takes some early movers to take the first steps and force change.

Since we're using Mer for the user space and Plasma Active for the user experience, all the code above the kernel and most of the kernel itself is already open and available for download right now.

Full disclosure: right now we're still stuck with a few binary drivers which is not a perfect situation. With time I'm confident we'll get the binary drivers out of the picture, one by one, even if it takes time, effort and some pain. We've already managed to get source for some drivers that were not previously available so the trajectory is right. If we wait for perfection, however, we'll never get anywhere because we need to release and push the status quo level of openness further inch my inch by making releases. It'll be incremental, but we're already further than others have gotten. It's been hard but rewarding work, and I hope we can all work together to make it go faster, bigger and further!

Open Beyond Licensing

I do think it is unfortunate that when I wrote about an open and unlocked device, so many people jumped straight to the topic of source code licensing. Free software is not about licensing. Let me pause while the shock of that idea sinks in for a moment. ;)

Free software is about freedoms. Licensing is an important part of the toolbox to ensure those freedoms are available, but they are only tools not the actual product being aimed for.

This is important to keep in mind because openness and freedom goes a lot deeper in Spark than just using GPL and BSD licensed code. For instance, the boot loader isn't locked so you can boot your own OS if you wish. You can install your own apps, you can even provide your own app delivery system. You can use the Open Build Service to deliver software on top of the Mer core. That is not a property of the open licensing, but of our desire to deliver devices that you not only purchase but wish you own.

The content store is also going to be interesting. On release, the client will be Free software and the APIs openly documented so others can write front-ends. Most interestingly, however, is the server side. It has been designed in such a way that other people with other devices or concepts can use that same back end to make their own stores. It supports the idea of a single, large set of content which can then be curated into any number of different stores with different focuses and delivery targets.

Think about the possibilities: a school district or educational board could decide to set up a "store" with learning materials and content with access granted to their students. They could offer both "free" and "pay for each download" content, even if only for bookkeeping purposes. Much like the wildly successful video game markets for gaming consoles, the Make Play Live content store uses a points system for transactions, so in such a scenario points could be handed out to students, schools and/or entire districts.

On release, we will be providing a guarantee that if the project dies or we all fall over, the back-end code for the store will be made immediately available for download under a Free software license. Hopefully it doesn't come to that, of course. Once we are happy with the implementation and scalability of it, we will be making the back-end open as well. We have chosen to delay that release as we don't want others setting up their own hosted stores before we are confident in the internal design ourselves.

Even Activities themselves, the core interaction concept in Plasma Active, embody the philosophies of freedom and openness. This is your device and it should become your personal thing reflecting you. You are not treated as a mere consumer for an app store, but given a tool to help you live your life in some small way.

I really urge people to think about openness and freedom, two amazingly important concepts, beyond the boundaries of simple software licensing. Licensing is important, and we take it pretty damn seriously .. but we ought to look at bigger picture and really think about how to make our digital tools open and free in all sorts of ways.

Tomorrow I Answer Questions

There were tons of really good questions asked on my blog, on tech news sites that carried it as well as by private messages. Tomorrow I will do my best to go through answer as many of them as I can with short, to-the-point answers. I will be covering information ranging from release time lines to pre-orders to more hardware details to .. well .. visit tomorrow to find out!

the reveal

2012-01-28T01:16:00.000Z

The Reveal

As I noted earlier in the week, my recent blog posts have been slowly leading up to something, and here's what that something is:

The first tablet computer that comes with Plasma Active pre-installed.

It's name is "Spark", in recognition of it being the start to an even bigger flame.

It sports an open Linux stack on unlocked hardware and comes with an open content and services market. The user experience is, of course, Plasma Active and it will be available to the general public.

The hardware is modest but compelling: 1GHz AMLogic ARM processor, Mali-400 GPU, 512 MB RAM, 4GB internal storage plus SD card slot, a 7" capacitive multi-touch screen and wifi connectivity.

I'm sure some of you are already wondering what the retail price will be. The answer: a mere €200.

A Bit of the Bigger Picture

This is more than just another piece of hardware on the market, though. This is a unique opportunity for Free software. Finally we have a device coming to market on our terms. It has been designed by and is usable by us on our terms. We are not waiting for some big company to give us what we desire, we're going out there and making it happen together. Just as important: the proceeds will be helping fuel the efforts that make this all possible.

It's also more meaningful than "just" Free software: The people who get to use these tablets will have in their hands a device that is more than an application bucket that sees them as a consumer. They will have a device that places value on who they are and what they are doing. This lies at the heart of Activities in Plasma Active and the open software stack will drive that trend further. Perhaps best of all: there's no walled garden to get locked into or which can be taken away.

This also will provide opportunities to the wider Free software ecosystem. Partnerships are being forged to provide things as diverse as OwnCloud hosting services, Kolab and Kontact Touch deployment support and exciting Qt/QML add-on apps for download.

The content store will offer great Free Culture artifacts such as digital books from Project Gutenberg as well as contents and apps for purchase. It will provide a conduit to users for those who love writing great software, Free and otherwise, using the typical Linux tools.

In case it wasn't painfully clear already: this epitomizes what I've been writing about for the last few days. It is a product made with and out of a commitment to the philosophy of making, playing and living. In fact, that's the brand under which this tablet, and those that follow it, is being brought to market under: Make·Play·Live.

.. but that's not all! ;)

I'll be sharing more information as to when the tablet will be available to be shipped directly to you (soon!), how you can place orders for them as well as more details on the hardware and software provided.

This will have to wait until Tuesday, however, as I'm off on a business excursion for a couple of days. Leave your questions in the comments and I'll do my best to cover them all in the coming blog posts.

Some Credit :)

Before I go, though, I want to offer some credit where credit is due. I've been involved in bringing this to fruition, but I most certainly have not been alone. The entire Plasma Active community, with their commitment and efforts, have been critical and inspiring. The efforts and commitment of both individuals (such familiar names as Marco, Sebas and Martin) as well as companies such as Basyskom and OpenSLX have been critical to making this even possible.

We've also had the support of projects such as Mer, the community continuation of MeeGo. One shining star there for us has been Martin "vgrade" Brook. He's a contract software developer contributing Mer hardware adaptations and Plasma Active bring-ups on ARM devices such as this one as well as various Tegra2 Tablets, Ti Tablets, Nokia devices and the Raspberry Pi.

Countless others have worked in so many ways I could never even begin to cover them all. This tablet is only possible thanks to the KDE community, to Qt, to the Linux ecosystem and to the pioneers of Free software.

... and finally a bit about my own future

In a few months I will no longer be sponsored by Qt Development Frameworks to work full time on KDE. I have been looking at various possible paths that lie in front of me, and as I've been going through this process I jotted down a few things that I would like to share with all of you:

First, I am deeply grateful to have had the opportunity to engage so deeply with a community as great as KDE thanks to the support of a company as great as Trolltech and right through its evolution into the Qt Development Frameworks we know today.

Second, I won't be leaving KDE or Plasma, let alone Free software. My heart lives here and I can't imagine not being involved.

Third, this is an exciting doorway through which I am stepping. I can not see with perfect clarity what lies on the other side, but it looks bright. :)

live

2012-01-27T23:58:00.000Z

We Seek Quality

Quality of life is a topic often discussed. There are so many different methods used
to try and measure this rather intangible aspect of our experience. We all have some sort of intuitive grasp of what it means, however: fulfillment and engagement, contentment and industry.

We want to neither go without nor to have everything simply handed to us. We desire peaceful lives sprinkled generously with happy events while also being spared from overly repetitious dullness. We crave companionship and simultaneously seek out competition. We hope that taken together these characteristics will lead to a wonderful tapestry woven of our experiences, relationships and memories which can whisper to us the meaning of our lives.

So quality of life does not seem to be an overly esoteric concept, yet it can be devilishly hard to get a hold of. Certainly life is not perfect and many things can and do go awry over the course of a lifetime; but even with those unavoidable bumps, we ought to find patterns of life quality in our choices and experiences.

Actually Finding It Is Another Thing

Living well is something that is learned. At least, I know that I'm still learning more about what it means to do so every day.

One thing I've noticed is that we tend to construct unfortunate narratives which get us to focus on things that do not really contribute to quality of life at all. It's perhaps easier to identify these narratives by imagining the autobiography of a live driven by them:

"On that fateful day 25 years ago, I finally managed to find a store in the mall that had the phone I had been looking for. I activated it and downloaded Angry Birds. The very next day I went to work with people I can't really remember anymore working on something I only recall as being rather boring; at least I don't think I learned anything from it, though it certainly allowed me to pay for all the network I was using with my new phone."

Really? It isn't like we all need to be riding rockets to the moon or painting the next Mona Lisa, but certainly we can live in a way that adds to something worth reflecting on in years to come.

Yet collectively, we are investing so much in things with far too little meaning, typified by punch-the-clock jobs used to make us into engines of consumption. Yes, we need to work. Yes, new toys and gadgets are awesome. Yes, Angry Birds is indeed a little addictive. These should be fillers, though, not the content of our existence.

So I Asked Myself: What Can I Do?

If I wish to live in a world where people are living lives worth living, then I need to try and help create an environment that supports that.

I wish to engage in ways that contribute to the mindset of living meaningfully. I want the things I make to contribute to and support the unfolding of meaning in the lives of others.

Getting there means stepping aside from some of the dominant models in society today such as "the person as consumer" and "the person as work unit". It means finding models of value that emphasize lives lived with quality. It means creating things that reflect that value.

In short, I can't rightfully expect to find lives of quality if my own efforts work in the opposite direction. I know I will not always achieve such high aspirations, but I can certainly try and, hopefully, succeed often enough to make a difference of some size.

Epilogue

This set of make, play and live blog entries may read like so much philosophy, but these are things I truly care about and which I want to find at the heart of my efforts. They are the metrics by which I wish to measure myself by, and which I hope to inspire others to consider as well. If I can manage that, what better life could there be? :)

play

2012-01-26T12:52:00.003Z

There's a well-known saying which first appeared in a book by James Howell published in 1659: "All work and no play makes Johnny a dull boy." The message is that life should not only be about the seriousness of work and that enjoyable, recreational activities are an important part of life. It is as true now as it was three and a half centuries ago.

Humans aren't the only ones who engage in play, of course. Many animals also play extensively, mostly while growing up though some continue to do so well into adulthood. It's one of the reasons I love having cats around the house: they are given to running around, chasing things (and each other) with obvious joy and frivolity. In addition to the enjoyment they get from it, this play has a pretty serious component: it's a way to put their skills into practice and improve them. It can also be a way to build social bonds with others of their social group.

Similarly for us humans, play can be more than just enjoyment and relaxation. It can be applied to creative processes to draw out truly great results from both individuals and teams. It can let us explore ideas, social interactions and generally open doors to new experiences and modes of being. It's a safe and enjoyable way to experiment, all while helping relieve stresses and pressures that may be trickling in from the more serious efforts in our life.

Sometimes I get the sense that technology has been getting more and more unplayful and that saddens me. The industries built around computing are massive. Billions of dollars swirl around them every day, and that sort of scale certainly requires a good amount of applied rigor and seriousness to keep things moving. The sheer amount of money that can be made coupled with the increasing complexity of technology and the ever rising expectations from people who use it can lead to an overly serious, unplayful environment that produces overly serious, unplayful results.

I've noticed that even many of the most popular games available for devices like phones and tablets these days are built around obsessive, repetitive behavior wherein you collect synthetically scarce imaginary resources and vie for the approval of imaginary beings. While rewarding to certain aspects of human psychology, these games are less playful than work-like. They don't even give you much opportunity to expand a set of skills. Even our most serious of traditional games, such as chess or go, are opportunities to exercise and grow strategic thinking while bonding with other humans. If even our games are less playful, one need not apply much imagination to how opportunities for playfulness are elsewhere.

In short: without play, life becomes dull and we risk become an increasingly boring group of people. That's not the sort of experience I wish to have, nor the sort of experience I wish others to have when using the things I help make.

The activities of play, when added to the other ingredients of life, can help create a fantastic and dynamic experience. That's why there's a certain seriousness to being playful; there is even such a thing as "serious play" which is being increasingly explored by those focused on innovation and communities. There's also, of course, the completely freeing and frivolous sort of play that rounds out this picture.

Make and play. Play and make. They go together, and I'd like to not only experience this myself but help support others in finding their own moments of exuberance.

make

2012-01-25T10:04:00.001Z

Make

There was a time when most everyone I knew had some sort hobby or past-time in which they made things, often simply for the sake of making. From this they derived enjoyment and personal meaning. The meaning was not kept to themselves, either: I remember being invited to watch a cactus that flowers most spectacularly but only once per year bloom as evening set in at the house of a hobbyist horticulturist. I spent evenings with good friends in old barns or in the comfort of their living room making music, listening to others play instruments alone or together, sharing stories they had written. I watched a friend sail out on a boat he built with his own hands in his own back yard, taking other friends out on day excursions on the waves. I've also watched that kind of involved life fade out from being the norm to being the exception.

Over the course of 2011, I had a strikingly consistent conversation with various individuals on this topic of making. In particular, the discussion would end up pondering why so few people in industrialized societies engage in the process of making. We would usually end up mulling over the role of modern patterns of consumption in this trend, what we have perhaps lost and how we might bring making back into the mainstream.

Sometimes the conversation would bloom out of a discussion of consumer centric social structures; sometimes we got onto the topic by way of possible economic alternatives to "we must find everyone a wage based job"; and other times I simply brought up the topic on its own. From those interactions, I took away three primary points of personal interest.

First, whether one self-identifies as conservative or liberal (economically, socially, politically or some combination thereof), people are generally aware that we make less and consume more, that the ratio between those behaviors has changed significantly towards the latter and that this is somehow not a great turn for our societies.

For many consumption has become the primary mechanism of involvement. There is nothing wrong with consumption itself (if we do not consume air, water and food, we will in short order cease to be), but it also probably isn't enough on its own. A working balance between participation by making and involvement by consumption has been lost.

Second, there is a distinct sense that many societies have begun to forget what it means to make. I had to remind one fellow, an academic that has found a very cool niche in the NGO world, that he did actually make something in the course of his daily work, even if it is not a physical good. He caught himself in surprise at the realization that, yes, he did make something ... and often.

Others expressed concern that fewer and fewer people knew how to really make much of anything. Instead, the skills being commonly acquired seem to be more geared towards acts of consumption, or for practices that don't really create anything.

Third, regardless of the trends towards consumption and away from making, there remains a high degree of value placed on the act of making and on those who do so. Aside from the obvious observation that we hold those who are great makers (which may be different from people who make great things) aloft in our societies, there is a definite inner connection to the act of making alive in people. We have not (yet?) gotten to the point where we have forgotten there is great value in the act of making things.

Despite all that general agreement, no one I talked to had any really solid ideas on how to bring making back into the core of our collective experience.

At the same time ... The Maker Faires are beacons of hope; the open source world continues to be a hive of activity; Wikipedia and OpenStreeMap bloom; kids still love lego; and I still bump into people doing crazy and wonderful things "just because". However, it seems evident that prioritizing behaviors, activities and objects that encourage and support making over simple consumption is still very much needed.

This avenue of thought has caused me to reflect quite a bit on what it is I am doing, what I am making and how I am encouraging and enabling others to engage with life creatively as well. Few things are as inspiring to me as watching something being made; few things fill me with more hope than someone with a warm heart and busy hands.

Yet if I truly believe that a world of people who engage in making is a better place to be, how am I contributing towards the realization of that reality? Eventually the obvious truth filtered slowly through my mind and hit me over the head with its simple truth:

I want the things which I help make to become opportunities for others in their turn to participate with their own voice, their own movement and their own passion.

fine tuning the trajectory

2012-01-24T09:09:00.002Z

It's difficult to come back to the blog after an absence without explaining what I was up to, what kept me from writing. I always feel I owe some sort of explanation for an unannounced silence.

In this case, it was pretty simple: changes are coming in my life and I needed some time to consider them. I find that when I'm sharing my thoughts with others on a more-or-less constant basis that my ability to work through deeper issues is lessened. This is why, every so often, I take some time to myself to just ... ponder. Often I don't realize I need to do this until I'm doing it, which is often why it comes without much warning.

I don't want to overstate it, however. I wasn't engaged in intense 24x7 meditations. I did take some time for family, enjoying mid-winter play with family and friends. Sledding, water sliding, geeking out at science museums with my son; building igloos in the mountains and watching fireworks on New Years with my wife. That sort of thing.

Most of the time, however, I was re-centering myself, finding where my energy is (and isn't) and working out what I wish the next few years to look like. I'm comfortable with the conclusions I have come to, and thankful for the support I've received during this process, particularly from family.

The path these decisions will have me embark on is not entirely easy nor comfortable. It embodies the good kind of the "scary": the tension that comes from doing something really exciting, really out there on the edge of your abilities; something that you can not guarantee a positive outcome for 100%, but which you really, really want to do with all your being and you know is within your abilities if you strive hard enough.

One of the most significant results of all the pondering in relative silence is this: My role within KDE and my relationship to the F/OSS community is going to be changing this year in fairly significant ways.

I will be writing more on this over the course of the week, culminating in an announcement on Friday that I hope you will find as exciting as I do. :)

quick bug days wrap up

2011-12-04T15:56:00.001Z

This is a quick wrap-up entry for Plasma Bug Days which was held over the last two days. First, we accomplished a lot. I mean a lot. The first goal was to drop into third place on the Weekly Bug Report. We accomplished that on the first day and so moved onto another goal suggested by one of the participants: have fewer reports open than we did six months ago. We also accomplished that. Now we have a new goal: break 1000. We're just 120 reports away from that goal right now.

Today has been relatively slow going as it isn't an official Bug Day so just a few showed up to do bug triage today. Quite promisingly, though, some people from the Bug Days showed up today again. I do hope all of them continue to be involved and help with the bug wrangling as their efforts were just fantastic this weekend.

I also set about to fix some of the older and more annoying issues in some of the more commonly used parts of Plasma Desktop. Many commits later, and many already-fixed (along with some won't or can't fixes, too), and the bug report count has dropped yet further. 4.8 is going to be a fantastic release.

Yesterday was really invigorating, as well: even more people showed up for day 2 than for day 1. That's understandable as it was the weekend. Together we mowed through large quantities of bug reports.

We also pulled together some Plasma bug hunting documentation for newcomers. It was very clear that handing out bugzilla account upgrades to those who took the time to show up was really worthwhile as well: it empowered people who may not have otherwise asked to help out, and boy did they ever.

I used to host bug days sem-regularly, but with project growth and life business they fell to the wayside. I'm happy to say, though, that bug days will be a regular part of Plasma life again, with at least one such event hosted every release cycle.

Our long term goal is to get down to a stable 400-500 open defect reports, and I think that is achievable. We have worked through 600 reports in just 2 weeks, over half of them just this weekend. So it is possible.

The results of a clean bug database are that it becomes far, far easier for developers to identify what needs attention. It also helps our involved users know that, yes, we still have a pulse and do care and pay attention, something that sometimes gets missed.

I now have a nice parcel of "junior job" bugs and a handful of "critical issues for 4.8" in hand as a result of Bug Days ... and a really good feeling about things to boot.

plasma bug day 1

2011-12-02T18:19:00.001Z

Today was the first of two Plasma Bug Days we're hosting this week in #plasma on irc.freenode.net. It started at noon UTC and people started rolling in. With the help of Ann Marie and Marco, we got the volunteer bug hunters up to speed and working with a high degree of effectivity.

So far (and we're not yet done for the day!) we've closed 62 reports. There were a number of fixes applied for 4.8 (and some for the upcoming 4.7.4 as well) as a result, and duplicates or already fixed bugs were also being caught. A good number of crashers were identified and fixed, and one vastly annoying bug where a panel would mutate and take over the whole screen when the screen count changed was also killed. That's pretty decent for a day's effort.

Big thanks and kudos to all those who participated so far, including asraniel, thijs, BrummbQ, mck182, emilsedgh, mrrub and Adaptee. (Hope I didn't miss anyone, if I did: mea culpa! and let me know :)

We'll be at it again all day tomorrow, so come join us in #plasma and have some fun with us getting Plasma into great shape!

plasma bug days reminder

2011-12-02T08:24:00.001Z

Just a quick reminder to all those interested: Plasma Bug Days start today at noon UTC and run until tomorrow night. You are invited to join us test and triage reports (no coding skills required!), participate in live bug wrangling workshops and, for the coders out there, fix bugs that the triage horde identifies.

They center of activity for this is #plasma on irc.freenode.net. As they say: come one, come all! :)

serbia

2011-11-23T16:01:00.001Z

I was in Belgrade last week for five days speaking at the B-Link festival. It wasn't just software, in fact it was primarily not software. There were panel discussions on various social, political and artistic topics. I met a musician from Ljubljana, the co-founder of the Dutch Pirate Party, local Wikipedians and several KDE fans .. not to mention members of the Math faculty at the university there.

It was my first foray into this area of Europe, and it was an interesting, educational and thoroughly enjoyable experience. Talking about politics with people there was interesting as conversations deviated from the standard memes, which is understandable given that this was a region with its own cultural history and heritage that was also at war less than 15 years ago. The transitions there in the last few decades have been sweeping and that has certainly shaped the mental landscape as well.

The physical architecture of the place was also interesting: relics of the cold war era sat stolidly next to the brands of today. I've seen pictures, but walking the streets is really the only way to get a proper feel for it. Unfortunately it was very foggy and a bit cold for much of the time I was there, so the weather certainly got in the way of this aspect of my visit.

Ivan Čukić helped arrange all this and he set up a really good program for presenting KDE at the festival. We had four people speaking on various topics with around 20 people in attendance. Most of those who came use Linux, many of them also use KDE software. The next day, Ivan arranged for me to speak at the local University where he also works and I got to meet some delightful people. Some expressed interest in getting involved with KDE as a contributor, so I'm hopeful to see some more commits coming from Serbia in the near future! :)

I'm still ruminating on my experiences there. Despite only being there for five days, there is lots to digest. Most of all, I hope that we managed to inject some KDE awareness and desire to those we spent time with. With that, at least, I believe we succeeded. :)

plasma bug days

2011-11-23T15:44:00.001Z

We want to make Plasma Workspaces 4.8 a great release, and one way to reach that goal is to take care of the defects that creep in. To do that, we need your help to groom the bug database. We also realize that to do that, many of you would appreciate some help and teamwork.

It's been a while since we've held Plasma bug days. They worked very well in the past so we're resurrecting them.

On Friday December 2 and Saturday December 3 in #plasma on irc.freenode.net from noon UTC until sometime in the evening (e.g. when the last of us pass out ;) we will be holding Plasma Bug Master Sessions From Outer Space And Beyond With Mustard Sauce .. ok, that's just a working title, admittedly, but here's what will be happening in #plasma on both days:

Live, hands-on, interactive tutorials on effective bug triage with an empahsis on the sorts of reports Plasma gets

Handing out bugs.kde.org account upgrades to people who don't have them but ought to

Massive, parallel, coordinated bug squashing. People who want to try their hands at simple patches are encouraged to join us, but coding skills are not ultimately what we need: we need to comb through the bug database marking duplicates, verifying fixes and finding big issues that deserve more priority.

Mustard sauce

We also have some targets. Over the last 3 days we've dropped the number of bug reports for Plasma by over 250 and are down by ~213 over the last week. Many were closed with patches, though many also were cleared out with simple bug triage. This is great progress but we have our eyes on the bug count table and, in particular, dropping from #2 to #3 in total bug count. That means another 170 reports to close. Come out and help us achieve that goal for an awesome 4.8!

more plasma workspaces 4.8 news

2011-11-08T19:08:00.003Z

In my last blog entry on Plasma Workspaces 4.8 I talked about a number of things that we've worked on in the last six months. I promised a follow up with more news in it, and so here we are.

Before we get to that, however, here's a little interlude showing Plasma Active One running on a Nokia N950 on Mer. You can read more about it here on Martin "vgrade" Brook's blog.

Plasma Active One on the n950

... and now back to the regularly scheduled topic of Plasma Workspaces 4.8. ;)

OpenGL ES and Compositing Performance

Compositing window management in 4.8 can be built with support for OpenGL ES. This means hardware acceleration using a more modern revision of OpenGL and one that is supported on mobile devices.

During development of this feature, Martin Gräßlin did a lot of clean up to the existing code bringing performance enhancements to how effects are handled and windows are painted. The blur implementation also received a significant improvement to its performance thanks to improved caching written by Philipp Knechtges; this provides quite noticeable results on many systems. In all, many fewer cycles are spent rendering and displaying the beauty that is the Plasma Desktop.

Thomas Lübking also helped simplify writing effects by introducing the new AnnimationEffect class so that development in this area can progress with less effort required to achieve results.

Power Management

There was a developer sprint was held for hardware and power management in KDE software and it was quite a success. A large number of bugs related to stability and predictability were fixed, but perhaps my favorite two things are that power management became multi-screen aware (so, for instance, plugging a laptop into an external monitor and closing the lid works a lot more like you'd expect ;) and power management became Activity aware so that you can have different settings per activity. I love this for when I'm doing things like giving presentations or watching videos: just switch to the activity with all the relevant files and apps and I don't have to worry at all about touching the power management settings.

Bug Fixes Galore

As the version numbers climb, one would expect so would the bug fixes. KRunner got a number of bug fixes, including fixing the kill runner and making sure all runners always respect their settings. The microblogging widget escapes HTML properly, the virus wallpaper works more consistently compared to the other wallpaper options, the location DataEngine works with newer versions of gpsd now and on and on. Lots of little things that one might never notice because they now just silently work .. and others you may notice because you stubbed your toe on them constantly.

I'm really looking forward to the 4.8.0 release due to all of these improvements, and I hope you are too! :) Thanks to everyone who helps make this possible by contributing their finances, their time, their imagination, their passion ... and remember that you, too, can Join the Game even if you don't have the time or energy to get involved directly.

Plasma Workspaces 4.8

2011-11-04T16:57:00.000Z

Having returned from two weeks away in Morocco, things have been hectic and Busy-with-a-capital-B. I've been working on some exciting new possibilities for Plasma Active which are not quite at the point that I can speak openly about them, but it's been taking a fair amount of my time and energy .. and I think it will pay off next year.

Rather than blog about Morocco (which I will do once I've processed the experiences a little more) or Plasma Active, I want to catch people up with what's coming in Plasma Workspaces 4.8.

Screen Locking

Screen locking has been moved into the KWin window manager. We did this to improve security, performance, X11 independence and the overall look and feel of things.

The security improvement comes from the fact that since the window manager, which is responsible for placing windows and when in compositing mode even making sure they appear at all on screen, now knows about the locker window it can ensure that no windows or glimpses of the desktop ever happen 100% of the time, something we could not achieve reliable elsewise.

The performance improvement comes from the window manager knowing when things are locked (and not). When locked, the compositor can simply not paint anything else but the lock screen, simplifying things a lot in the locked case.

The X11 independence and look and feel improvements come from supporting QtQuick (read: QML) for the lock screen. This allows us to provide non-password based systems (think: touch screen device friendliness) and simplify the interaction between what is being shown and the unlock mechanism significantly (limiting maintenane costs and eliminating bugs). It also allows us to simply make things that look better. Plasma Active uses this to provide a very beautiful lock screen that blends with the rest of the system and shows the current time along with a simple swipe-to-unlock gesture.

The X Screensavers are not supported with the QML lock screens due to the design of X Screensavers, which dates back to 1992 when things were a little different. QML gives us a huge amount of flexibility, however, and the opportunity to create things that are as good and better than what X Screensavers offered. (QML will support OpenGL shaders, at which point possibilities really open up wildly.) We surveyed our users first before making this change, and there was overwhelming support for the benefit/cost involved in this change.

QtQuick Splash Screens

A new splash screen implementation that uses QtQuick has also been added, thanks to the efforts of Ivan and Marco. It loads QtQuick, which implies Qt, so can not be as performant as the very small and slim tool that Lubos coded for the KDE desktop in the past. However, in our tests, the user experience is not diminished in the least by the difference and the ksplashx option remains and in fact is, in Plasma Desktop 4.8, still the default.

Just as with the lock screen changes, this gives us the ability to deliver visuals that are more beautiful, more flexible and easier to change. The start up splash in Plasma Active uses this new splash screen facility and it looks beautiful. The ability to add animations and position the images and other information on screen completely freely really opens up the field here.

Right now, we do not have documentation on Techbase for this new addition but if one looks in kde-workspace/ksplash/ksplashqml/themes it becomes very apparent. Writing a small tutorial would be an awesome way to give something back to the community that doesn't involve coding. Hint, hint ;)

Input Method Panel

The KDE Input Method Panel, aka "kimpanel", got a complete and much needed rewrite for the 4.8 release. It has a nice separation between visualization and logic, using the standard Plasma approach of Applet and DataEngine. It resolves many long-standing issues, has simpler code and a very active maintainer in Weng Xuetian.

On-screen Keyboard

Speaking of input, the on-screen keyboard has seen numerous improvements in terms of bug fixes and performance, some of which take performance from "sort of acceptable" to "so fast you don't notice its doing something anymore". There isn't much here that is user visible other than "it works better". For the next release, we plan to offer support for integrated layout switching, quick access to accented characters and more X11 independence.

Taskbars, Docks and libtaskmanager

We are in the middle of merging the improvements to libtaskmanager from Craig Drummond's Icon Tasks Plasmoid. Icon Tasks itself will end up in the Plasma Addons repository (kdeplasma-addons) as well. This means much improved support for launchers, nicer context menus, a few new features and a number of bug fixes. It's a very significant effort as Craig's fork was quite large: 2639 lines covering 30 files. Seeing as the library is only 6,300 LOC, that's a significant set of changes.

We also managed to track down and squash, though many heroic hours by Alex Fiestas and others, several of the last very visible bugs in the tasks widget and libtaskmanager. Things like the ghost items that would sometimes appear have finally been fixed once and for all. Some fixes exposed problems in Qt itself (in particular: an issue with event loop reference counting whenever inside of x11EventFilter) which we have worked around until proper fixes appear upstream.

Picture of the Day, Picture Frame

This one started quite innocently enough as a patch by Greg T who noticed that the Picture of the Day feature in the Picture Frame Plasmoid caused it to check the picture every two seconds. Wow!

While merging and testing his patch (and the next two he submitted :) a whole number of other issues jumped out at me. Picture of the Day now behaves a lot saner, only waking up at most every five minutes and changing the picture only once it's been on your system for 24 hours (making it your picture of the day, regardless of when it changes on the source server).

While working on this, I realized with a start that there was no wallpaper plugin that used this. I could hardly believe this, and so wrote one while sitting on a train. In Plasma Workspaces 4.8 you can now have a new astronomy, flickr, Wikipedia or other picture on your screen every day. Currently I am using the Wikipedia picture of the day.

Picture of the Day is plugin based, so new picture sources can be easily added. Just as with the new QtQuick splash screen, however, we don't have documentation for this. Looking in kdeplasma-addons/dataengines/potd/ should give a would-be tutorial writer everything they need, however.

This also led to cleaning up a few issues in the Picture Frame, such as not stalling on images that were deleted from disk but just skipping to the next available picture automagically.

Plasma QtComponents

This is a hugely significant addition as it means we now have a full set of QtComponents for use from QtQuick that integrates beautifully with Plasma interfaces. It is the result of Daker's highly successful Summer of Code project, which Marco mentored with patience, care and brilliance. We have also had interest and contributions from people who came by way of the Mer project.

This is a vital step towards even better looking Plasma user interfaces and the ability to step into the OpenGL-driven world of QML2 when we get there.

Documentation is being written and will be available in coming weeks.

QtQuick'd Devices Notifier

Building on the components project, a number of Plasma widgets and other UI pieces are being ported to QtQuick. The first completed one of significance that debuts in 4.8 is the devices notifier, which was part of Viranch's Summer of Code project. To the user, nothing changes except it feels smoother and looks a little nicer. It was a long, long path to get to the point that we could use QtQuick as a better-than-QGraphicsProxyWidgets replacement in Plasma .. but we're there now!

In upcoming releases we will have a new QtQuick battery widget and panel controller, among other shifts. This is part of the strategy I described at the end of last year of not distrubing Plasma Desktop or requiring that we rewrite everything all at once, all in the name of respecting our available development resources and not disrupting the user in the least while still marching towards an all-QtQuick world for Plasma Workspaces.

Control Panels in Plasmoids

By adding a X-Plasma-ConfigPlugins= list entry in the metadesktop.desktop, scripted Plasmoids can now have arbitrary control panels integrated into their settings dialog. It's a small thing, but it allowed the QtQuick devices notifier to be fully realized.

Improved Window Switcher

KWin, in its usual and amazing pace of improvement, also brings a new window switcher UI system that ... wait for it ... uses QtQuick. ;) You can read more about this great work on Martin's blog.

... and so much more

These are just some of the highlights and doesn't really cover the many performance and stability improvements that have also been worked on. Alas, already this blog entry is too long, and dinner becons as well, so I'll leave it here and follow up later with more changes in another entry.

Hopefully this already gives you all the reasons you need to try out the alpha and beta pre-releases when they become available to help us test and make Plasma Workspaces 4.8 the most stellar release yet. :)

activities

2011-10-07T12:29:00.002+01:00

Several years ago now I had a minor epiphany while doing field research in the offices of friends and work associates on how people use their computers. The ideas led to the concept of "Activities", which I originally called "Projects" (we changed the name because it was about more than just things we could call a "project").

The idea was fairly grand: you communicate to the computer what you are currently doing and it adapts to that. You would be able to teach it what it means to be doing that thing: "I use these files, talk to these people, need this network connection, want these applications ..." The teaching would happen over time as you engage in your activity, whatever it might be.

Where to start with such an idea? Well, I started simple and small. In part because I was the only one working on it at the start and so I had to eat this elephant in small bites, but also in part because I had a lot of open questions as to how to implement things. I couldn't just easily look over someone else's shoulder who was creating the same thing and see how they did it: no one else was doing this as far as I could find. That made it exciting .. but it also made it a lot more like research than development. ;)

So it was that the beginnings of Activities were as different widget layouts in Plasma Desktop. You could zoom out and see each collection of icons and widgets and switch between them. It let you, for instance, open different folders in a folderview for different projects you were working on. Some people got it right away and started using Activities. Most people didn't, and I don't blame them at all: it was very hard to communicate something that was new to me as well and which we had only the basic sketches of implementation to demonstrate.

In a few days we release Plasma Active One. I just finished up my part of the release announcement and I have to say ... it brought up a certain amazing feeling that has no name (at least none that I was taught :) inside of me. You see, Plasma Active embodies Activities.

When you start it up, you get a view of an Activity and everything in it. You can add things to it. You can connect a web site or an image to an Activity while you are viewing said site or image. Applications launched are automatically associated with the current activity. You can quickly switch between them using a great little wheely switcher thing that's a pleasure to use. Activities sit at the core of Plasma Active's tablet UI and it works wonderfully.

I've shared my tablet around at BBQs and parties I've attended in the last few months and people immediately get it and see the value. I get questions like, "This is perfect for use in our office where we work on multiple projects, could we share Activities live with other people in a meeting or while we're working from our desk?" When people respond like that after just a couple minutes of seeing and using the device, it gives me tingles. :)

It's not all Plasma Active, though. When I read Dario's blog entry on Power Management and activities I just about cried. Ok, not really, but almost. ;) Finally we were seeing very cool usages of "how to teach my computer how I live and work". I now have a "Movies" and a "Presentations" activity on my laptop which I plan to use extensively in this manner. ;)

We're nowhere near the full capabilities of Activities yet, and I know that. We have so many other things to integrate and work on, so many possibilities that we haven't even dreamed of yet on how to use them, expose them, teach them.

But after these past few years of efforts, to see the idea and concept blooming in the open like this .. damn .. what a rush! This is what I identify as the "KDE feeling". :)

On that note, I have an activity ahead of me that I rarely engage in. Someting called a "vacation". I hear they are good for you or something. I'm taking two weeks off, and I dread to think of my inbox size when I return. ;) However, I'm looking forward to a couple weeks in the sun and culture of Morocco, a place I've dreamed of visiting since I was a young adult.

See you on the other side and happy hacking!

meego.next();

2011-10-04T14:48:00.003+01:00

Henri wrote a really nice blog entry yesterday entitled "Where is the future for openness in mobile?". What he wrote spoke me quite deeply: as do may in our community, I deeply believe in the need for a truly open device stack.

As developers, we need it to be able to create on our terms.

As companies working in this space, we need the ability to innovate on our terms in a collaborative environment without creating dead-end separate silos. It simply makes the most business sense for us. (Though, admitedly, perhaps not for, say, Google ;)

As users, we need our technologies to enable freedom, not quietly rob us of it while we play Angry Birds.

To accomplish that goal we must have a community infrastructure that mirrors the end goals deeply. This is why previous efforts to do this have failed, in my opinion: while there was the stated desire (and probably real desire as well) to create something open, the path there was driven by engines that were most comfortable with closed systems and top down control.

While I was in Tampere, Finland last week I had the opportunity to meet with a diverse group of people from the MeeGo community: companies, their employees, volunteer developers, hardware hackers ... and they kept saying these same things in their own words.

Plasma Active, which is a mere five days away from its first release, has had such openness and collaboration as one of its two core principles from day one. (The other core principle has been to make beautiful things which add to and support your experiences in life; we believe this to be an important ingredient in making objects of desire and is the inspiration for Activities.) So when we watched the events around MeeGo and Tizen unfold, it just reinforced in us all that we felt about other options out there: if we want an open platform, we're going to have to make it.

The question, of course, is who is "we"?

There is a large and vibrant community of driven, intelligent and experience people and companies that had gathered around MeeGo. As Henri's blog entry noted, there is a forward migration to Mer as an open, collaboration-driven platform. We'd like to support that.

We also feel, however, that some of the necessary parts won't magically occur on their own. That includes purposeful vision, clear goals, community growth and interfaces for interested companies. In addition, we'd like to bring our open UX work, along with that of others doing similar things, to the forefront here. So where do we begin?

To help determine that, we've scheduled to meetings over the next two days in #mer on irc.freenode.net. The first will be tomorrow (Wednesday) at 13:00 UTC and the second on Thursday at 18:00 UTC. Hopefully if you can't make the first, you can make the second one. Individuals and companies around Plasma Active will be there to start the process of discovering how we can integrate our efforts and foster the community processes around it that will lead to success. We announced the meetings with an open invitation on the meego-dev, meego-community and active mailing lists today.

I hope to see all the MeeGo-heads and Mer-folk (I had to say it ... ;) there so we can get to the business of building significant momentum together.

plasma active workshop wrapup

2011-09-23T10:30:00.002+01:00

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 :)

plasma active workshop: day 0

2011-09-19T10:28:00.003+01:00

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.

easy building with git split modules

2011-09-08T11:25:00.005+01:00

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! :)

the on-screen keyboard

2011-09-04T10:00:00.000+01:00

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. :)

more on Active strategy

2011-09-03T10:00:00.000+01:00

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.

Plasma Active entering beta

2011-09-02T13:16:00.002+01:00

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. :)

tracking what happens in your DataEngine

2011-09-01T18:33:00.002+01:00

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.

planet kde chinese update

2011-08-31T11:55:00.002+01:00

Things move fast once they are moving. It was only 2 days ago that I announced the existence of Chinese language blogs on Planet KDE. Since then, several things have occurred:

There are now a total of six Chinese language blogs being agregated on Planet KDE 中文!

The community decided to change the url from "ch" to "zh" so you can now access it via http://zh.planetkde.org or http://planetkde.org/zh

Franklin Weng, who is also a KDE translator, is now the maintainer of Planet KDE 中文. He has been reaching out to as many of the Chinese speaking communities as he can to find relevant and interesting blogs by KDE contributors that are written in either simplified or traditional Chinese. His enthusiasm and efforts will ensure that Planet KDE 中文 prospers under his care.

What next? Well, we are still looking for more Chinese language bloggers to add and we need to spread the word that Planet KDE 中文 exists so that people may benefit from it. :)

chinese language blogs on planet kde

2011-08-29T12:05:00.003+01:00

On my recent visit to Taipei, I worked with some of the local KDE community members to identify ways in which we could help support both the various Chinese-speaking KDE communities as well as the local KDE community in Taiwan. One of the things we identified was getting the same level of support and exposure for Chinese language community content, such as blogs, as we do for other language groups.

Upon arriving back home, I set about adding a Chinese language section to our blog aggregator, Planet KDE. With the support of our sysadmin team, this went live today and you can now read Chinese language KDE blogs from Planet KDE.

We only have one blog on their right now, but it's a great asset to the Chinese KDE community: it contains primarily translations of KDE related news and information found elsewhere. With your help, we can add more blogs and original content. How? Well, if you have a Chinese language blog that is KDE related, or know of one, please let me know and I will make sure it is added to the new Planet KDE area for Chinese language blogs.

My next step is to remove myself from this role and pass on maintenance of the Chinese language blogs to someone in the Chinese KDE community. Seeing as I don't speak/read Chinese nor live in a relevant region, I am a language and geographic barrier that we don't need here. :)

This is, of course, only the first of many steps towards increasing the support for our friends in Asia and elsewhere who contribute to, use and generally appreciate KDE and feel most comfortable communicating in Chinese. It's also a step in helping bring together the local Taiwanese KDE community by providing more visibility for them to each other. We have more planned, but all great journeys start with such small steps.

collect.kde.org is live!

2011-08-29T10:49:00.003+01:00

A quick update to my previous posting about collect.kde.org during the Berlin Desktop summit is in order for two reasons.

First, collect.kde.org is now a fully functional battle station .. er .. Synchrotron installation. Things that are added to the shared sources repository will automatically appear there. As an application (or application add-on) developer, you can quickly and easily set up your own provider and start populating it with items. It takes all of about 2 minutes to set it up. How to do this is documented in the Quick Start section of the README.

Second, we now have three applications using it: KDevelop for API documentation downloads, the share plasmoid for updates to the Javascript backends (covering the case where the web API for any of the services change) and Dr. Konqi (so that its configuration controls to help users generate useful backtraces can be updated over time). Just as exciting, it looks like at least one (non-KDE) application may end up hosting their own Synchrotron instance to service their needs. Cool!

So If your app has data that you wish to control the updates to (as opposed to user-contributed and -curated content, which is better done through opendesktop.org), you may wish to consider using collect.kde.org.

I'm collecting questions developers have as they start using collect.kde.org and will be writing a Techbase page in the future that provides a clear tutorial that covers both the basics and these questions. Don't let the lack of that tutorial stop you though, check out the README and get started.

system tray icon hiding

2011-08-29T10:13:00.002+01:00

To all application developers who create a KStatusNotifierItem in their application, please consider making your icon as friendly to the user through automatic hiding as possible. The system tray is a very valuable bit of real estate and unless your application's entry there is actually useful to the user, it ought to be hidden. KStatusNotifierItem allows you to set the status of your icon to Passive, Active or NeedsAttention. Setting it to Passive will automatically signal the system tray to hide the icon automatically. The user may always override this in the settings, so if they always want it shown .. they can!

Of course, what is the meaning of "useful"? That's the trick here. We're trying to make the system tray as "quiet" as possible for the user so that the entries that do show up are a good signal to the user that they actually matter.

So now the battery icon goes away when the system is plugged in and the battery is at 100% charge and the information icon (jobs and announcements) goes away when it is empty. I've patched a few other applications such a konversation and ktorrent to also go Passive when they aren't actively downloading or there are no message alerts (respectively).

If your application doesn't have something to actually tell the user: set the icon to Passive. The system tray icon is not a replacement for the task bar. (In fact, in 4.8 it is quite likely that application entries will appear in the tasks widget instead of the system tray by default!) There is an exception (as usual ;) which is applications which provide user interface in their system tray entry, such as media players. We generally discourage such usage, but it can make sense in specific cases. Over time, we'd like to see these uses also phased out in favour of merging those interfaces with the relevant UI; media player controls and the volume control, for instance, or instant messaging accesses and a proper presence Plasmoid.

COSCUP and Taiwan

2011-08-26T15:12:00.003+01:00

I arrived back home from the Conference for Open Source Coders, Users and Promoters (or, more succinctly, COSCUP) yesterday. Staring at the cursor blinking in the big open text box in front of me, it's hard to know where to begin. Really, there is more than I can possibly share in a reasonable amount of space. So I'll try to summarize and keep it to the point.

First off, people would not keep their hands off the tablet running Plasma Active with the Countour user interface. Despite it being alpha software, people loved it. They got the idea of the four essential concepts right away: Activities, Recommendations, Peek (at your running applications) and Launch. Several people asked how they could get one. They also provided me with tons of valuable feedback, some of which we'd already heard before and had on our worklist and others that were new to me. This is great!

The presentations were varied and several were excellent. Even though most were (of course :) in Chinese, many of the slides were in English so I could semi-follow along. The really telling thing, however, was the audience: rooms were full to standing-room-only and the audience was quite evidently fully engaged. The topics were mostly about mobile, server, web and embedded. This is where the attention was, even though there was a laptop in front of nearly individual. We are taking the desktop for granted now (not a bad thing, but a natural stage) and looking into the near future that is around us. We need to keep giving people a great desktop experience, and move forward into the new form factors as well.

I also noticed a few people with tablets and keyboards, using them as lightweight laptops, if in two pieces, when seated at a table. It's another tween-category in the device spectrum, which is going through a fantastic time of differentiation, though it will almost certainly be followed by a period of post-experimentation consolidation.

I met with a number of companies while I was in Taipei, both at COSCUP as well as outside of it. I have a lot of follow up work to do, but having a tablet UI which is a truly open ecosystem and which looks as good as this already does gets us attention and interest. That is shares so much code with the Desktop and Netbook interfaces also fascinates people. There is great potential in these relationship building efforts for KDE in terms of increased support and investment.

I also continued talks started by Armijn about hosting a KDE event in Taipei, possibly alongside COSCUP, next year. Many people affirmed their commitment to help us achieve this, and while we're still working on the details (and will be for a few months yet), I'm confident that we will pull this off. It will be beyond amazing to follow the successes of KDE India in Asia (an example I used many times with people in the local KDE community in Taipei) with a strong KDE event next year! I was highly impressed with the level and efficiency of organization at COSCUP: it's a large event, and it ran very smoothly with a lot of very nice features like on-site lunches (and even some dinners!). The people who can make a KDE event in Taipei a roaring success are there, and now we need to do our part in making sure it comes to fruition.

I also spent time working with people in the area on how to bolster the KDE community there. We held a really nice BoF at the end of the first day (where people kept playing with the tablet some more ;) and, among other things, out of that came the decision to set up a Chinese language section on Planet KDE where people can blog in Chinese. This should be appearing in the very near future and I'll post a follow-up announcement when it goes live.

A few days after COSCUP, I gave a presentation for the local Linux User's Group which was well attended. It was held in the upper floor of a lovely restaurant. People ate dinner together first and then out came the projector and the presentation started. We talked about KDE for a couple of hours, most spent in the Q&A period. We looked at KDE from a community perspective as well as a technological one and examined KDE's past, present and future. I even fixed a small problem live on the projector that we ran into during one particular question and when the `git push` completed successfully after testing the fix, everyone aplauded. That was a very nice experience. Again, people played a lot with the Plasma Active tablet. :)

While I did a lot of working in the 5 days I was there, I did manage to find time to experience the city itself. It is a complex city full of flavor and texture. It was hot and sticky (and rained a few times most intensley), the food was amazing and the people were even better. I exchanged gifts with a few of the people there and, I like to think, made some great new friends that I hope to see again soon. I also took a few hours before my flight left on the last day to visit the National Palace Museum, which has an astounding collection of diplomatic documents, jade, pottery and bronze work. I managed to see a few other sights at night after the business of the given day was over. However, I also learned that it is impossible to really experience this city in such a short time. I passed more gorgeous temples, more markets, more interesting looking shops, more restaurants eminating curious and wonderful odors and more interesting sights than I cared to .. I wish I had had more time.

My take-aways from this trip are, in short:

We have to get the word out more about our direction on tablets, both within the KDE community and outside of it. Not enough people are aware of what we've been cooking up, and it's time they did. This is a unique offering in the F/OSS space, and compliments our desktop efforts beautifully.

We also need to work on our HTML5 and Android compatibility stories, starting with deciding what they are.

I have a lot of follow-up work to do in the coming weeks with people I met. The reach of KDE in Taiwan is in its infancy, and we can improve that situation with attention and outreach.

I have a lot of business focused writing to do to support our new efforts

A KDE event in Taipei next year will be wildly successful if we make it happen (and it looks like we can and will)

I need to go back ;)

kde email list unsubs

2011-08-24T15:21:00.002+01:00

If you, like me, are the administrator of one or more KDE emai lists, you may have recevied a small (or large) flood of emails a few hours ago letting you know that various addresses had been automatically unsubscribed from your list. When I received my share of these emails I grew concerned: why were 80 addresses suddenly axed from the plasma-devel list?

Well, fear and worry not. It's just our sysadmins doing what they do best: making our infrastructure better. The new mailing list server is now handling bounces correctly and if an address bounces too much then it automatically unsubs the address. The mailing list setup on the old and venerable ktown server wasn't doing this, and so stale addresses had piled up over time.

I was relieved to find out that's all it was when I asked in #kde-sysadmin on irc. Whew! :)

COSCUP day 1

2011-08-20T17:37:00.003+01:00

I arrived in Taipei at a bit past nine in the evening yesterday. I had started out at 19:30 CEST the day before, flying through my least favourite airport in Europe (Heathrow), on to Hong Kong and finally here. I got a good five hours sleep after doing the usual evening-before prep work, woke up, showered and had breakfast with John Corbett in the hotel cafe. Then it was off to COSCUP by train.

The metro system here is modern and efficient. I bought a metro card and filled it with NT$100. At the last station we were approached by another conference goer: a Finn who now lives in Taipei and has a company that specializes in MeeGo. They also have offices in Tampere, where I'll be next month. What a small world!

My presentation on KDE's Plasma Active was very well received and the live demo seemed to impress. Many people came up after to ask questions and discuss. I exchange business cards with numerous of these people and with some arranged to talk at greater length after the sessions. There is a real appetite for a truly Free and Open device OS right now, due a variety of factors, and we're bringing exactly that to the table.

Even though we're only in alpha and just starting the polishing and stabilization phase of development for our first release of Plasma Active with Contour, something I made clear to those in attendance, the ExoPC demos definitely made ripples, and perhaps even a few waves.

After meeting with Jos and the OpenSuse guys here in town and discussing how we can arrange for a KDE event in Taipei next year with organizers of this year's event, I wrapped up the day with an extended BoF with KDE contributors and enthusiasts. A couple of translators along with some coders and enthusiastic users attended. We ate pizza and talked about KDE. They asked questions and I did my best to answer them accurately and to the point. I did a little KDE trivia quiz and handed out some Swiss delights (chocolates, cheese) to people who came up with the best answers. Then we huddled around my WeTab and explored Contour together.

I got back to the hotel sometime after nine, twenty four hours (and a bit) after I had first arrived in the country. I could feel the energy the day had taken out of me, but I also felt elated at the progress that was made and the wonderful people I had the opportunity to meet.

I decided to reward myself by wandering down to a night market in the area where I hunted about the various stalls for some food. I had a pancake wrap thing that was quite delicious but it wasn't for a few hundred more meters until I struck true gold: a small wheeled cart parked next to a wok half filled with oil. An old wisened woman stood behind the cart which was filled with trays holding various ingredients: tempura vegetables (some of which I'm not sure I know exactly what they were..), mushrooms, tofus and seafood. I picked out three of the most interesting looking vegetables, which she measured out and then dropped into the hot oil. They bubbled away for a minute or so and then she drained them and coated them in a wonderful spicy powder.

I picked up a Taiwan Beer, to see if it is as disappointing as Armijn keeps telling me it is ;) , and wandered on home in the wet heat of the night and digging into this huge bag of wonderful, deep fried, spicy vegetable wonderness. I'm back at the hotel, still have some left and just cracked open the beer to calm the riot in my mouth.

What an excellent end to a first day here. I get up about six hours to do it all over again tomorrow. I can't wait.

the circle is small

2011-08-17T11:09:00.002+01:00

Yesterday I added virtual keyboard support to konsole: select the text area and the software keyboard, if any, appears. This frees me from having to lug around a keyboard with my tablet just to do command line stuff. It was a small patch, nothing fancy, really. Took me maybe 10 minutes.

Today I `zypper dup`d my tablet to get the latest packages and to my wonderment there was a new konsole package. After it installed, I started up konsole and sure enough: on screen keyboard delight!

Less than 24 hours from development to deployment: I wrote and tested it on my laptop yesterday, this morning it is on my tablet which only has packages (to keep it semi-sane for demos and user testing). What more could a developer dream for?

Suse's OBS, which we are using for these things, absolutely rocks. And with this tool enabling their passion, Sebastian and the other Plasma Active packagers are quite simply rocking the house and helping keep the development-deployment-testing-feedback circle small and tight.

Beautiful.

Taiwan, or: no rest for the weary

2011-08-17T10:38:00.002+01:00

Tomorrow evening I leave to participate in the Conference for Open Source Coders, Users and Promoters, or COSCUP, in Teipei, Taiwan. I will be presenting on Plasma Active and helping spread the KDE and Qt story (and love!) while I am there.

My presentation will be in the second conference room at 11:30 on the first day of the conference, the 20th. I will be laying out the concepts behind Plasma Active, the four elements of the Contour shell and wrapping up with a live demo. All in 30 minutes. It has become an exercise in cutting away everything that can be, but no more, in a drive for clarity with impact. :)

There will be a meet-up of KDE enthusiasts on the evening of the 20th in form of a KDE User's BoF which I will be attending. If you are in the area and are a fan of KDE or just interested in what we do, please join us!

I'll also be around for a few extra days meeting with various people, though I do still have some spaces in my schedule which I plan to fill as I meet people at the conference.

A big thank-you to KDE e.V. for their support in this endeavour, to COSCUP for the opportunity to present and to Armijn for helping make so many vital connections in all this.

every new beginning

2011-08-17T10:20:00.002+01:00

The Berlin Desktop Summit was a roaring success from my experience at it. We, as they say, pushed forward on all fronts: cross-project collaboration, KDE Frameworks (the next major version of KDE's libraries and runtime requirements), application development and, of course near to my heart, our Plasma workspaces.

We had a lot of opportunity to work on Plasma Active things, including a BoF in which we combed over the various elements in the Contour shell and beyond to come up with a very nice set of issues that need working on. This is critical as we've moved past feature addition in the UI and are now focussing on polishing for the next ~2 months which will lead up to the release of Plasma Active One.

This is a perfect time to get involved as a developer, especially as a few hundred more of those who attended the Desktop Summit have ExoPC devices. ;) We've built a very big wiki page housing our task list and will be triaging this list to something more workable than .. well .. a giant wiki page. So there is lots to do and much of it is a "low hanging fruit", which is usually the sort of thing those just getting started find easiest and most rewarding to work on. If you'd like to join us and take on one of the open tasks, visit us in #active on irc or send an email to active at kde.org.

Of course, with all the activity around Active, I got the innevitable complaints from some that we weren't paying enough attention to the desktop. I found this personally a little frustrating for a number of reasons that can be best summarized as "that doesn't match reality".

I fixed a number of bugs while at the Desktop Summit, all of them for Plasma Desktop. I've personally spent more time on Plasma Desktop issues than Plasma Active so that our desktop shell does not bit rot. I'd love more hands helping there, and we do get regular patch submissions from new faces fairly regularly. In addition, I've been putting significant efforts into libplasma2, which is what underpins all of our shells, particularly Plasma Desktop.

All keep in mind that we've worked on the desktop and netbook shells over the last ~four years. We've spent less than four months now with some of our resources (not all!) on Active. This is not a zero-sum game, either: Plasma Active has brought us new resources we would not have had without it, such as our interaction designer Fania who comes to us by way of Basyskom thanks to Eva's interest and involvement.

Moreover, a good portion of the work going into Plasma Active also helps out the other workspace shells due to the amount of infrastructure and code shared between the shells. This is part and parcel of the design of Plasma: a way to affordably create purpose-specific shells through code and design reuse.

Finally, ignoring the device space would be eventual suicide. The future absolutely contains the desktop (sales are still growing for desktop and laptops, by-the-by), but it will be augmented by devices which people will increasingly expect to work together. Their choices in one category will (and already do) affect their choices for other form factors: my choice in tablet may affect my choice in laptop.

On top of all the logical argumentation, there's also the fact that it's fun and enjoyable work. It's important to me to keep our Plasma project injected with joy and fun. It keeps people motivated and moving, it gives life greater meaning, it makes it more worth doing.

Since I've wandered this far off topic, I may as well say something that often comes into my mind while working with my fellow Plasmaters: we feel like much more than just a team of people banging out code next to one another; we're good friends and supports, an understanding and gracious support for all our dreams and efforts. It's not often in life one gets to be a part of something like that, and I am quite grateful to be a part of it.

Getting Plasma Active on your tablet

2011-08-11T17:56:00.003+01:00

Want to get Plasma Active on your tablet device? We'd like to help you.

Join us on IRC in ~~#plasma-active~~ #active on Tuesday, ~~July~~ August 16 at 14:00 UTC or Friday, ~~July~~ August 19 at 12:00 UTC and we will hook up with a choice of operating system that gets you with Plasma Active on your device ready to use and ready to contribute.

See you then!

Update: That's what I get for pounding out a last minute entry on the way out of the appartment. Yes, it is August (not July) and #active (not #plasma-active) .. :)

collect.kde.org

2011-08-11T17:42:00.002+01:00

I am about to leave Berlin to go back home for almost an entire week before heading off agian to Taiwan. While visiting wiht my good friends Marco and Sebas over beer I finished installing Synchrotron on the server the amazing (and award winning!) KDE sys admin team allocated it for.

Synchrotron is a simple way to offer Open Collaboration Services on top of a git repository. You commit to the git repository and in a few minutes time (configurable) Synchrotron will add it to the OCS service. Plasma will be using this to ensure that we can update Javascript addons on the fly. This is most important when online services change, such as how the BBC UK Met weather service changes the other year. KDevelop will be using it to offer single click downloads of API documentation.

There is a lot of ways that Synchrotron could be made even beter, such as internationalization based on HTTP requests or supporting multiple git repositories for the sources.

In any case, for KDE software: if you have an application that could use a way to push new or updated data or content (Javascript, documents, data, etc.) you can put your data into the synchrotron-sources repository and they will magically show up via OCS ready for integration with your application's GUI using the KNewStuff library. Let me know if you need any help getting started. :)

This is a very nice way to end my time here at the amazingly productive Berlin Desktop Summit. I'm leaving with a smile on my face.

Oh, and did I mention that we fixed (or at least we're 99% sure it's fixed) the bug in the taskbar which causes blank spaces to show up when using "Only show windows on the current desktop"? Turns out it was also possible to duplicate with other similar "Only show ..." features. Thanks to Alex Fiestas for pushing on me to fix it. It's one of the half dozen or so annoyances that I fixed, added to the innumerable ones others fixed, in KDE software while here at Berlin Desktop Summit.

All while we move forward with Frameworks 5.0. All while Plasma Active is looking better than ever on hardware like the ExoPC Intel gave out the other day: it took one evening to install it and work out kinks to get it to an easily usable and demoable state.

This is an amazingly exciting moment in our community. 2012 here we come!

Important Announcement Coming Today at Desktop Summit

2011-08-07T09:51:00.002+01:00

Today at 17:30 there is a panel presentation here at Berlin Desktop Summit that is unfortunately titled "KDE Platform 4 Roadmap" and the schedule says I'm presenting it. This was submitted prior to the Platform 11 meeting in Randa so it could make the speaking schedule here at the Desktop Summit. At the time I didn't know what precisely we'd decide on at Platform 11 .. and the title reflects that.

What I did know was that we would want to communicate the results (whatever they would be) from Platform 11. That is in fact what we will be doing. Better yet, I will be joined by David Faure, Kevin Ottens and Stephen Kelly in doing so.

Interestingly, however, the presentation will not be about KDE Platform 4. It will be about KDE Frameworks 5.0.

Yes, you read that right. Coming out of Platform 11, we have a roadmap for the next major releast of KDE's libraries and runtime requirements. The emphasis is on modularity, dependency clarity / simplification and increasing quality to the next level. Our goal is to give us better tools for desktop app development, give our KDE mobile projects a leg up and make KDE's libraries something that Qt developers can and will use.

There are many steps to get there: reexamining what is in KDE's libraries that ought to be in Qt proper; dividing up the libraries along the lines of the new organizational charts we've drawn up at Platform 11 and subsequently presented on kde-core-devel, etc.

We do not wish to introduce anything highly disruptive, however. As with Qt5, we want this to be a mostly-under-the-hood set of work. We will be taking this opportunity to adopt some new technologies behind the scenes to increase interoperability, such as introducing a Secret Service implementation that can phase out KWallet. (Yes, we have automated migration code ...)

Application development will not be pausing as we do this: releases every six months of application improvements will continue based on the 4.x codebase. When Frameworks gets to the point where it is ready for serious banging on, then we will start repurposing our highlight applications to the new codebase. We don't want application development to be held up by the library development, and we don't want the library development to create much, if any, need for "porting" application code. We want "just recompile and test" to be the common case, with whatever changes do become necessary to be of the simple and even automatable sort.

If this sounds rather different from how we approached 4.0, that's because it is. The requirements, needs and context for this release are utterly different. We're after evolutionary improvement and broadening our developer ecosystem, and our plans therefore need to, and in our opinion do, reflect that.

We will be communicating these developments over the next months in more official and comprehensive means than this personal blog entry written while I'm sitting in presentations at the Desktop Summit. ;) However, I wanted to make sure people knew what was coming in our presentation and hopefully motivate people to therefore show up and participate!

So one more time: Today at 17:30 in our panel discussion in Kinosaal room at the Desktop Summit we will be discussing the plans for Frameworks 5.0 in detail, taking questions and entertaining the thoughts shared by those who come. Be one of those people! :)

more minimalist panels, off to berlin

2011-08-04T11:16:00.003+01:00

Yesterday I cleaned up a few bugs in the system tray, particularly with how it was refusing to resize smaller after icons would automatically hide. In the process I cleaned up a few other issues I noticed; e.g. I made the notifications icon autohide by default and got rid of the vertical line which was looking more and more vestigal as the rest of the chrome around it had been ripped away. The bug fixes will be in 4.7.1, some of the visual changes will only be in 4.8.

This follows rather nicely in the steps of work we did for the Plasma Desktop 4.7 relesae in making things a bit cleaner and easier to get around. Yes, we added a button for the activity manager to expose that more, but we cleared up a number of other things. In fact, that's what prompted me to take ten minutes out of my day today to write this blog: I read a user comment lamenting virtual desktops and how they don't like to use them. This was a problem for them due to some other desktop environments being increasingly tied to virtual desktops as part of critical workflow. Which reminded me of a little thing we did for 4.7: if you have only one virtual desktop (or, put another way: you don't use them), then pager in the panel disappears. If you change your mind later and bump the number of virtual desktops up, the pager reappears. This elminates the oddness of having a pager with just one virtual desktop on your panel.

Also related to the pager is some work Martin put into KWin recently: starting in 4.8 KWin will define the layout of the virtual desktops. Previously, and as is documented in the NETWM spec, this is up to the pager. This made sense back then: everyone had a pager, and probably only one, and the window manager didn't do nearly as much with window presentation as modern compositing window managers do. Today, it makes little sense. You can have multiple pagers and the window manager exposes virtual desktops in all sorts of ways through desktop effects. So, we've moved that functionality to the window manager, which makes things simpler and more consistent.

One other small thing we did in 4.7 on the panel is make the default launchers in the taskbar for file manager and web browser follow your prefered applications as set in the system settings. Which means we have one configuration that we ship, but it matches what you want. Including if you change your mind later. Since they share space intelligently with the tasks, it means less space used: when the app is running, the launcher goes away. (Btw, a bug in 4.7.0 around that feature has been fixed for 4.7.1, so if that isn't working for you properly, the fix is just a patch level update away.)

Merging application system tray icons with task entries is only on the roadmap for 4.8. Yes, I know: FINALLY! :) All of these efforts to streamline and simplify are making for a more polished result. It isn't all just trimming and rearranging, however: I plan on adding Share Like Connect to the panel by default as well. We will be working on these things in various BoFs and hacking rooms over the next week in Berlin.

Speaking of which .. I've finished packing for the Berlin Desktop Summit and am working on my presentation now until I head down to Zürich HB to board the night train. I have my football boots, a WeTab, a PandaBoard, collections of various cables, writing books and the necessary amount of clothing for the week there. I can't wait to see everyone there, listen to the talks, collaborate with people that I only get to see in person every year or two, hack until my fingers bleed and my body demands sleep and, of course, karaoke in Alexanderplatz. It's going to be amazing.

wetabirific

2011-08-02T13:29:00.002+01:00

Last week, I received a WeTab, hansomely provided into my care by the folks at OpenSLX so that I can track Plasma Active development on that device. Getting it set up was quite straight forward, particularly as the one I received already had firmware that supported booting from external media. Perfect. After a few small glitches related to the release of Plasma Workspaces 4.7, which caused some of the repositories to move around for us, I got the thing up and running. There are still some rough edges, and I'm hoping Sebastian and I can huddle together during the upcoming Berlin Desktop Summit to file some of them off as he probably currently has more experience with the WeTab and Plasma Active than anyone else.

One result of having the WeTab in my hands is that I've been able to start collecting a list of tasks that need attention between now and the 1.0 release of Contour. It's also giving me great hands-on opportunities with Plasma Active on a device of this form factor.

The WeTab itself has more than enough horsepower to drive the system and the battery life isn't too bad either. What things I do find odd are the result of some understandable design trade-offs. For instance, the screen size is huuuge compared to other mainstream tablets. This makes it awesome for reading books, watching videos and other types of media consumption. It also makes it rather less portable than the 7" tablets out there, to say the least, and it also costs on battery life (which is still in the satisfactory range, however). It's intel based and not really what I'd call "perfect for tablets" hardware: it has a cooling fan in it for instance.

All the quirks aside, it's a terrific platform for developing and testing Plasma Active with and I think it hints at some really interesting potential use cases. The screen is big enough and high quality enough to be used as a desktop. One our first stable release of Plasma Active is out, I want to explore the interesting possibility of "mult-form-factor" devices with it. Namely, I'd like to be able to put it in a cradle on my desktop with a wireless keyboard and mouse (which I already have and which work great with it as expected) and use it with Plasma Desktop. When I remove it from the desk and take it with me to the, say, the living room or off on a train ride, I'd like it to switch seamlessly to the touch-friendly Plasma Tablet interface with Contour. While the WeTab has a built-in screen that would be suitable for both, smaller tablets and even smaller pocketable devices (e.g. phones) don't and that then brings in the idea of a device that can drive a second larger display when docked and show Plasma Desktop on that external display.

There are already a couple of devices on the market that have experimented with this "mobile when you take it with you, a desktop experience when you dock it" idea, though to my knowledge none have yet really taken off. However, as tablets continue to improve both power consumption and compute muscle, I wouldn't be surprised if there's a sizeable market of people who would prefer to have just one computer that can switch between modes.

For now, however, I'm focussed on detailing what is left to do to make Plasma Active ready for release. I'll be bringing my list with me to the Berlin Desktop Summit and once we've BoF'd on it, I'll share the tasks, particularly the "low hanging fruit", so that it will not only be documented but so that people who would like to get involved have easy and well-defined entry points into KDE's foray into mobile.

Once again, a big "thank you!" to OpenSLX for their belief in this project and for putting their support behind it with time, effort and investment.

new Plasma Active repos

2011-08-01T15:33:00.002+01:00

If you are having issues with software updates with Plasma Active, the reason is that the repositories have changed around a bit with the release of Plasma Workspaces 4.7. Such is life in a pre-release project of this scope. We've documented the new repositories on the wiki in the Repository Setup section.

For quick reference, if you already have an installation, do the following:

zypper rr kusc
zypper rr plasma-active
zypper addrepo --refresh http://download.opensuse.org/repositories/KDE:/Release:/47/openSUSE_11.4 kr47
zypper addrepo --refresh http://download.opensuse.org/repositories/KDE:/Active/openSUSE_11.4/ plasma-active
zypper mr --priority 90 plasma-active
zypper dup

Things should be back to good again after that.

BDS: a focus on leadership

2011-08-01T15:14:00.002+01:00

You may have noticed in my last blog entry on Plasma content at the Berlin Desktop Summit (BDS) that I'm not giving a Plasma-related presentation. I'm helping with the BoFs, yes, but no Plasma related presentation in sight from me. What gives?

Well, the presentation schedule was highly oversubscribed this year, which is a good thing: it shows there is a high degree of interest in BDS and allowed the program committee to pick high quality presentations for the program. Knowing this was the case, and since we already have several others who will be presenting great talks on Plasma and related technology, I decided to submit a presentation on a different topic ... one that I felt needed attention but which gets far too little.

That topic is leadership. There is a lot of mythology and misinformation around the idea of leadership in Free software. (I would assert: in the broader world as well.)

For instance, leadership is not the same as community management, which is a related topic that probably recieves more than its useful share of coverage these days, driven by the number of community managers we have in Free software circles and that their job is communication focused to begin with.

Leadership is not something one is either born with or without. It is a set of skills that nearly anyone can learn. In fact, they can be learned to the point where they can be usefully applied without dedicating one's life to the topic of leadership. This means that every Free software project can end up with effective leadership.

Leadership is also not relegated to the two most popular archetypes in Free software: the (benevolent) dictator and the charismatic individual. These styles of leadership can and do work (with their own challenges, of course), but are more difficult to achieve for many and are also often liabilities in the wrong circumstances.

So it is that many of our communities and teams drift without clear leadership. For small projects, either in terms of team size or project scope, this is not a big issue and even without identifiable leadership such teams can and do thrive. However, more and more of our projects have crossed over that critical threshhold where leadership becomes a necessity, and without it they end up losing direction, underachieving, becoming contentious and even failing.

Given that leadership is learnable and can be easily put into practice, this is a shame. This was my motivation for submitting a talk on leadership. I will be presenting on one style of leadership, which I call "Navigators and Explorers", which I feel anyone in our community can easily pick up and have great success with. My goal is to bring down some of the misconceptions around leadership and hopefully describe an achievable, positive path that those who attend may choose to travel down with the goal of becoming effective leaders themselves.

If you are in a Free software project that could use leadership but lacks it, if you are in a project that does have leadership but which is increasingly disfunctional, if you are just interested in the idea of leadership in general, I invite you to join me for half an hour on Day 1 in the Audimax at 14:40 for an exploration of the topic.

I hope to see you there :)

shout out to dolphin

2011-08-01T13:56:00.003+01:00

Peter Penz blogged this morning about the new views in Dolphin, dubbed "Dolphin 2.0". The big push: speed. The code is now in master, so I figured I should try it out and see what this very new code can do. I expected regressions and bugs given that this is the first drop of a huge bunch of code, but was hoping for the performance improvements Peter was talking about.

It just so happens that less than two weeks ago I did some rough measurements of file listing performance in Dolphin (and Konqueror; they share the code for this) after reading a posting about how bad file listing times in popular Linux file managers were. The writer had asserted that unlike say, on Microsoft Windows where large directories list almost instantly, both KDE's and GNOME's file managers were very slow on directories with a lot of entries.

Indeed, with previews on Dolphin would take up to 15 seconds to list directories with 3000-5000 entries in them, as /usr/bin and /usr/lib on my laptop do. Ugh. Certainly not great.

After pulling the new code from git and trying it out: I'm now getting between 1 and 2 second load times for these same directories. That means the difference between horrifically unusable and beautiful. It also means that Dolphin and Konqueror are now faster at listing directories than the file dialog, which now takes about twice as long on these larger directories.

Peter: my hat is off to you!

There are some regressions in the current code drop: no rubber banding, clicking on white space then release on an icon will activate it, no drag and drop, no icon overlays, scrolling with the mouse wheel or track pad (I die a little inside without my two-finger scrolling :) is very slow. So if you go to use it now, expect some steps backwards in the functionality department, but these should all be resolved before 4.8 comes out with this new view engine.

Also important is that Peter paid a lot of attention to making the code much easier for people to understand and contribute to. So if things like "awesomely faster and clearer code" turn you on and you'd like to help make KDE's filemanager rock like Freddy Mercury with a mic in his hands, now is a perfect opportunity to get in there.

Plasma at BDS: AC/DC!

2011-07-30T21:44:00.003+01:00

We have a full schedule prepared for Plasma Workspace related topics at BDS, and we invite you all to join us. What will be covering? Active, Contour, Desktop and Community. Yep .. AC/DC. ;)

During the presentation tracks, we have the following talks lined up:

Compositing after X - KWin on the Road to Wayland, Day 1, 14:00 in RM2002 with Martin Gräßlin. Supporting OpenGL ES in Plasma Workspaces 4.7 was only the first step for KWin in a longer journey that has a clear vision for where we need to go. KWin is going through a process of careful modularization and is shipping with profiles for different form factors. The end goal, however, is to drive towards the heir apparant to x.org on the Free software stack: Wayland. Come to this presentation to see just how far KWin has come on this path, what the migration path towards Wayland will probably look like for us and why we're taking this path.

Conquering the device spectrum, Day 2, 9:40 in Kinosaal, with Sebastian Kügler. This talk will be covering Plasma Active, including what we've accomplished and both our mid- and long-term plans. Active is a big and ambitious project, one that is hitting its goals thus far I might add, to bring more Free software in a compelling way to devices. If you are interested in how consumer electronics might marry with our traditional desktop oriented vision, this is the talk to attend.

A new activity based mobile user interface with Plasma and Nepomuk, Day 3, 10:20 in Audimax with Marco Martin and Fania Jöck. Featuring one of Plasma's primary UI developers (Marco) and Contour's primary interface designers (Fania), this presentation will be covering the new activity-centric Contour interface that is the centerpiece of the Plasma Active default user experience. It offers a unique and powerful touch-based Activities interface that makes using tablets and similar devices not just pleasant but compelling. It brings together Plasma and Nepomuk in novel ways, and they cover all the dirty details of the user interface in this talk.

Activities - the helpful Big Brother, Day 2, 14:00 in Audimax with Ivan Čukić. This presentation delves into the engines that drive Activities as presented in Contour: Nepomuk, Zeitgeist and the code glueing it together with Contour.

We also have a line-up of BoFs scheduled, too. After the presentation track, the Plasma teams as well as anyone who finds themselves interested, curious and/or inspired by the earlier presentations will come together for discussion, planning and hacking. The BoF sessions include:

Plasma Active: 9:00-11:00 on Wednesday, August 10th in room 1.204

Plasma and Wayland: 11:00-12:00 on Wednesday, August 10th in room 1.204

Plasma Desktop: TBD

The rest of the time we'll be hanging out together working on moving the various Plasma projects forward: libplasma2, Active, Contour, KWin, Plasma Desktop, etc. All are welcome to come and join us in the positive spirit of adventure and collaboration. See you there!

f/oss flash mob @ hot pasta, zürich ;)

2011-07-28T13:34:00.002+01:00

With the KDE release day fresh on our minds and having fun checking out all the new KDE software that came out yesterday, a friend emailed me suggesting that we head for beer, food and fun this evening in Zürich and invite along "whoever else wants to join in". I'm not sure he had my blog in mind when he said that, but this will teach him! ;P

So if you're a Free software fan and/or a KDE enthusiast, user, contributor or someone who would like to get involved ... come join us sometime around 19:00 at Hot Pasta. Who knows where the night will take us .. well, ok, probably into geekdom and related conversation, but that goes perfect with beer, right? :)

See you there!

4.7!

2011-07-28T00:17:00.003+01:00

Congratulations to everyone who has worked so hard over the last half year to bring 4.7 to fruition and bring another great release of world class Free software into the world. Features, performance, new platforms .. this release has a bit of everything while remaining on the solid, know-where-we-are-headed evolutionary road.

To coin a phrase, and in reference to the graphic above, it's all coming together .. and what timing! People are looking for modern, stable Free software and the KDE community is putting it out left and right. With the Big Release date, the Platform, Applications and Workspaces have their big day, this time joined by Kontact for the first time in a while.

Of course, we have a lot simmering in the pots that are still on the stove, too! While we've worked hard on the Plasma Desktop and Netbook 4.7 releases which feature several performance improvements as well as feature enhancements, not least of which are improvements to Activities and the use of OpenGL ES for window managaement, we've also been pushing Plasma Active forward relentlessly. Some times I wonder where we get all the energy from, and then I turn around, look at my team mates as well our greatful users and remember where it comes from ... :)

In one week's time I'll be boarding a train with some of the Swiss KDE Contingent as we head off on an overnight train to Berlin to take part in the Desktop Summit. It is there that we will take stock of where we are in light of this terrific release and take another bold set of steps forward.

While our users will be enjoying the "fresh off the presses" 4.7 releases, we'll already be hard at work on turning KDE Platform into KDE Frameworks, bringing Plasma Active and the whole Active movement further into the sunlight, bonding with others in our community and forging new relationships across project boundaries.

So tonight, as I sit watching the people of the Internet spread the word of 4.7, I just can't help but look forward. Viva la 4.7! Viva la git master! :)

Enjoy the release everyone, and I'll see many of you in Berlin really soon!

on a cloudy wednesday

2011-07-27T15:08:00.002+01:00

It's a cloudy day, yet again, in what is turning out to be a rather lackluster July here in Zürich. We've had hints of Summer weather, but the month has been dominated by decidedly Spring-like weather. If nothing else, it prevents me from feeling like I'm missing out by staying inside as I work away on things. When it does get nice, I have been making a point to get out in the sun to enjoy it however: I played some soccer last week and went to the Kaztensee, a pair of lakes within walking distance, yesterday in the late afternoon to enjoy some sunshine and thoughts.

Yesterday was also the day that the Ausie couch surfers went home. Aside from leaving little stuffed kangaroos all around the house for me to find (they had a great sense of humor and adventure), they also left behind some nice memories such as when one of them pulled out their laptop with a rather old version of Linux on it running Xandros with KDE. Crazy! She's now looking to upgrade to a new system but isn't too smitten with the idea of Windows and had been looking at a Mac. While here, I had my laptop out for work and what not and she shoulder-surfed a bit. The result was that she asked how she could get a computer pre-installed with Plasma Desktop on it. Just seeing what it looked like and how well it works on a commodity laptop was enough to create that desire.

When I read Alex's blog entry on some new Bluetooth features in BlueDevil, I found myself watching his screen cast and thinking: it looks so beautiful. With features like those covered in his blog entry and the amount of polishing work we're all doing as well, there are times when it is very satisfying to just sit there and look at something like a Dolphin window with the nicely blended and therefore solid feeling window title and content, the in-window notifications and information, the little animations and interface simplifications ... all while knowing the power and functionality that it contains. It's very uplifting, and it even moved me to do another round of improvements on KRunner today which included a few little bug fixes (one of which sadly will not be fixed in 4.7.0 but only 4.7.1 due to timing) and a few performance improvements.

This is where we start to get into those positive self-reinforcing cycles, or virtuous circles: one person's response begets another person's positive efforts which dominos into another person's movement which ... In an environment where critique and division is so easy to create due to the open and participatory nature of collaborative creative work (as open source is), paying attention to ensuring the virtuous circles are kept in movement is critical; and, ultimately, rewarding.

With that in mind, I've received a few requests lately to comment publicly on some turns of events in the Free software ecosystem, I assume with the expectation of a critical analysis. I've touched on the requested topics in the past, which is probably what elicited those requests, but I'm just not in the mood. In fact, I feel we have fewer positive champions than we probably need right at this moment and in the spirit of "be part of the solution" I'm going to spend more of my time doing just that.

Today, other than the hacking, I also put out a call for people to share their plans for the upcoming Berline Desktop Summit on kde-core-devel. In the last few months I've been to an inspiring kick-off event for Plasma Active, a terrific Tokamak for Plasma in general and a terrific Platform 11 where we plotted the future for KDE's shared technologies (libraries and runtimes, in other words). Others have had similar experiences this year at other developer sprints that they have attended. Berlin can be yet another stepping stone upwards for us all that builds on these recent successes and helps move KDE forward in terms of participation and achievement. Our community is in an upswing right now, so the summit comes at a perfect time. After a dip in development efforts while the community was processing a combination of winter weather, the migration to git and news from Nokia, we're back on track in terms of development pace and volume. I see many groups within the community re-assessing where they are and where they want to go, which is also a good sign of renewing energy. KDE Games just started this conversation, and when the Games are busy .. that's always a good sign. I don't know what that correlation is about, really, but there's a reasonably strong correlation there. Or maybe my monkey brain is just looking too deeply for patterns to track. :)

Speaking of patterns ... MeeGo news continues to appear, this time in reference to Tegra 2 based devices which opens a whole new category of devices that are interesting to me and I presume many others. I will be bringing at least one tablet with me to Taipei next month, but now I'm wishing I could also bring one of these nVidia powered beasts.

I've also found that having moved to rekonq motivated by a combination of QtWebKit being more than good enough these days and Firefox becoming less and less robust for my use, that I've made a small but significant change to my tab usage habits. While rekonq has a nice location bar, the sort we already take for granted in modern browsers, the web shortcuts page is set to be my "home page" and instead of typing in the start of the address of common sites I go, I just hit Alt+Home and select what I want from there. Middle clicking opens the page in a new tab, which is what motivated this change in behaviour: I can open several commonly visited sites in quick succession. Nice. :)

++performance

2011-07-22T17:13:00.003+01:00

Plasma uses a lot of files from disk, particularly when using QML and scripted Plasmoids, but also whenever something requests an image from the theme. The Package class is responsible for the former functionality and the Theme class for the latter. We already cache the results of the Theme rendering, but not the results of looking around on disk for the requested image. There is essentially no caching at all for Package: every request for a file sends it looking on disk for it.

The impact of this is relatively low thanks to caching by the operating system, but it isn't negligable. When we start thinking of smaller devices it becomes even less negligable. So while working on libplasma2 I decided something needed to be done.

This past week I started a refactoring of the Package classes so that less memory was used, both by using a smaller data structure on devices and by using an implicitly shared pointer for the private data (which improves things on all targets, including the desktop). PackageStructure went from being a data bearing class to a mutator of Package, which allows them to be properly shared between Package objects. I then added a lookup cache to Package.

The result was that the copy test (100k copies and deletions) went from ~2700ms to ~37ms, while 100k copies, file lookups and deletions went from ~3900ms to ~40ms. All while the memory footprint shrunk. Unfortunately, this isn't really backportable to libplasma1 as the changes that were required to achieve this were significant. These changes were on top of previous changes made in the refactoring of Package and PackageStructure which drew the data "closer" to Package and cut out a lot of collection creation and copying. So reasonably good wins there.

Theme also got a lookup cache, and the good news is that this is backportable and has, in fact, been cherry picked into both the 4.7 and master (will be 4.8) branches. There the results were striking as well: 100k lookups of 3 different files in the theme dropped from a little over 6 seconds to ~1/4th of a second. That's an order of magnitude improvement. Unlike with Package, overall this will end up taking a little more memory, but we're talking about a few kilobytes at most which isn't particularly significant compared to the time savings. Since Theme is used heavily and the same SVGs are asked for over and over again during a Plasma applications execution, this should have some very nice impacts at runtime.

I still haven't done the screencasts and snapshots I need to for my Share Like Connect blog entry, but I was busy today finishing this stuff up ... and attending telco or two, and doing presentation prep for next month and dealing with the construction people who put in the new decking today... so the usual distractions. :)

public transport plasmoid looking for your input

2011-07-22T12:16:00.003+01:00

The Public Transport Plasmoid is a rather useful and pretty cool tool to look up information on, as the name clearly implies, public transit in your area.

I really like the ability to quickly see route information with times and associated alerts for my home station, and with multiple instances of the Plasmoid I can keep track of several stations quite easily at a glance. The journey features are also indispensible.

Using it with Contour, which is getting support for random Plasmoids in addition to the Nepomuk-derived resources that are associated with an activity, is going to be very, very nice for someone like me who travels a fair amount: I'll end up with one Activity on my tablet per trip with all my files, contacts and even transit information agregated in one place that I can switch to with a simple thumb swipe. Oh, yeah!

A new version was released today and I noticed that the author of Public Transport has put together a set of polls asking people what they think of the UI changes in the new version, which transit systems you use it with and how you get and install it.

If you're a user of Public Transport, register your vote to help Friedrich know how to continue improving it. If you aren't a user of this Plasmoid and you use public transit in your area .. go install it and then go vote. ;)

Contributing new transit system backends or improving the existing ones is probably also very welcome. I noticed recently that the SBB backend doesn't seem to work nicely for journeys anymore, which probably has to do with their recent website upgrade which changed things significantly. Since the SBB doesn't provide a public API (though they have one!), Public Transport is just page scraping which is pretty brittle. I don't know if that is the cause of the errors, but I wouldn't be surprised. Anyone who wants to give me a nice gift could fix it up (I unfortunately do not have time right now to do so with everything else on my plate *sob*). :)

.. and in case anyone at SBB is reading this: open up your API already. It's public information and you're only hurting the society you provide service to with your policies that come straight out of the dark ages.

a quiet house

2011-07-19T09:37:00.003+01:00

S. is currently in the US visiting a university there and taking part in an invitational program for a few weeks, which leaves me alone in the house. With the windows closed it is such a silent place. Even with the with the windows open, it's pretty quiet due to being right next to the countryside. Mostly, however, it is the lack of another person in the house that makes it so amazingly quiet. There is no movement and no sound save for my own.

Besides being used to living with other people in the house, as has been the norm for many years for me now, I've also tended to live in less sound proof places. In North America, I preferred to live older houses as they have more character and less of that "built to fall down" and "made out of as much cheap synthetics as possible" feelings I get from so much of the new construction out there. One downside of older houses is that noise, as with heat, tends to leak in and out them. In Hawaii, windows are always open out of necessity and the sounds of people in the neighbourhood routinely would filter in. The new place here in Zürich, however, is stone quiet.

This really struck me yesterday mornng. I woke up when my body decided it was time to and everything was utterly, perfectly still. I could practically hear my own breathing. The absence of others was palpable even with my eyes closed. It reminded me of my early childhood in rural Canada: a perfect stillness that requires the absence of others to achieve.

While I don't think I'd want to live in perpetual quiet and solitude quiet this complete, it is nice to get some ultra-quiet time everyone once in a while to let the senses unload and relax for a couple days.

This morning was a slightly different story: I was awoken by the ringing of the door bell by some workers coming to measure the deck area for some flooring they are putting in on Friday. Tonight some couch surfers come by, so there will be people about again.

Right now, I need to push some bug fixes to git and then hop in the shower before my first telco of the day. No matter how quiet it is inside the house, life itself is always full and busy.

--annoyances;

2011-07-18T15:45:00.000+01:00

After doing some fixes to KRunner last week which I blogged, I later fixed a few similarly small annoyances in KRandrTray. Today I cleaned up a small issue with the notifications widget: the tooltip would show even when the popup was open, resulting in less-detailed information in the tooltip obscuring the purposefully open and more detailed job and notification information. This was right after reading Alex Fiestas's blog entry on having a very productive KDE hacking weekend in which he nailed some Plasma Desktop annoyances of his own.

While we're all working on lots of new things (like Plasma Active) or important retoolings of old things (e.g. libplasma2), I believe it's also important that we try and make some time to pound out the little dents and smooth out the slightly rough edges of what exists as well. A lot of these fixes take only a few minutes, though admittedly some can take a few hours of trudging through code, though that usually means a number of other cleanups can and likely do happen as well.

Usually, though, these fixes take much less time than trolling through the dozen or so bug reports needed to find one that's valid and addressable.

This is all a bit of a reminder to myself to do these kinds of little "makes me enjoy this software more" fixes more often, and an invitation to all other KDE hackers (and would-be KDE hackers) to also take the initiative similarly with the code you work on. Or, like Alex, on Plasma code. We welcome your help! :)

(Which reminds me, it's now Monday at nearly 17:00 and I still haven't gotten out my blog on Share Like Connect. Gah!!!!)

krunner updates, COSCUP

2011-07-12T11:07:00.002+01:00

While I'm pretty busy working on libplasma2, Plasma Active and related items, I do put aside time to improve other things that exist .. mostly because I'd go nuts if things I use on a daily basis didn't improve over time. ;) For instance, yesterday, a person wandered into the Plasma irc channel and noted that the top area of window thumbnails that show when one hovers on the taskbar didn't respond to clicks .. which I fixed, along with a few other cleanups in and around the area.

Today, I reached my "can't take it, must be fixed" threshhold with some items in KRunner: pressing tab or the down arrow would send focus to the list of results .. but the first item will still be selected. Not overly useful as it means having to press tab or down arrow twice to get any useful effect. Also, when results would come in and the window would automatically open up, if the mouse happened to be positioned over the results entry it would highlight the item beneath it. This was practically never the intended result and just looked a bit sloppy. Well, all that is fixed now. Huzzah.

In other news, I will be attending COSCUP next month a couple weeks after the Desktop Summit in Berlin. COSCUP is the Free Software event in Taiwan and I'm quite excited about going there to speak. I'll be meeting up with the local KDE community in a BoF session at the end of the first day and have a couple extra days after the event for meetings and follow-ups before I start the trek back home. I'm looking forward to meeting as many people and companies as possible while I'm there to discuss KDE, Qt, Free software and devices. Thanks to Armijn Hemel for helping hook this up and KDE e.V. for travel support.

PandaBoard first impressions

2011-07-07T14:51:00.002+01:00

This week I received a couple of PandaBoards, courtesy of our friends at Canonical by way of our friends around Kubuntu. The goal is to get Plasma Active running well on the platform.

It is very much a typical developer board: no cables, no boot device included and lots of "this won't work until you add this other software over there" to it. I really can't fathom why a basic set of cables and a basic boot disk is not included. Yes, it would inflate the cost of the box a bit, but a "bare bones" version would be easy to offer in tandem. The result would be that a few days of work by the manufacturer (prepping the boot system) along with procuring the cable sets would eliminate untold hours from developers wanting to get involved and give that much-needed "instant gratification" feel.

Which is to say, my first impressions were not great, and it had nothing to do with the hardware or the software. Both of which, I might add, look pretty darn good. :)

Once I have more of this beast up and running, I need to send the second device on to someone in the Plasma team to join me in working on it. I understand that Martin "KWinning" Graesslin also has one to continue working on KWin's GLES support to ensure it works well on these kinds of smaller ARM devices.

We'll keep you all posted as we make further progress. I'd love to see a downloadable bootable image with Plasma Active on it as a final result.

barcelona

2011-07-07T14:34:00.002+01:00

Last week I was in Barcelona to present at the 10th edition of the local Jornades de programari Lliure ("Free Software Conference"). It was well attended for a local technical event and the presentations were good (though I gauge this on the slides, the audience satisfaction and audience interaction).

My two local hosts, Orestes Mas and Aleix Pol, were terrific. I was met at the train station and the travel arrangements went off without a hitch. The local food and sights were wonderful as well as I made my way out in the afternoon after plowing through work and KDE code.

(Side note: Travel by overnight train is a new thing for me, and I find myself rather in love with it. Whether this is purely due to the current novelty of it for me remains to be seen. I can say that I do not miss airports.)

My presentation was the only one in English, and I did my best to speak slowly and clearly. Hopefully I succeeded. :) I presented on a topic we've been talking about for some time but which I haven't done a full presentation on before: the concept of the device spectrum and what that means for F/OSS and KDE in particular. The slides I used, which need much work still before I'm nearly happy with them (as all first time presentations start out), and partial notes to go with them can be found here. The slides are fairly large due to the images in them (some 18MB), but that was probably to be expected.

The presentation is very much my opinionm, rather than "official KDE dogma", and reflects how I see things currently. It has a fair amount of what I'd call philosophical content in it. The essential message is: writing software for one form factor or one modality for data retrieval is phasing into history, and it is software that can successfully span physical form factors and erase data locality as an issue that will have a long term competitive advantage. This idea is based on where we are now with technology and comparing past technological occurrences (and some biological evolutionary systems) under the pretense that the future mimics the past since the systems underlying these kinds of change are largely immutable.

Anyways, I was asked to present on the future of F/OSS and so I did my best. I thoroughly enjoyed having that opportunity and look forward to more great tapas in that Catalan city by the sea.

frameworks and applications

2011-06-09T13:00:00.006+01:00

The words we use matter, as they often shape not only how one does think about things but also how one can think about the subject. This is because the words we use can lead to excluding some valid options and including invalid ones.

In past releases of the KDE software compilation, right back to when we called it all just "KDE", whenever library development needed to enter a major release cycle (e.g. 2.0, 3.0, 4.0), everything entered that "big change" phase. This included the applications, the desktop, etc. This worked pretty well when the number of applications were low and the overlap between "people who work on kdelibs" and "people who work on applications" was very high. It ceased working so well by the time we started working KDE Platform 4, however.

Application developers either started porting "too" early or "too" late. Some jumped on the 4.x bandwagon quickly and suffered constant API drift, while others waited until "it" (whatever that meant) was stable (whatever that meant). Our users, in the meantime, drummed their fingers waiting for applications and workspace that they could use to be released. The need to get releases of applications out to users put unnecessary pressure on the library development process as well as the workspaces. They were all "welded together" in terms of release management. This reflected how we generally thought of the KDE codebase in general.

At the recent Platform 11 event, we allowed ourselves to really take on the implications of KDE releasing a Platform, Workspaces and Applications as seperate things. It was no longer evident that we had to put application development on pause while library development happened. It was no longer evident that "our" libraries were only for "our" applications.

This in turn allowed us to see our libraries as a collection of powerful, well-integrated, co-supportive frameworks. We started identifying "platformy" bits that had been added over the years and worked on clearly defining what the individual frameworks really are.

The plan that was proposed and accepted at Platform 11 is to start work on the next major version of kdelibs, kde-runtime, kdepimlibs, kdepimlibs-runtime and kdesupport immediately once 4.7 is ready. These modules will be morphed into a clearly defined set of libraries and runtime components with an emphasis on modularity.

We won't be waiting for Qt5, though we will be tracking the development of it closely. When Qt5 is a viable library target then we will change our Qt dependency for Framework development to that. We also are not targeting large new blocks of functionality as we did in the 4.0 release when we took on the major (and necessary) additions of libraries such as Solid and Phonon.

This will allow us to do the Frameworks organization first, influence and participate in Qt5 development as it happens and then take on Qt5 when it becomes ready all in a timely manner. At that point, application developers can begin to decide working on adopting the updated Frameworks as we work on final stabilization.

In the meantime, releases of KDE Workspaces and Applications 4.x will continue on as they have for the last few years: every 6 months. Our work in the Frameworks will not get in the way of those regular releases, preventing application developers from getting stuck between making releases now and jumping into the new versions of the libraries.

For application developers, this means as little disruptive change as possible: the functionality you have come to rely on will remain and in the meantime your releases will go unhindered. Modular libraries means more git repositories, but we will be providing an easy means to "build 'em all at once" just as we do now while allowing for "cherry picking" the specific libraries that you want to use in your application, complete with clarity in dependencies and separate git repositories.

For users, this means you will still get updates to your applications while the Frameworks hacking goes on. No more "great pause" in releases while Qt and KDE library hacking goes on as it did in 2.0, 3.0 and 4.0. It will also allow applications and the workspaces to release once the Frameworks are ready at a pace that allows for great stability and utility on first release.

To coordinate our efforts, the team at Platform 11 came up with solid definitions, detailed listings and clear graphs to guide us. They have been sent for further input on kde-core-devel to include everyone in our community. Branches in the Frameworks modules will start soon (pending 4.7.0) and work will move into full swing. All without nary a ripple in the application development efforts.

This is possible because we have gone from a monolithic mindset, which reflected the successful realities of early KDE releases, to one that reflects the realities of today: we release Frameworks, Workspaces and Applications .. and lots of them. They all rely on each other, work amazingly well together, are derived from the same enormous and vibrant community, but are today much more independent pieces of the whole.

Our ultimate goal is simple: to increase quality as we catapult our libraries into the hands of ever more developers ("Qt-only", mobile, ...) in a timely fashion while minimizing disruptions to our users.

Frameworks, Workspaces and Applications ... Words are, indeed, powerful things.

kdenlive

2011-06-05T15:43:00.003+01:00

One of the other nice little bits of news that was shared at the Randa Multisprint: Kdenlive, a terrific video editing tool that is Free and Open Source Software built with Qt and KDE technologies, is getting a little closer to the KDE community. Not only did Kdenlive developers join us here as part of the multimedia sprint (which is the fabled ".5 sprint" you may have seen referenced in other blogs, but Kdenlive will be hosted in the KDE infrastructure. I look forward to running `git clone kde:kdenlive` and watching our community grow larger and more diverse as we lower the barriers between different projects.

Go kdenlive! :)

dissections

2011-06-05T15:07:00.002+01:00

I'm sitting in the games room where the fußball tournament, which has replaced the trip to Zermatt which was canceled due to weather, is in full swing. Eight teams vying for the win, with laughter all around. Still, four people in the room here are hacking while most of the attendees remain scattered about in the rooms in the three floors above us working diligently. On what, you ask?

Well, there is the multimedia group working on the next generation of Phonon and Amarok (there's a PulseAudio fellow here with them, so that's also getting attention), there's the KDevelop group hacking on making it awesome (there's a new Plasma dashboard for it, too!) and the Semantic Desktop group (Nepomuk, Zeitgeist and Plasma devs) going mad on improving the infrastructure and implementation of those technologies and working on how well they integrate with each other. While we had a series of lightning talk updates from each group yesterday, I'm still not up to date on all the details of each group. Even though I visit them during meal times and occasionally in the day, there is too much going on and I'm too busy with Platform 11 to be able to blog about those events in detail. I'll leave that to those attending those events. :)

So what have we been doing at Platform 11? In short:

Working on what we want the relationship between future Qt and KDE's libraries to be. We will be sharing our ideas on the mailing lists as we finish documenting them.

Preparing for the inevitable coming of Qt5 by going through each class in kdelibs, yes all 200+ of them, and cataloging where they belong in the scheme of things. This might include targeting inclusion or integration with Qt, refinement or deprecation. We are aiming for source compatibility as much as possible, however, just as Qt5 is.

Cataloging each and every item in kde-runtime (all 102 of them, according to our spreadsheet) and dividing them out into function. Let's just say that runtime will become a lot smaller and properly focused in upcoming releases.

Examining our existing library solutions and determining what to do with them. There is likely to be a significant, mostly source compatible, change to KConfig, for instance. A SecretService based internal overhaul of KWallet has also been seeing considerable progress here.

Working on the git workflow we want to use for the libraries, runtime and workspaces (and hopefully as many other KDE hosted projects as possible). Cornelius just finished up the draft proposal and Frederik has done some graphics for it as well. It should make its way to kde-core-devel in short order.

As an extension of the latter, our release cycles have been discussed at length and consensus has been reached here in person. We will be sharing those results on the mailing list as well, and I don't want to blog about them until that occurs so that other contributors may be involved first before bringing the ideas to a wider audience.

In short, a lot of hacking, a lot of meetings and a lot of progress. The biggest amount of effort has gone into the careful dissection and examination of our platform in the light of what we've learned in the last few years, the coming of Qt5 and new frontiers both on the desktop and in consumer electronics.

The gorgeous mountains here in Randa have served to provide inspiration to our efforts and the sprints have already produced significant results. It's been great to see so many new people here (something like 1/3rd of the people were attending their first KDE sprint!) including some of our friends from communities such as GNOME.

A string of article for dot.kde.org will be written once things wind down here. The first people have begun to leave, and the exodus will continue over the next few days. It's always sad to see our friends and collaborators leaving, but being able to spend this time with them has been priceless. :)

krunner doing just one thing

2011-05-31T17:14:00.004+01:00

So here's a feature of KRunner than probably very few of you know about: KRunner can be made to query a single specific plugin for one search. You can even quite easily create shortcuts, both launchers and global keyboard shortcuts, to trigger this behavior. This feature was added some time ago by Jacopo, but it's rather well hidden unless you know it is there or stumble over it accidentally.

If you've played with KRunner, you probably have found the configuration where you can turn plugins on or off by pressing the left-most button with the icon of a wrench/spanner tool on it. This is something different, however.

Here is KRunner searching only for Applications on my machine:

Here it is looking only at command line operations:

You can do that with any of the following plugins (by plugin ID) in 4.7: recentdocuments, org.kde.windowedwidgets, locations, kabccontacts, bookmarks, org.kde.activities, solid, webshortcuts, shell, services, PowerDevil, wikipedia, nepomuksearch, desktopsessions, windows. This is accomplished by having a Runner plugin which either can match whole search terms or which registers a default syntax using AbstractRunner::setDefaultSyntax(const RunnerSyntax &). As long as the Runner plugin matches one of those criteria, then this line in the .desktop file for the plugin makes the magic happen: X-Plasma-AdvertiseSingleRunnerQueryMode=true. Unfortunately, in previous releases only a handful of plugins were marked this way. I've fixed this for 4.7.0 however. :)

To trigger the "single plugin" behaviour, you can create a launcher on a panel or desktop that calls to KRunner via D-Bus like this: "qdbus org.kde.krunner /App displaySingleRunner nepomuksearch". To get a list of possible values for that last entry, try this from a konsole: "qdbus org.kde.krunner /App singleModeAdvertisedRunnerIds".

The other way, and perhaps even more convenient, is to open the global keyboard shortcuts panel (type "global key" in KRunner :) and go to the Run Command Interface selection in the drop down box at the top of the window:

Then you can assign a keyboard shortcut to your favorite plugin. This means that you can, for instance, turn Nepomuk searches off in the main KRunner config and only when you want to search the files on your disk press the key combo for that runner. The rest of the time, the Nepomuk (or whatever other plugin you turn off in the KRunner config) won't be queried for normal searches done via Alt+F2 or "Run Command" from a launcher.

Pretty sweet, huh? :)

Platform 11

2011-05-31T16:25:00.004+01:00

Tomorrow I will be getting up at around 7 AM, along with Marco who has been at the house here for a couple of days, and going out to the airport. However, I won't be taking an airplane. I will be meeting people coming in from all over the place (well, Europe and the Americas, anyways), handing them train tickets to a little town called Randa and making sure they get on the train successfully.

It's not particularly glamorous work and to be honest, I'm not particularly looking forward to hanging out at the airport for an entire day. There is some upside, though: I'll get to see friends, new and old, as they arrive to join one of the four sprints happening in parallel over the next week in the Swiss Alps. It's nice to be able to lend a helping hand in making these events go smoothly and be able to spend time with them.

I'll be leaving with the last group of people in the evening towards Randa to participate in Platform 11.

If you want to read about what we'll be doing at Platform 11, check out Sebastian's blog on Platform 11 from earlier today. He does a great job of explaining it all.

I have no firm predictions as to what the results will be. That's the whole reason for the meeting in fact: we have a good idea of what the questions are, but to make progress towards the answers we need to huddle together with some 60 other people in a secluded village in the mountains and work it through. I have complete faith, given the people who will be there and the results of past events, that the results will be worth every minute and every penny spent. We'll keep everyone informed with daily blogs on planet.kde.org, "live" blogging on identi.ca using the #randa hashtag and with a wrap up summary on

libplasma2

2011-05-30T18:48:00.002+01:00

I've spent a fair amount of time this month working on shaping the libplasma code into what will eventually become libplasma2. The goals are straight-forward:

Drop cruft

Smooth out API issues that have cropped up

Separate QGraphicsView code out into a separate library, clearing the way for QML-only Plasma interfaces to not have to carry that weight

Make parts of libplasma more QML-friendly than they are currently

The motivation for these changes is based on the history of the library, which grew over the last couple of years in response to changes in Qt (the biggest being the arrival of QGraphicsProxyWidget which was first used in the KDE Platform 4.2 release) and the needs of the increasingly sophisticated applications using libplasma.

One example: As activities shaped up and have become integrated with Nepomuk, KWin and other apps, the classes in libplasma meant to help track activities in relation to Containments simply stopped making sense.

Another example: the rise of QML has made QGraphicsView things optional rather than required. We don't want to do any massive porting or rewriting, so we'll be creating a new library with all those pieces in it. Components that use QGraphicsView things will need to link to that library, but otherwise little changes.

This will be our first big break in libplasma since the KDE Platform 4.2 release, but we're trying to keep it relatively tame. So far all deprecated methods have been removed, needlessly reimplemented methods (usually because the need for the reimplementation was lost over time) are all gone, unused classes have been removed, slots that were being used as a "poor man's" virtual method have been switched to actually being virtuals and some API blemishes have been cleared. The ability to verify signed packages using GPG has also been added.

Next up is a merge of Package, PackageStructure and PackageMetadata into one class, with most of PackageMetadata actually being discarded. Then the QGraphicsView separation will get underway.

Further on, there's hope that some refactoring of DataEngine will also happen to make them easier to use from QML as well as to make them safer to use from C++ (e.g. no pointers). More of the enumerations used in libplasma will probably move into a QObject, so that while little or nothing will change from C++ we can more easily import them into QML and Javascript.

Changes to the public API are being documented here as they happen. There are still several months of work to be done on this, and we're trying to keep the impact low with the mantra of "source compatible if at all possible" constantly on our lips. We don't wish to break plugins or have to touch code that is finally becoming mature in plasma-desktop, plasma-netbook, etc.

The development is happening in the libplasma2 branch in the kdelibs git repository with discussion happening on plasma-devel at kde.org and in #plasma-devel on irc as usual.

Plasma Active: Marble To Go!

2011-05-30T15:15:00.002+01:00

(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.)

What is an Active App? It's a project built with Qt and/or KDE libraries that fits into the spirit and use cases of Plasma Active. That means it needs to be touch friendly, preferably present the user interface with QtQuick, have a nice separation between data and visualization where appropriate and integrate well with the platform.

In the Plasma Active meta-project, which includes things like Contour and live OS images, we're building up a small army of such apps in the hopes that those projects can learn from each other and us from them. It will also help ensure that when someone goes to use a Plasma Active device, they don't just have the Contour user experience but also a host of useful stand-alone applications as well.

I announced our first Active App a couple weeks back: Calligra. Today, we add another to the books: Marble!

Marble has already had a mobile version for some time, and since mapping is very important functionality for devices you carry around with you it was only natural for Plasma Active to meet Marble.

There is a project going on right now to provide a QtQuick interface to Marble, and we will be including this effort in the live images as it matures.

Plasma Active: Quick Catch-Up!

2011-05-30T15:02:00.003+01:00

(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.)

We've been a bit quiet lately around the Plasma Active farm. This is mostly due to us being rather busy, both with technical as well as organizational tasks. On the technology front, things continue to plow forward at a very brisk pace with Contour shaping up with every passing day and libplasma2 (a big part of the Plasma Quick track) zipping ahead nicely.

Organizationally, we're learning new lessons every day as to how to best coordinate efforts between companies currently involved and reaching out to ones that should be involved. Basyskom sent a bunch of people to the recent MeeGo conf, and the response was fantastic, including some bloggers writing about the demo that was on offer.

There's also been some learning-as-we-grow happening that has hampered outbound communication somewhat. For some of the people involved, this is their very first open source experience. For others, this is their first foray into the interesting world of devices. While it is terrific to expand our merry band of freedom makers, it also has meant some learning curves.

Amongst all that, code is getting written, the user experience design continues to mature and new operating system images are being spun. All is good in the land of technical progress. Marco is hanging out at my place for a couple days prior to the upcoming Platform 11 meeting (which starts Wednesday) and we're getting some work done at a nice pace. Today we're working on Share-Like-Connect and building integration points in Contour for it.

I am, however, behind on posting news about new Active Apps as well, which I'm going to remedy in a moment.

relax :)

2011-05-11T06:11:00.002+01:00

After my last blog about a possible future KDE Platform 5 due to Qt 5, it was interesting to watch the number of "Oh no, not another big release that will break the interface we know!" type comments. Let me put all of that to rest:

The Plasma team has no intention, desire or need to start "from scratch" nor engage in a massive redesign of the existing netbook or desktop shells.

One of the goals of Plasma from the start was to design a framework which would enable us to preserve work in the future. I was at the time quite disheartened that the design of kicker was so inflexible that, as good as it was, to make any sort of real changes to it would essentially require a rewrite of the whole thing. Even if it had been done piece by piece, at the end of a long development process there would have been no original code left. I went through the code and marked it up by hand to discover this. Keeping in mind that Kicker and KDesktop themselves were rewrites I was shocked, and so set out to create something that was flexible enough and free of internal assumptions so that we'd not have to "start over" again.

Fast forward to today and we have a robust framework with very few internal assumptions about what a primary user interface looks like. That's why we can use it for a desktop, for a netbook, for a tablet, for application dashboards and all the other projects people are building around it. Even as Qt has jostled about we've managed to keep Plasma bits coherent and avoided rewrites. Code that hasn't been touched in a couple of years in plugins and the shells themselves still works just as it did, and more importantly when we wish to add to that code it isn't difficult or time intensive.

Also keep in mind that Qt5 is set to be a "non-disruptive" release. It is mostly about cleaning up performance issues, focusing on QtQuick and improving the modularity of Qt. This will end up affecting binary compatibility, but source compatibility will remain largely in tact, especially for modules considered 'done' like QWidget based things. That means we are not compelled out of necessity to rewrite fundamental bits of our apps as we were with Qt4.

I expect there to be work to be done in the build system to reflect however Qt ends up being broken up into modules as well as a lot of work in managing the new QML2 and QScript work, something we've already started preparing for in Plasma. Otherwise, things shouldn't be too disruptive and I'm really looking forward to some of the performance improvements that will result from the Qt hackers really going "full steam ahead" on making Qt even more lean and mean than it is now.

One more important thing to consider is this:

This isn't going to happen tomorrow, or even this year.

Qt5 isn't scheduled until 2012. No release date has even been set. The release planning is still happening, but they've announced it this early so that we can all get involved. Qt being openly developed isn't just a story, it's a reality and Qt project management is putting their actions where their mouth has been. Bravo!

This means that a KDE Platform 5 can't happen any sooner than that. The earliest date that has been suggested thus far on the mailing list for a first KDE Platform 5 release has been January 2013, and even that may turn out to be "too quick". We'll see, but we have at least 2 more 4.x releases, and I would not be surprise at all if that turned into 3 or even 4 more.

As we cast our eyes out into the future by a couple of years, we are also keeping our minds on today and will continue working the 4.x code base. After all, it is what will become the 5.x code base. :)

I hope that puts some concerns to rest. As you can see, the KDE developers share pretty much all the same anxieties as you do about such a big release and are more than content to "just" deliver a more performant, more reliable, more featureful, more device-friendly version of our existing Platform and Workspaces. We've worked really hard to be able to say that, and will continue to work hard to take the next steps forward toward meeting those goals. :)

Qt5 .. KDE5?

2011-05-10T08:07:00.003+01:00

As most of those who read my blog have already heard, Qt5 is on its way. The target is 2012 and the focus is QtQuick where there is a high degree of separation between display and data and things are rendered using a hardware accelerated (read: OpenGL) scene graph. This is very much in line with where we are heading with Plasma as well. Exciting times!

What does this mean for KDE? Will there be a KDE5 in 2012 as well? What would a KDE5 look like? I know these are the questions on some of your minds, if only because some of you have already started asking myself and others about it. ;)

The short answer is that we don't know yet, but we're working on it. Not a very satisfying answer is it? Well, short answers are rarely much fun. So here's the slightly longer version.

Some of us have known for a while that Qt5 was brewing. The decision to start on libplasma2 that focused on QtQuick and moved away from all things QWidget was influenced by this knowledge. Thankfully, with Plasma's emphasis on Javascript, data/visualization divisions, use of OpenGL and more recently QML, we're in a good position to follow the Qt5 flow as it comes. We're already discussing on the mailing lists how to get involved and what issues will be most important to us. We're quite excited that Qt5 is going to be developed in the open, as this should give us much more influence in and foreknowledge of decisions that get made.

However, Plasma is not KDE, it's just one part of our rather large ecosystem of software projects and products. The biggest impact that a Qt5 will have is on the KDE Platform itself, since the library infrastructure relies on working well together as one cohesive unit. As Lars pointed out in his blog entry, the focus for Qt5 is to not disrupt the application developer by changing the API, but rather making performance oriented changes that result in the binary interface, or ABI, changing. For most applications, that will mean recompiles and possibly some source level tweaks here and there.

For some, however, it will be a little more drastic. Qt3Support will be gone, which means KDE3Support will almost certainly die along with it. If your application still relies on the Qt3- or KDE3Support libraries, this is a wake-up call to address that.

The current plans for Qt5 mean that, unlike Qt4's reinvent the world approach (which was needed, if painful), it will be evolutionary and far less disruptive. This is the good news.

I also see this as an opportunity for KDE's own libraries and runtime that form the KDE Platform. We don't need another big re-engineering of the base technologies as we had in KDE4, but there is a lot of opportunity to improve how the pieces fit together. Since Qt will be breaking ABI, KDE's own libraries will also have a new, binary-incompatible signature when compiled against Qt5. That means we have the opportunity to clean up things that require breaking binary compatibility.

Often this doesn't require affecting source compatibility. For instance, the other day in the libplasma2 branch I removed a data member in a public class that shouldn't have been there in the first place. This is binary incompatible, but doesn't matter one bit from a source compatibility perspective.

Some changes will likely affect source compatibility, however. KDE's UI and KIO libraries both need some hard changes made to them. libkdeui will need to split out platform, QWidget and generic components. KIO needs a similar split between platform bits, QWidget-centric UI and business logic bits. We need to think about how to reform the KDE Platform so that it is not only possible but easy to create builds for devices with less storage or targets where QWidget simply won't exist in the future.

The best news is that in just a few weeks, dozens of KDE developers are coming together in Randa, Switzerland to work on these issues at the Platform 11 meeting. The organization for this meeting actually started towards the end of last year, and the timing really couldn't have been better.

Today we stand with a bright future ahead of us, with Qt growing leaner and more modern and appearing on more computers and more devices every day, but we also stand with a number of open questions. We don't really know the details of what KDE Platform 5's libraries will look like. We do know it will be an evolutionary release, much like the transition from KDE2 to KDE3 was, with significant improvements. We will be grappling with those unknowns in the Alps, well away from distractions and surrounded by natural beauty, and we will start to draft those answers. A couple of months later we'll be in Berlin to come together at the Desktop Summit and push it yet further forward. We should, by then, have some very clear ideas of what the next year of development towards Qt5 and an eventual KDE5 will entail.

Personally, I can't wait. Perhaps because I remember how KDE3 polished the raw materials of KDE2 into a high gloss finish and can see the same patterns emerging here again. :)

another git wiki: ikiwiki

2011-05-10T07:44:00.002+01:00

On my previous blog entry about gitit, a wiki that uses git to store and revision all its data, a fellow named Richard commented:

"Why not ikiwiki? Actively maintained, lots of plugins and works as a blog engine so you don't have to use blogger.com ;)"

My answer was simple: it hadn't shown up in searches I'd done. I probably share some of the blame for that, but it also highlights that as a F/OSS project getting the word out and making sure you are prominent, particularly for common search queries, is important. In this case, I missed ikiwiki, but Richard made sure that didn't last long. ;)

I managed to find some time at the end of a long day yesterday to toy with ikiwiki and since I had spent time writing about how great gitit is (it really is! :), I figured it would be nice and fair to at least try ikiwki and report back.

Here is my verdict in summary: it's an excellent tool, far more capable of gitit, but also comes with a lot more overhead in terms of setup and management. It is a classic trade off between power and ease of use.

ikiwki requires an investment in time to set up. If you are running Debian, there are packages for it, otherwise you'll be installing lots of perl modules (thank goodness for CPAN!) and reading the not-as-coherent-as-it-could-be documentation on getting it set up. I felt a little like I was building Plasma Desktop from scratch at times with all the dependencies. ;)

Once ikiwki is set up, you next need to ensure the webserver is set up properly. Unlike gitit, ikiwiki does not provide it's own web server, which is not a bad thing. It just means it's one more bit of software to configure. Thankfully, other than a missing ExecCGI directive, openSUSE's apache2 install is perfectly set up to host ikiwkis in your home directory.

Then there is the configuration. Richard was right, ikiwiki has tons of plugins. Which means choosing which to enable and which not to, and how to configure the ones you do enable that have configuration options. Thankfully the setup page is available via the web interface itself, though the configurations options are often rather cryptic. I wasn't sure what some of the things did, but with some experimenting I figured it out. (Flashbacks to KDE software from the KDE2 or 3 days. :) One thing to keep in mind when trying out ikiwiki is that it looks horrible by default, but if you just put "actiontabs" in for the theme plugin configuration it looks far more sensible.

For the investment of time you get a wiki with full text searching, caching, templates, tags, link tracking and all sorts of other goodies. It does have it's flaws: the management UI is nothing to write home about, the permission management is primitive and the documentation could use some help. ikiwki stores the pages in markdown, but doesn't seem to provide conversion utilities to other formats (other than HTML, of course), but you can easily use pandoc for that.

However, with ikiwiki you do get a very capable, light-weight wiki suitable for group editing and all backed by git for easy replication and interaction behind the web interface, and that could well be the killer feature for ikiwiki: a git backend with lots of features on top.

So now I have not one but two great tools to choose from: gitit when I need something fast to set up and easy to use, and ikiwki when I need something with more features. Got to love Free software. :)

gitit

2011-05-09T12:05:00.003+01:00

After finding myself rather behind on a few different things I'm working on, I spent some time this weekend thinking about how to better order some of the things I'm doing. It seems this is a theme for 2011 so far, what with Plasma Active moving to iceScrum for project management and other similar events.

One thing that came to mind is that I'd could probably really use a personal wiki .. or three. Of course, I'm a picky sort of person and had all kinds of requirements in mind which I was fairly sure I wouldn't be able to find all in one tool. Essentially, I wanted something:

similar enough to editing a Mediawiki-based wiki that it didn't feel too alien

that can be set up in a matter of minutes

that used git for storing the content so I could easily carry it with me on my laptop, but then sync it to a server somewhere without pain

could host multiple wikis side-by-side

I search the Internet using variations on the search phrase "git wiki" (e.g. "git backed wiki") which gave me all kinds of results that had nothing to do with what I was looking for but, thankfully, also a small handful of links that were on target.

The first two options I found and tried left me feeling empty: they were featureless and not actively developed. Then I found gitit by John Macfarlane.

At first my heart sank: it was written in Haskell and looked to have some sort of arcane install process. That was just my ignorance speaking though, as I soon found that OpenSuse's warehouse of packages gave me quick access to everything needed to get gitit up and running. The most important bit was a tool called "cabal" that does all of the heavy lifting for you. After doing the "one-click" install of cabal (which ironically took more like a dozen clicks), it was installed and ready to run.

After adding the ~/.cabal/bin directory to my $PATH, I made a directory for the wiki content, ran `gitit --print-default-config > gitit.conf`, edited the config file (setting a title, changing the default port; it's very well documented) and then started the wiki with `gitit -f my-conf +RTS -I0 -RTS`. The latter bit of line-noise is to make Haskell behave nicely and not constantly run the garbage collector and thereby kill my laptop battery; I got this jewel from the gitit documentation which is very nicely written in my opinion. Creating a second wiki was as simple as reproducing those steps.

Best of all, going into the wikidata/ directory and doing things like `git log` gave me exactly what one would expect. It feels like a wiki via the web browser, but it's doing git magic in the back. Just like Plasmate does. Is this a part of the future of content-centric software?

I do miss templates from mediawiki, but other than that all is good: easy editing, page history, discussion pages, file uploads, user accounts, etc. It does lack a lot of features Mediawiki has, but I need none of them (save, perhaps, templates). It uses Markdown by default (though you can use various other markup styles, including something call "literate Haskell"), but can export to a myriad of formats including Mediawiki markup, HTML, LaTeX and what not. This part is all powered by another of John's projects: pandoc.

Performance wise it is instantaneous on the laptop (as one would expect) and does support things like caching pages and sitting behind a proxy web server. I haven't bothered to set up either feature as I don't need them, but how to do so is described clearly in the gitit documentation. The gitit process is currently taking ~8.5MB of resident memory and sharing another 25MB and idling, as one would hope, at 0% CPU usage so I have nothing to complain about there either.

I'm very happy to have found such a tool, all nicely GPL'd and everything, that performs like a champ and has absolutely zero lock-in thanks to the usage of things like git (for data management) and pandoc (for content format management). If you've been on the look-out for a similar tool, I heartily recommend checking gitit out.

Plasma Active: New OS Image Available

2011-05-02T14:56:00.002+01:00

I'll be leaving Tokamak 5 and Nijmegen in just over an hour, but before I head out the door some good news by email arrives: it's time for a new OS image according to the Plasma Active OS track schedule, and so there it is: v 1.0.70.

If you are following Plasma Active, download the image and see what's new. If you aren't following Plasma Active yet, what are you waiting for? Go to the install wiki page and get rocking.

We unfortunately don't have a coordinated change log for this release which includes all the improvements made in Plasma Quick and Contour over the last couple of weeks, and that's something we'll be working to improve as part of the process in the coming iterations.

Feedback and participation, as always, are welcome. Join us in #active on irc.freenode.net or the Active mailing list.

A big thanks goes out to our friends at open-slx for driving Balsam forward and helping hit our next milestone in the OS track!

I'd also like to thank those who have joined in from the openSUSE community, such as Will Stephenson, to work alongside the Plasma team on packaging issues. Growing the community of packagers and operating system enthusiasts around Plasma Active is great to see.

Plasma Active: Calligra Active

2011-04-29T16:39:00.002+01:00

(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.

a typical day at Tokamak 5

2011-04-28T12:33:00.003+01:00

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. :)

Tokamak 5, Day 2

2011-04-27T07:51:00.002+01:00

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.

tokamak 5 begins

2011-04-26T08:33:00.003+01:00

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.

undertow

2011-04-19T15:55:00.003+01:00

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. ;)

Plasma Active: Vendor Interaction

2011-04-15T14:28:00.003+01:00

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.

Plasma Active: Operating Systems

2011-04-14T15:29:00.004+01:00

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:

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

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:

ViewSonic Viewpad 10
WeTab
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.

Plasma Active: Active Apps

2011-04-13T13:21:00.004+01:00

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:

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

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

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!

Plasma Active: Contour

2011-04-12T12:58:00.002+01:00

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.

Plasma Quick Redux

2011-04-12T12:21:00.002+01:00

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 :)

Plasma Active: Quick!

2011-04-11T12:56:00.002+01:00

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! ;)

active routes

2011-04-10T14:41:00.005+01:00

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.

Plasma Quick (Monday)

Contour (Tuesday)

Active Apps (Wednesday)

Operating Systems (Thursday)

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. :)

sounds familiar? well ...

2011-04-08T04:00:00.001+01:00

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.

sounds familiar.

2011-04-06T14:39:00.007+01:00

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 ...

just another day in paradise

2011-04-04T16:28:00.002+01:00

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.

the fun in banging our heads together

2011-03-30T10:02:00.002+01:00

After sitting on a train for four hours that whisked me through the countryside of Switzerland and into Germany, I am sitting in a room in Darmstadt that is full of familiar faces, along with one or two less familiar ones.

For instance, it's been a few years since I had the opportunity to meet up with Eva, who was KDE e.V. president before I was, and even longer since I got to sit down with Stefan Werden and discuss high level topics about Free software, distributions, KDE, etc. In fact, I think the last time I met up with Stefan for an extended visit was at the Appeal meeting in Berlin all those years ago. We've passed each other at conferences a few times since, but today and tomorrow we're sitting down to really bang our heads together about (what else?) Plasma.

Ok, it isn't all about Plasma. Sebastian Trüg is also here, so I'm sure you can guess what else we're talking about: Nepomuk. The Other Sebastian^TM (Kügler) is also here as is Marco Martin. There are also interaction designers and project managers in the room, so we're bringing a lot of different useful perspectives and voices together.

What are we working on? Well ... that's something we'll be blogging and documenting at the end of this week. Right now what I can share is that we'll be bringing Plasma and other KDE software to a wider array of devices, and as part of that we're going to try to be a lot clearer about the device continuum approach that is at the heart of Plasma.

We're going to spend the next few days banging our heads together, messing up some whiteboards and sharpening our ideas in the forge of creativity. Then at week's end we'll share our progress with the community at large, push it through another iteration of input and refinement with everyone involved and then at the end of next month at Tokamak 5 in the Netherlands we'll do another big iteration of what we're working on here. Our work and communication will continue to build up through the Platform 11 meeting in June and the Berlin Desktop Summit in August. Today we are pressing the ignition button on this locomotive.

On a personal note, after spending months dealing with my move to Switzerland, adapting and working with the various changes in the Qt space and a host of other time and energy drains, it is really nice to be able to sit down with others, concentrate and bring Plasma development and innovation back up to the old break-neck pace. While the last six months have been progressive, they've been rather focused on important incremental improvements. I'm looking forward to mobilizing the energy that is circulating in this room, spreading it to the community at large and seeing where it will all go.

Oh, and you may want to mark 9.10.11 down on your calendar. ;)

platform ho-ooooOOO!

2011-03-24T08:31:00.004Z

A Quick Archeological Diversion

Yesterday I hunkered down beneath an old church to look at its foundations, bumping my head a few times on the low ceiling while trying not to get dirt on my clothes as I leaned around various corners and edges.

Five different phases and eight centuries of construction were visible. Besides a few graves and some interesting stone work, there are also two "Findling": large natural stones that were left behind by glaciers during the last ice age, marooned on a small island in the Limmat river. Over time and with some applied imagination, these stones had become wrapped in a myth about Christianity, a pair of Roman soldiers, their slave and a post-beheading zombie walk up the banks of the river. It's a story that, much like the building itself, evolved over the centuries: while the story appears in the 8th century, the slave was added to the story in the 13th century. It also planted the seeds for a festival which lives on today as the annual shooting festival, or Knabenschiessen, in Zürich.

Today, the church is no longer on an island. The Limmat river, as is common for rivers flowing through cities, has been significantly narrowed over the centuries due to urban development. However, I can well imagine that when the stones were naked on that small island, one breaking the flow of the river and the other one behind it, they could very easily have held mystical significance even for the resident bronze age population. Elsewhere in Europe, similar peoples loved to venerate their islands, stones and valleys so putting the three together could well have been quite moving for them. There seems to be some disagreement on the relation of the stones and the prehistory peoples, but one can always imagine. :)

.. aaaand we're back (to people)

Whether in the evidence found in centuries of stone structures piled one atop the other or in the more contemporary form of digital creations communities such as KDE generate over the span of mere years and decades, the paths we take together and the histories we lay down are endlessly interesting.

KDE's libraries have their own "archeology" buried within the code: some of it is older, some is newer and it is all laid down in strata. (Too bad there is no "git log" for physical objects! ;) As with the land beneath any living, thriving settlement, the KDE Platform is not yet settled into stasis never to be changed or altered again. It grows, it changes, it gets refined.

With Platform 4, we added a number of frameworks each with its own purpose. We often refer to these as "the pillars of KDE Platform 4" and they include familiar names like Solid, Phonon, Nepomuk, ThreadWeaver, Sonnet, Plasma, etc. They are all still growing and improving, which is a good sign, but it does beg the question: where are we going?

Platform 11

Find answers to that broad question is the purpose for the upcoming Platform 11 event this June in Randa, Switzerland. Topics will include desktop, mobile, extending the Pillars of KDE upwards as well as outwards into our applications, modularization, increased interface with the Qt ecosystem and more.

It's going to be a huge event in terms of importance, scope and the number of people who will be participating. Platform 11 will have some 25 participants on its own, but it won't be alone: we will have the company of three other KDE development sprints happening at the same time in the same small village! This will be the biggest library focused event since Trysil, Norway five years ago.

We will busy ourselves with mapping new phases of construction for the KDE Platform, and so the importance simply can not be understated. kdelibs may have been around for less than 15 years, nothing compared to the old buildings here in Zürich, but the construction of layer over layer as we modernize all while keeping the spirit of what went before alive, is much the same.

If you are on the attendee list and haven't yet put in your registration with travel cost estimates, please do so ASAP so that I can finalize the budget and move on to other logistics.

If you won't be able to attend, we'll be making sure that we keep everyone up to date with what happens at the event as it happens. We'll do this through a combination of live blogging, daily blogging, irc channels, email list communication as appropriate and overview reports on dot.kde.org. I'm hoping we'll even have a presentation at the Berlin Desktop Summit on the results, but that remains to be seen. This is our platform, not just for the 25 or so people who will be physically be there participating, but for all of us. We will have that in mind as we work towards our common goals, much as we have at the past "big" kdelibs events.

The expected agenda and format of the event will be announced in the coming weeks. Cornelius and I will be working on a process for that together and will be asking for input and participation once we've got some initial logistics worked out.

sprints.kde.org

We also have some new organizational tools for sprints that we're using for the first time. It's all part of the "standardizing around smoother, leaner processes" path that we've been on for a number of years now.

This time we're improving sprint organization, starting with the new sprints.kde.org website where events can be proposed, approved for funding by KDE e.V. and organized. It's still a "beta" site, but it already has a number of features that will make sprint organizing and reporting much easier for us all. KDE e.V.'s board of directors will have a nicer tool to gain an overview of present and past sprints, sprint organizers will have more guidance and less "by hand" work to do and sprint attendees will have a standard, simpler method of discovering and participating in sprints.

Naturally, it ties into identity.kde.org so your existing KDE account is your key to future sprints. It also has OpenStreetMap integration, standardized forms for sprint attendees, etc. This has been a remarkable experience in which KDE's sys admin heros, our growing web development community (in this particular case, Emil Sedgh) and sprint guru Mario Fux all coming together to make something we've probably needed for a while now.

If you are organizing a sprint, please use sprints.kde.org if you can. At the moment, starting that process still means getting in touch with the KDE e.V. board to get it posted on the site, but the proposal process will eventually be done on sprints.kde.org itself, open to anyone with an identity.kde.org account. The goal is to also standardize and streamline the sprint proposal process so it is more predictable and carries less administration overhead.

Of course, the website itself is also Free open source software. If you'd like to help improve the website (so many possibilities: RSS feeds, calendars, post-sprint reporting improvements, accounting views, sprint proposal workflows, auto-created countdowns, Plasmoids, ...), git clone the sprint-kde-org repository, coordinate with Emil (aka emilsedgh on irc) and start cranking out those patches!

Excited yet?

This is the kind of thing that comes to mind when I think "KDE": people coming together and tackling exciting, big issues from multiple angles, doing the hard work with enthusiasm. Just look at what's going on here: Web development and KDE? Check. Mobile? Check. Improving the Pillars of KDE? Check. Planning for current and future Platform needs? Check. Organizational process improvements? Check. Sprints galore? Check. Amazing minds and the wonderful people who own them coming together for a momentous week in a beautiful location? You bet.

I can't help but feel excitement when I think about it. The anticipation of positive movement, positive energy and important, challenging questions ahead of us ... The future is open and there for us to explore with open minds and arms. I wish it were June already!

On that note .. if you, like me, feel these kinds of events are critical to the future of KDE and the Free(dom) software our community creates and you haven't done so yet, please consider Joining the Game with a small financial commitment. Your support helps make these events possible. :)

shoot the messenger

2011-03-12T09:38:00.002Z

I'm glad so many people are talking about inter-project cooperation, the role freedesktop.org plays in that, etc. It isn't an easy set of discussions because it is a difficult topic. I recognized this was the case in my first blog entry on the topic where I noted that the topic was incendiary, so I went in with my eyes wide open. So while there are those writing thoughtful pieces, such as Henri's blog entry on cross-process collaboration, others are more content to shoot the messenger.

Dave blogged once again and this time he took aim at the character of people. Even if we assume that I'm a raging asshole laying waste to the interactions going on around me, the track records remain for all the projects involved in freedesktop.org in terms of what each has adopted and what each has proposed. I really hope that people pay attention to the issues we face rather than pick on personalities involved.

I'm not going to write a rebuttal to Dave's essay point by point, but I would like to correct a statement Dave made that was not just unfair and incorrect but potentially quite damaging to the overall process because it is unnecessarily divisive: I do not have "no confidence in GNOME developers as a whole." This is not about the individual developers who work on GNOME as a faceless whole. I've known several of them for years and count a number of them as friends and associates. There as several who I have praised openly and publicly in the past for the technical and social work. To put it simply: I am not a bigot, and I'd ask that we not use such an idea as an excuse to dismiss the realities we face.

This really isn't about individual developers, and I do not paint every person in GNOME with the same brush in my mind. I don't do that for KDE, either: there is variety, some productive and some counter-productive, in any large group of people and our communities are not exceptions to that. However, casting me as some sort of "I hate all of you!" villain is not useful. Even if it were true, then people should simply ignore me as an individual actor in it and look at the large, long-term patterns that really do exist and really do need fixing. I am not personally responsible for everything, I was not even involved most of episodes that exhibited the unfortunate patterns we've been experiencing. So even if the messenger really, truly sucks and you really don't like them as a person, try to address the issues anyways. Avoid indulging in shooting the messenger as a way of dismissing issues and thereby relieving the perceived pain. It's only a distraction, and nothing gets improved that way.

Aside from all that, I do find hope in the discussions being had: Dave says freedesktop.org is not functioning the way it should, and I've heard the same from others. People have been trying to put forward possible ways to improve it for some time now. Those involved in freedesktop.org as a whole haven't actually been trying out those ideas in practice, and that is a bit discouraging and certainly not helping. Having a functional, healthy collaboration zone (or zones) would be to all our benefit and I do hope that we find the time, energy and courage to try to better our processes.

Starting with clear problem statements, as Dave suggests, might be one thing to do. We now have a defined git repository to house specs in a shared fashion, perhaps we can now add usage metadata to that repository so we can easily track who is using, who is developing and who is participating in each effort clearly. This would help address Dave's concern of ensuring that projects have the appropriate individuals around them, as we'd be able to easily identify when they don't. This is a source of insight we currently lack. There are certainly other improvements to be made as well, and I hope that we can shift the discussion to those things.

Before I sign off for the day (it's a beautiful sunny Saturday outside, and we're going to go for a walk and some shopping in a bit!), I also wanted to clear some technical errors in Dave's blog:

StatusNotifiers are not about notifications. This an understandable error I've seen repeated a few times as the word "notifier" is in the name, but it is actually about system tray icons or "message area" entries. The use of the word "Notifier" was to emphasize that it is about communicating application status rather than presenting a full interactive interface. It really, though, has nothing to do with notifications themselves, which is a whole other technical topic.

StatusNotifiers did start with a clear problem statement, namely that the XEmbed system tray icons were failing us in a number of technical manners. This problem statement was shared on the xdg@ list more than once and over the course of several years, and a number of projects other than KDE agreed (Enlightenment is one that jumps to mind, for instance). Where we could have done better is to repeat that statement when introducing the StatusNotifiers spec to the xdg@ list, something Dave observes. We simply can not assume people will have read and remembered past discussions and need to keep context. StatusNotifiers did start, however, with a clear and communicated problem statement.

Changes and improvements suggested were made to the spec, though not all were, particularly those that deviated from the design in such a way as to make the entire concept of host-side rendering control moot. We didn't show up with something hard-baked and without flex in it.

Cheers ...

panel hiding

2011-03-11T13:27:00.002Z

With all the news of mobile and politics and what not, I thought it might be nice to hear about things we're working on related to the desktop that, while maybe not as earth shattering or exciting, are none-the-less part and parcel of what we do each and every day.

One of the things we introduced in recent releases of Plasma Desktop was panel auto-unhiding: if you have a hiding panel and something in it says, "Hey, I need the user to notice me!" then the panel will happily unhide. This was only possible because we have the ability to know things like the attention and input status needs of components such as Plasmoids and Status Notifiers.

Unfortunately we hit a snag: not everything sets the attention status sanely. This would sometimes lead to a panel being "stuck" in the unhidden position, unless you could find out what was "sticking" it and cause that component to become "unstuck". Not very elegant.

After stumbling through a few other random issues yesterday and today, I implemented an approach that tries to balance all needs. This was something that came out of discussions with hiding panel users who are also KDE contributors, particularly Kevin Ottens and Thomas Zander.

In the plasma/panelunhiding branch in kde-workspace, a panel will now auto-unhide and then rehide a few seconds after any user activity. That means that if you walk away from your computer, something happens and you return, the panel will still be there in a visible state to let you know. However, if you are using the system while something goes into "I need attention" state, then the panel will pop up but then mercifully slide back out of view in a few seconds time without you do anything.

I'll be testing it out more over the next few days and welcome others to do so as well, and then if all goes well with this approach then I'll merge it into master and, if it's really solid, maybe even merge it into 4.6.

battling misconceptions, even within KDE :)

2011-03-11T09:32:00.002Z

Stuart has written a rather nice blog entry on misconceptions around what KDE is and how the community works.

One of Stuart's points was that KDE doesn't have top-down leaders that can tell random other people what to do in a way that they are beholden to follow. This is quite true, and it's a strength in that it prevents KDE from hijacked by any one interest, or requiring that we bet our future on any one group consistently and always making the best decisions.

It isn't, however, pure anarchy as one might get the impression it is from reading Stuart's blog. He notes that we do share commonalities such as the software libraries in the KDE Platform which create some bottom-up driven consistencies. We have similar "consistency creators" that aren't technical in nature, as well.

Stuart noted that we do have prominent community members, and many of those community members are prominent within KDE even if not so visible outside of it. These are people who are recognized at having great skill, wisdom and/or insight into issues relevant to KDE. These people often hold discussions that cross project boundaries within KDE to help create consistency and share their expertise.

People within projects also often seek each other out to discuss matters and find through patterns of challenge and consensus common directions. Our annual Akademy gathering is perhaps the most visible, if time and space limited, example of this.

Stuart is correct, at least according to my understanding of KDE, that "if you wanted to change our software significantly then you would have to contact key people in every team and convince them of your vision." This sounds a lot more difficult than it really is since projects talk to each other, we share information, we share links, we get together in person and knock ideas about, etc.

For institutions that have more resources to bring to bear in a more traditionally monolithic fashion, such as a company looking to productive parts of KDE's software offerings, we also often provide a well defined human interface for them that does the "contacting key people in the relevant teams" bit for them. So while that work does get done, the question is "by whom" and "how" and it varies from case to case. I would also echo Stuart's suggestion that using KDE e.V. as an initial contact point can be very useful for organizations looking to build an interface with KDE.

Is weird good, as Stuart asks? I agree with him on this point too: it is when it works. In the case of KDE it tends to work more often than it doesn't (and we try to constantly improve the areas that aren't meeting reasonable expectations), and in large part that's because while it is highly decentralized, we have a tight and vibrant network of people who work together to create an organic structure that provides a useful level of global direction and consistency.

collaboration's demise

2011-03-08T09:37:00.003Z

Dave Neary published a blog post about some of the challenges experienced with GNOME and Canonical working together. I'm not going to put myself in the middle of that particular tempest-in-a-teapot, but when I got to the point in Dave's blog where he justified GNOME not picking up the appindicator work I cringed and then cringed some more. For you see, the appindicator story is not so much about GNOME and Canonical as it is about GNOME and the rest of the free software desktop ecosystem and the regressive behavior being demonstrated there.

There was a time when most everyone was really trying hard to close the interoperability gaps between different Free software stacks, and freedesktop.org was one place to achieve that. People were engaged in creating improvements for things that weren't as good as they should be and sharing the results between projects so that our users not only got improvements, but got to enjoy those improvements in all their Free software applications. Those days seem to be receding into the past however as GNOME seems increasingly content to "do their own thing". It's like they have lost sight of the goal of a coherent experience for users of Free software regardless of the applications they choose to use.

The decision by GNOME to not adopt what Canonical calls "appindicators" and what we (and the specification that was brought to freedesktop.org) refers to as "status notifiers" is a perfect demonstration of the problem. Sadly, it isn't the only one, but since Dave brought it up, let's examine this particular case.

The reason for creating status notifiers, and why Canonical built their appindicator library on top of that technology, was because, quite simply, the XEmbed based system tray icons were broken. They did not lend themselves to a modern presentation, failed to provide a compelling answer for mobile/tablet/netbook form factors and lacked any mechanism to communicate vital metadata to the host visualization. I won't go into all the technical details here (others have covered them elsewhere in the past), but suffice it to say that the old XEmbed system was increasingly becoming a blocker and status notifiers were a big step in a better direction. When we started work on them, it was our goal for the very start to make them attractive to and useful for others so that we didn't accidentally create a "separate silo" technology.

As a result of our work and outreach, Canonical agreed that there was value in the technology and picked up the technology, adding things like menus-via-D-Bus to it. Other projects such as GLX (previous Cairo) Dock followed suit and also added support for them.

In contrast, GNOME went in their own direction, even mentoring a Google Summer of Code project to create something unique to gnome-shell. Dave offers the following reasons for passing on libappindicator:

"it doesn’t integrate with gnome-shell": this is a tautology; it doesn't integrate with gnome-shell because GNOME didn't pick up the technology. If GNOME had, gnome-shell would have gained support for it and it would have integrated with gnome-shell.

"probably depends on GtkApplication, and would need integration in GTK+ itself": the answer to this one is simple: fix it. The core of the technology isn't "a GtkApplication dependent mechanism", so this should be addressable .. but again, would likely require GNOME identifying the value in and adopting the technology.

"we wished there was some constructive discussion around it, pushed by the libappindicator developers; but it didn’t happen": I can't speak for the GNOME / libappindicator dev collaboration efforts, but KDE Plasma devs have been working with libappindicator devs for some time now. We don't always agree, but we do tend to get things done and share efforts along the way. In addition, there was a lot of communication about Status Notifiers on the freedesktop.org xdg list where good feedback was offered and the specification improved significantly as a result. So communication really can't be to blame here, at least not communication by those outside of GNOME.

"there’s nothing in GNOME needing it": this depends on how you define "need". It's true that one can certainly build a desktop application or a desktop shell without Status Notifiers / app indicators. One can even build one without a system tray / notification area at all! One doesn't need D-Bus either, or any other number of technologies. But they improve the user experience. In this case, it is a significant improve on what was there before. Also significant is that adopting the technology would draw together GNOME apps/shells and non-GNOME apps/shells to the betterment of all our users.

Other objections given in the past, such as "there's no mechanism for publishing menus using D-Bus" or specific nits about the StatusNotifier spec have been resolved one by one as those who adopted the technology worked together to improve it so it met all of our needs. Unfortunately, GNOME wasn't one of those participants and even as these issues have been sorted out they remain uninvolved and apparently uninterested.

Why do I care, or perhaps more importantly: why should you care? Well, this has become a pattern of behavior that we're seeing more often and it runs directly counter to the idea of a Free software desktop platform where applications are highly interoperable. It is indeed not incumbent upon any project, be it GNOME, KDE or any other to adopt every single technology on offer. However, it is in all our best interests to work together more rather than less and to share what makes sense, even if sometimes it means some short term compromise. KDE has made that decision many times even in recent times as we adopted various technologies such as D-Bus, shared mimetypes, shared icon theme definitions, etc. It's taken a lot of effort on our part and at times we've had to make some compromises, but our users have been reaping the benefits.

So while I personally think it is certainly acceptable for GNOME to elect not to get on board with Status Notifiers / appindicators (or other things, like a shared job D-Bus spec, or usage metadata for freedesktop.org specs, or ..), I do think it is unfortunate, particularly as this is not a recent development but an apparent longer term trend. Moreover, I don't buy the rationalizations offered in blogs such as Dave's and I don't think you should either. I feel that users of Free software should be aware of the decisions being made and the consequences of them with all the facts on the table.

If you, as a Free software user and/or contributor, care about a coherent experience in which applications, regardless of the toolkit or team behind them, not only merely work but work well together to provide a powerful and seamless experience, then you may want to be selective in which projects you support with your time, effort and usage. Supporting teams that are open and collaborative will ensure that the future of Free software is open and collaborative; supporting teams that are more intent on going it on their own will ensure a future with more fragmentation and wasteful duplication of effort. If projects lose support when they are less collaborative, that will be a strong incentive for such communities to reassess their priorities.

While diversity is great, incoherence is not. It's up to us to support the kind of future we want by voting with our feet.

(.. and yes, I am fully aware that the content of this blog entry is potentially incendiary; but it needs to be said and I've waited a long time for someone else to say it. In the end, I'd rather be flamed to death if free software benefits in the process rather than sit quietly in comfort while we pull the roof down upon our own heads.)

home again ...

2011-03-08T09:28:00.003Z

One week ago today I arrived in Switzerland and moved into my new home in Zürich. There are still lots of boxes to be unpacked (and even lots of boxes yet to arrive from Canada!) and furniture to be assembled, but it is slowly coming together.

I have a wonderful view of the Swiss countryside from my new home office. We are on the edge of the city and one side of our apartment looks away from Zürich, over the school where children play and learn, and out to some fields, villages and forest. As I type this, kids are playing football (aka "soccer" ;) outside and a pair of hawks circle in the distance looking for their next meal in the fields below them as cars and trucks slip past on the autobahn which is just visible amongst the two embankments it runs between.

I've been busy meeting up with (or arranging to meet up) with friends both new and old, so the social life is slowly being established as well. I'm looking forward to all the new sights, sounds and people I will experience here.

Living in a city with history is also a new and exciting experience for me. Cities in North America just don't have things like the ruins of Roman bath houses, which I visited last week in an alleyway in the old town are of Zürich. As someone who has a soft spot for human history, I'm having a great time learning about the foundations and intervening centuries (millenia!) of this, my newly adopted home.

Yesterday was my first day "back to work", so now it really feels official. ;) Besides an ungodly amount of email I had to work through, I also started in on a QAbstractItemModel for libtaskmanager so that we can eventually create a QML version of the tasks widget. Fun. :)

sizing up the field

2011-02-11T18:50:00.003Z

So Nokia has announced a partnership with Microsoft around the Windows mobile stack, as I'm sure you are all aware of now. There have been various blogs and reactions to this around, including on planetkde.org. Reading them, it's evident that there's a fair amount of emotion and not a lot of fact on the ground.

While I have little good to say of the announcement that was made, what remains of interest to me is the level of investment in Qt, the strategic positioning of MeeGo going forward and what KDE's role can and will be as both of those things continue to mature.

Open governance around Qt is moving forward briskly and from what I gather there are some interesting and useful announcements to come. R&D investment continues. However, we (KDE) won't know the full shape of how this will impact our landscape in the mid- and long-terms until we speak more with people at Nokia as well as within the Qt team itself. That's going to take weeks, not hours or days. Pretty much anything said before then is going to be premature and stand an awfully high chance of being wrong. Qt is a big ecosystem with many players right now, and as with any big company making a big announcement sorting out the practical implications is not something done in an hour or a day.

What we in KDE need are calm, stable heads to plot the lay of the land first and then examine how our strategy should be adapted and extended. Change often produces opportunity, but first one has to understand the change to recognize the opportunities. Right now it's infeasible to speak to what the real opportunities and challenges are without first doing our homework.

Discussions with people in "in the know" positions about the relevant issues are happening and, most encouragingly, it seems likely at this point that KDE will be putting a task force together to focus on this evolving situation to ensure our interests are considered and that we can arrive at an informed and intelligent response.

git 'er done

2011-02-05T02:46:00.004Z

I can't believe nobody has blogged this yet, but kdelibs and kdebase are now both in git! There's also been a bit of a reorganization undertaken. Led by our fearless git migration rule writers Ian and Nicolás, we have five repositories where once there were four:

kdelibs (ok, no surprises yet..)

kde-runtime, which used to be kdebase/runtime/

kde-baseapps, which lumps together the file managers and related utilities (like bookmarks editors, kdialog, etc)

konsole

kde-workspace, which used to be kdebase/workspace and now contains all things Plasma Workspaces; yes, that includes stuff like the mighty KWin and KSysGuard. Of course libplasma is still in kdelibs.

Also of note is that the KTextEditor interface, while still in kdelibs, is primarily developed in (and sync'd with) the code in the Kate git repository.

This is setting the stage for a nice opportunity for us to work on the further modularization of the KDE Platform for app devel while also giving the workspaces a clearer and more separate footing on their own.

Judging by the commit rate, it's also making us more efficient already. :) Some "getting used to this new set of tools" accidents are happening, but we've got some great and caring shepherds helping the herd on its way.

The sys admins have, as usual, been phenomenal. Many of us are using this trick to not only make our git clone commands shorter, but to also set up a very clever system in which pulls transparently happen from anongit and only pushes go the slow boat route through ssh. To put the proverbial cherry on top, sysadmin wrangled it so that when something is pushed to git.kde.org is immediately start propagating to the anongit servers. This push approach means no delay for (and thus no collaboration downside to using) the anongit servers. Pure magic.

I hear rumblings of both KDE Edu and KDE Games about to take the plunge as well. Expect lots more repositories which, I fear, will make building by hand a bit more time consuming. The savior is likely to be kdesrc-build or something very much like it. With the XML being generated by projects.kde.org, doing meta-builds (e.g. "give me all the edu titles") should still be single commands and, even better, fully automated as things change in the repositories. (Including interdependencies!) I'm optimistic that this will replace our somewhat hard to get through "how to get started building KDE" documentation we have right now on Techbase with something that takes 10 minutes to install, learn and set running to get a complete build. We're not there yet, but we're on our way!

... if you thought 4.6.0 was good

2011-02-05T02:36:00.003Z

I'm really happy with how the number of bug reports coming in is not a massive deluge of different bugs, but mostly just endless repetition of the same handful. For some of them (like the notifications collapse triggered crash on exit) we're getting several duplicates per day, so we know it's not just because people aren't using or reporting!

Even better than having bugs reported is having bugs fixed, of course. Which is exactly what's been happening in droves. From multi-screen fixes to panel hiding fixes to, yes, fixing that on-exit crash, we're smacking the bugs down as fast as we can so that next month's 4.6.1 release will be beautifully solid.

I'm hoping that the upcoming springtime releases of the various distributions will be able to benefit from this bug fixing spree as well so that users installing the defaults will have a great experience too.

Not that 4.6 is the only thing we're on to these days, of course. I've put together an activities runner (and speaking of activities, here's another nice blog entry on them, this time from Hans Chen) so that in 4.7 you can type thing like "activity" in KRunner to get a list of activities or follow that up with the name of (or start of the name of!) an activity to switch to it. Marco's been working on some Plasma application dashboard love and more QML goodies. We have "Apply" buttons in the Plasmoid config dialogs (shock! shock!). We've also begun in earnest on our 2011 roadmap (well, it actually stretches into the beginning of 2012, but.. details :) and started planning for our next dev sprint, Tokamak V, in the spring.

One thing we already know is that we feel we're on the "right" track with activities now and will spend a significant investment of our resources in 4.7 to fleshing them out further.

Meanwhile, I'm counting down the days until the movers come to grab my stuff to put on a dock so it can go in a boat which can go to the UK which can then drop it on another dock before it somehow, somewhen makes its way to my doorstep in Zurich. I leave here on the last day of the month, and there just doesn't seem to be enough days left. A little nerve wracking ... but very exciting! I can't wait to be in the new place, meeting new people and, of course hacking on good ol' KDE from a new location. One where I don't have to be up at 1:00 am on a regular basis just to attend team meetings. :)

Qt in education

2011-01-28T23:06:00.002Z

I came across a really nice blog entry by Hanne Linaae entitled Teach Qt!. That led me to the Qt course materials and I grabbed a few of the course material sets.

When I settled in to look at the first one I was very pleased to see three things:

They are creative commons licensed, allowing for broad usage

There are PDFs and PowerPoint formats, yes ... but there is also an ODF version in there

KDE is mentioned a few times, including getting its own slide in the intro slide deck with a pointer to Techbase

The course materials look really good and the approach seems solid. Nice work Qt people! :) The more educational materials and documentation we can have around the Qt and KDE ecosystem the better.

four point six

2011-01-26T20:25:00.002Z

another january, another awesome release

read all about it at dot.kde.org

kdeexamples moves to git!

2011-01-25T19:56:00.003Z

My KDE hero of the day is Nicolás 'PovAddict' Alvarez who dove into the KDE Examples module and turned it into a git module, complete with history even of the examples that existed prior to the creation of the KDE Examples module intact! When I queried Ian Monroe the other day about how much work it would be to migrate this module over, Nicolás simply jumped in and attacked the problem with the usual KDE gleam in the eye.

The sys admins were also as usual right on the ball and the server-side stuff was set up very quickly. Did you know that they now have a repository request form that makes it even easier? It's brand new, and I didn't even know it was there until Tom Albers pointed me to it.

The result is that you can find KDE Examples on projects.kde.org and clone it with "git clone git://anongit.kde.org/kdeexamples" or (for read-write access) "git clone git@git.kde.org:kdeexamples".

This module is open for all KDE libraries and applications that wish to offer example code to help other developers get up to speed quicker. If your app has plugins, KDE Examples is a great place to host an example or three. If you publish a library, KDE Examples is the perfect place to show how it can be used. In fact, just last week I used the Attica example in KDE Examples to quickly figure out how to use it for my Hot New Stuff needs. It really works! :)

Something I'm really looking forward to with kdeexamples being in git is that I can now very easily have local branches where I keep variations on the Plasma examples that I use for testing Plasma features while I work on them. These modifications are not usually suitable for pushing to the main repository as examples: usually it's just uglifications and debug spewing to meet my testing and debugging needs. With git it's so much easier to keep all that straight and tidy.

Oh, and the repository now takes 1/3rd the space on disk: 3 vs 9 MB. Win.

thinking about library modularity

2011-01-19T23:55:00.002Z

It'll be a topic at Platform 11, it's a topic that is ever more important KDE developers working on constrained mobile devices, it's a topic that app developers moving to or already using Qt are wondering about more and more: How modular are KDE's libraries?

The short answer is this: more than they used to be .. but with a lot of room for improvement.

We have a growing number of libraries that only depend on non-GUI parts of Qt such as KDECore, Solid and Attica to name three off the top of my head. We have more than only rely on Qt and no other KDE libraries. This is rather better than the "big glop" of libraries in kdelibs in KDE 3.x days. Are we getting the most out of this? Sadly, not really.

Here are three avenues of thought for those of us involved with writing, maintaining and/or packaging KDE's libraries to consider that could help improve things:

Packaging With More Modularity

While most of our downstream packagers tend to split up applications into separate packages, KDE's libraries tend to come in big chunks that reflect the source packages. On OpenSuse, the distribution I'm using, there are two main packages: libkde4 and kdepimlibs4. The both contain large collections of libraries that are vaguely related to each other. The downside to this is that if a Qt app developer wants to use Solid, they end up having to pull in all of libkde4.

Open questions:

What can KDE library developers due to improve this situation through build system or module layouts?

What information or other help for packager would help drive more modular packaging?

What libraries are most worth modularizing into their own packagers for application developers?

Identifying and Justifying Dependencies

Even if libraries were split out more efficiently, there are some interesting limits to that right now due to dependencies between our libraries. In the "pre-4" days we really didn't pay much attention to inter-library dependencies, nor did we have many good reasons to do so. Today, with a more modular Qt, a growing Qt app ecosystem and targets like mobile, we now do have some pretty good reasons to do so.

Let's take libsyndication as an example. libsyndication is the library used by applications such as Akregrator and Plasma DataEngines to fetch and process RSS feeds. It depends on KIO, a library which pulls in a fair number of dependencies with it. If we examine what it uses KIO for, we find out that KIO is used in just one file: dataretreiver.cpp. Within that file, it is used for one purpose only: to fetch feeds over the network, usually (exclusively?) it seems via http. It would be possible to use QNetworkAccess for this instead, which would use KIO in a KDE Workspace, turning KIO into a runtime dependency driven implicitly by the user. Without those few lines of KIO usage, libsyndication would only require KDECore, QtCore, QtNetwork, QtDBus and zlib.

Combined with more modular packaging, this would open libsyndication to a much broader Qt app development audience, with no loss of functionality. Of course, libsyndication is just one example (it came up in an email conversation with a Qt and Gtk+ app developer last night, actually). How many other KDE libraries have similar unnecessary dependencies?

We don't want to sacrifice integration or functionality, but there seems to be a lot of possibility here. How many can we identify? How many identifications can we turn into realized improvements?

To Split, To Aggregate?

Another avenue for exploration is the lines along which our libraries are split. In working towards the first version of KDE Platform 4, we re-arranged the classes in KDECore and KDEUi so that KDECore had not GUI dependencies. This brought a very nice division of tasks between the two. There is so much more opportunity for this, however.

KDEUi itself is an interesting, though highly complex, example: it has all sorts of useful UI bits in it, some of which are applicable to QtQuick applications and some which only make sense to QWidget based ones. Is this an opportunity?

Nepomuk libraries in kdelibs combine both data and user interface elements: does it make sense to split that into two, so more Qt apps could take advantage of Nepomuk with fewer dependencies?

How about libplasma, which has a number of both data and user interface elements in it? It's still an unresolved question as to whether we'd gain anything from splitting out the data elements (DataEngine, AbstractRunner, etc) from the user interface bits, or along which lines such a split would actually happen. It might make more sense to cleave it into "QtQuick-appropriate" and "QGraphicsWidget" parts.

This becomes a balancing act: too many libraries and load times go up; too many libraries and maintenance of the code as well as of packaging and building goes up; too few libraries and the audience decreases due to lack of clear focus and odd dependency chains.

... and more?

There are indeed more topics to mull over, such as the relationship between kde-runtime and kdelibs. What goes into kde-runtime and what goes into kdelibs is pretty well defined these days: build dependencies go into kdelibs, runtime dependencies go into kde-runtime. However, when it comes to dependencies and use cases between these two modules, what then?

Or how about the icons situation: we have a large chunk of very high quality icons .. but do we need to install them all together, or can they be modularized as well, e.g. into "in the icon spec", "also needed by kdelibs", "needed in the workspace" and "used by specific apps"?

How do we best prep the KDE Platform for QtQuick? Several parts of that answer were worked on at the recent KDE Mobile developer sprint, and we have code to show for it. Where do we go from there?

If you are a library developer, a packager or an app developer: what topics related to modularity can you think of?

These are the kinds of questions that swirl around the exciting life and times of a KDE library developer. It's the kind of querying we'll press upon ourselves in the amazing alpine environment of Switzerland's Valais region in June. Our work in 2011 will be tinted by the answers and ideas that sprout out of these lines of thought.

If you've ever pondered getting your hands dirty and your feet wet (or other body-in-substance metaphors ;) with KDE platform and library development, there's probably never been a better time to do so. For the curious, we coordinate most day-to-day development of the libraries on kde-core-devel@kde.org, use the "kdelibs" group on reviewboard.kde.org for patches and hang out in #kde-devel on irc.freenode.net.

For those of us already foot, knee, waist or neck deep in the code, we owe it to our selves, our code and our users to think about the above and take action to push the state of our art. It's a path to more users of our libraries (which also means more contributors!) as well as a way to embrace more of the Qt ecosystem and in turn be embraced right back.

Platform 2011 sprint update

2011-01-19T23:26:00.003Z

I'm helping arrange a KDE development platform sprint that I've been referring to, rather unimaginatively, as "Platform 11". (I admit I've been tempted a few times, in the name of general irreverence, to change the name to "Platform's Eleven" and show up as George Clooney minus the good looks and money. ;)

We have a location for it now as well: Randa, Switzerland. If that name sounds familiar, that's because we held Tokamak III there. It's so beautiful, we just had to go back. Ok, and having Mario offer to host it along with two other sprints helps. (Mario is a superhero of developer springs; I think that KDE e.V. should sponsor a superhero costume for him: Sprint Man! But no capes!) Mario being in Zürich is also a bonus, as it will make it easy for me to collaborate with him on logistics starting in March. The sprint is currently scheduled to take place on the first week of June.

There is the usual sprint planning wiki page for it and the number of people who have already signaled interest is great. I want to see a good mix of kdelibs hackers, packagers, developers and our key partners such as Qt devs there.

What is the goal of this sprint? To lay down a near-future practical roadmap that covers the next 2 or so years of development for kdelibs, kde-runtime and our engagement of the platform ecosystem around us. Getting down to work will also be important, so that we can leave not only with plans but also something to show for it all, even if it is just early steps, in the source code.

The participants will ultimately end up driving the actual topics and direction, let alone the conclusions, but here are the points likely to be hot at this sprint:

Modular, Baby! Did you know Solid only depend on QtCore? What other dependency chains can we streamline? How can downstream packaging strategies shift to reflect these changes so more app developers can take advantage of this progress?

Mission: Platform Profiles In 2010, we began the work of creating target platform profiles, particularly to differentiate mobile, tablet and desktop usage of the libraries. We have a lot more knowledge of the internal and external needs after this early effort, and need to take it to a compelling milestone.

The Orphans of 4.0. Some areas of kdelibs did not get the API and design love they deserved, and other libraries got, leading up to 4.0. KIO is one such library. We need concrete plans for them.

Embracing and Extending Qt Ok, that's a phrase that's most often associated with nefarious plots to do nasty, predatory things to other people's technologies. In this case it's completely friendly, however. We have a number of open questions regarding the role of KDE's libraries and Qt, how to best roll in things like QtQuick effectively without it feeling like a tack-on, how to identify and limit duplication between Qt and KDE libraries, etc. There are many opportunities here to broaden our reach, gift more app devs with ever better tools and help make Qt rock harder. (Relevant to recent bits of news: I've already invited dconf-qt devs to join us for this part.)

If that doesn't sound exciting and challenging to you, you probably aren't a library developer. ;) To me, however, it gives me that feeling I get when at the top of a roller coaster hill: excitement mixed with a little stomach churn. It's going to be an amazing ride.

To get involved, please add your name to the wiki page. If you have already added it, please make sure that it contains approximately how much it will cost to get you there so that I can do up a budget for KDE e.V. to take under consideration. I do need to start adding more meat to the bones of that wiki page as well, and will do so over the next few weeks. I'll keep you all posted.

Oh, and we need a kick ass logo for the event, too. Preferably with a George Clooney reference in it. Ok, maybe not. We do need a logo, though. ;)

Qt acceptance growing, next: colaboration process?

2011-01-18T17:04:00.002Z

As some of you probably have already seen on Mark Shuttleworth's blog, Canonical is embracing Qt. They have even started developing apps in-house using it, such as Unity-2D, which is great.

Within KDE, we've long espoused the idea that the user doesn't care what tools the developer uses and that we should be working to give them the biggest and best choice of applications that work together well. Seeing others, particularly groups who have historically taken rather heavy-set stances that worked against that, start to come around more and more to the idea is good for Free software and our users.

There is still work to be done, however. Mark suggests that Qt developers should start using Canonical's Qt add-on libraries for things like dconf so that Qt apps integrate properly with Ubuntu. This is not that much different from saying that Qt apps should just use Gtk+ for rendering so they fit in better, just doing so at a different layer in the stack.

One of the great strengths of Qt, and something that KDE benefits from greatly, is portability and the wide availability of common infrastructure as a result. We've done a lot of work to make Qt and KDE apps work well on all sorts of platforms. This has taken the form of Qt Platform Plugins, porting Oxygen to other platforms, dialog button awareness, Qt's NetworkAccessManager and much more. Part of the "much more" has also been standardization, of the "weak" sort where it's more about conventions and sharing than strict ISO/ECMA-style standardization, of tools and protocols in use, often aided by freedesktop.org.

To get applications working together as well as possible, the answer is not to start creating Ubuntu-targeted versions of Qt apps, but to work on the issues below the application developer's line of sight. If settings are an issue, then there are two avenues that should be pursued: identification of which settings ought to be widely shared and identification of management processes that ought to be shared. The former can be approached through standardization if nothing else, and the latter is probably a technology problem.

Solving this means working together, not thinking that we are individually capable of coming up with the best ideas ever and that the world should simply bend to our whim of the day. That is a strategy fraught with risk and is socially unrealistic given the number of stakeholders.

There are ways to fill in remaining gaps such as configuration related issues that are well within our combined reach, and which we remain quite motivated to continue to fill in. KDE has led the way in not just helping define standards (including ones Canonical now uses), but adopting ideas from the outside (just look at all the freedesktop.org initiatives KDE Platform 4 uses!), working with others on specs (including things like integrating dbusmenu with StatusNotifiers, something Canonical and KDE worked on together to make happen) and working to improve the mechanisms by which such standardization happens. We're open and wanting to work with others, and Free software users would benefit from as many in the Free software ecosystem adopting a similar approach.

As more groups warm to the beauty that is embodied in Qt, I hope that the message of working together (rather than dictating, for life or otherwise) also spreads. That mode of operation is what got Qt and KDE Platform, as high quality developer tools, to where they are today. It is what motivates us to look at the development platforms we build for application developers and ask ourselves, "How can we make this as painless as possible for the developer while giving them access to as many platforms as seamlessly as possible?" It's a way of thinking that helps create a superior result, and we're always looking for new ways to expand the benefits it brings.

synchrotron update

2011-01-15T21:57:00.002Z

Synchrotron, an OCS-compatible web service that makes it easy for upstream to push application addons and updates to them to users, has reached another couple of milestones.

First, it has its own project page on projects.kde.org and it has moved out of my personal scratch area and into playground. From here, I hope to submit it to the KDE Review process and have it out of playground sometime in February.

Second, the shared sources repository also is up on projects.kde.org and is starting to get populated with addons. I added a README to it so others might be able to figure out how to add their own feeds and addons without needing to find me on irc or by email, and the KDevelop team used that to add a feed for library help files.

This leads to the third update: synchrotron can now be used to point to downloadables that are hosted elsewhere. This was driven by KDevelop's massive qch files which are already hosted on api.kde.org. Instead of duplicating all that in the Synchrotron sources repository, there is a new directive that can appear in the metadata file: X-Synchrotron-ContentUrl. It took all of 10-15 minutes for the KDevelop hackers and myself to figure out what would be a "best case scenario" type solution and all of 5 minutes for me to implement it in Synchrotron.

I'm not done yet, though! Besides working on getting Synchrotron ready for KDE review in the next week or two, I will also be putting up a testing/staging install of Synchrotron for developers to work with and test their apps against. I will probably make it track a branch of synchrotron-sources so that new feeds can be set up and tested live without actually appearing on the shared Synchrotron install immediately. The goal is to have this up by end of Sunday (tomorrow) my time (PST).

The README file currently in the synchrotron-sources repository will eventually be transferred to Techbase in the Tutorials area, but I'll hold off on that until I've found a permanent home for a shared KDE Synchrotron. I've already had some offers for homes, but I want to coordinate with KDE Sys Admin first.

If you have an application hosted in KDE's svn or git and would like to take advantage of Synchrotron, please simply add an entry to the synchrotron sources repository. There's no need to ask for permission to get started, but I'm always around to answers questions you might have.

Also, if you'd like to hack on Synchrotron itself, we'll have a review board install for it up very soon, but even now I'm happy to receive patches by email. There's a TODO file in the Synchrotron repository with a number of things that can be tackled.

Finally, Synchrotron isn't KDE specific in the least, nor does your KDE app have to share a Synchrotron with every other KDE app (having a shared install is really just more for convenience). It's rather easy to set up a Synchrotron instance somewhere, as the INSTALL file in the Synchrotron repository outlines, and all you need on the other side is something that speaks OCS. For Qt applications, the easiest approach is probably to use libattica, but rolling your own shouldn't be too hard, either.

Enjoy. :)

plasma desktop scripting API updates for 4.7 release

2011-01-15T21:44:00.002Z

I've been adding useful bits of API to the Plasma Shell Scripting with every release since it debuted. The Plasma Workspaces 4.6 release slated for this month will have "API version 3", which is backwards compatible with all previous releases and adds the following:

theme: read/write string containing the name of the desktop theme to use for the interface, e.g. default, Air, Oxygen, etc.

multihead: read-only boolean, true if the system is running with multiple screens in a "Xaphod" multiple display server configuration

multiheadScreen: read-only number which, if multihead is true, contains the (real) screen id of the current screen

Not tremendously exciting, but that's because we don't add random bits of API hoping that they could be useful to someone, somewhere, sometime. When we find new use cases, either due to our own use of the API or because someone else who uses it (e.g. distro packagers, power users...) sends us an email or files a feature request, we examine them for validity and how best to service that need.

Even though 4.6.0 isn't out yet, we already had a backlog of items for 4.7 since we got a small raft of requests after the feature freeze for 4.6. I implemented them all over the past few days, however, so API version 4 will also include:

boolean applicationExists(String name)

mixed defaultApplication(String kindOrMimetype [, boolean storageId = false])

String applicationPath(String name)

String dataPath([String type[, String path]])

Array[String => Array[String]] knownWallpaperPlugins()

As usual, they are all documented in full on the Plasma Shell Scripting page on Techbase.

Those following development in trunk can try out the new API right now and feedback is quite welcome. If you have a use case that isn't being met by the current API, please let us know sooner rather than later so that I can schedule them for the 4.7 release.

light up the synchrotron

2011-01-05T21:05:00.003Z

There was quite a bit of constructive feedback from my blog posting the other day about Synchrotron, my recent pet microproject to make it easy to create and maintain OCS feeds for application addons, and so I thought I'd spend a few minutes sharing some of the feedback and thoughts with you here.

Let's start with the whimsical: Parker Coates suggested this song by Canadian alt-rockers Carbon Dating Service as the theme song for the project. Who knew there'd be a song called "Light Up The Synchrotron"? Awesome.

On a more serious note, some asked as to the security of the service. Well, it's pretty simple: All data sent back in response to requests comes from the PostgreSQL database. All requests are written to be safe against things like SQL injection. If someone managed to find a way to do something untoward with the SQL queries, the scripts that power the public API use a database user with read-only writes to the database with one exception: it can insert rows into the IP access time log table. This (nearly) read-only user can not delete or update anything in the database. PostgreSQL just rocks in how easy it makes to add and manage a layer of security right inside the databas itself.

Other than this database access, the public API scripts do not touch the filesystem at all. So I'm pretty comfortable with it, though I'm still very much interested in people actually looking at the code, however, to ensure everything is indeed in good shape.

Speaking of which, I forgot to mention that there is a TODO file as well as some sketchy documentation in the repository in case you are wanting to get started on something. We also started up the respository for the actual addons where we are starting to collect items.

A few people asked if Synchrotron could replace kde-look.org or kde-files.org and the simple answer is: "no". The reason is that Synchrotron is not meant to allow for uploads and sharing of content by users. It is quite specifically an upstream tool. It's designed to make our lives as upstreams as easy as possible, in fact, but this makes it rather useless as a public file and data sharing hub. In theory it's possible for Synchrotron to be extended to be such a thing, but I have zero personal interest in that. :)

Something I do have interest in is using Synchrotron as a component in some larger projects that have been waiting for attention for a while, such as Plasma Classroom. So I do hope to reclaim the ~2 days spent on this project many times over.

Finally, Josef Spillner pointed out to me that there is the Hotstuff project that he started back in 2004 that strives to do some things similar to Synchrotron. Indeed, this was the project that helped birth the whole Get Hot New Stuff feature that can be seen in many KDE applications today. Sadly, I wasn't aware Hotstuff was still active and a viable candidate, as the last time I'd had a discussion about it I was left with the impression that the Hotstuff server wasn't really being kept up. Hotstuff is written in Perl, which is even less my language than PHP is, and is significantly more complex (and so probably does all kinds of nifty things Synchrotron doesn't); I'd probably still be struggling away by now instead of having something that works if I'd tried to go with Hotstuff. Still, Hotstuff is an interesting bit of software, it's been there for quite a while (nearly 7 years!) and Joseph is still interested in the Hotstuff code. So if you find Hotstuff to be something more like what you need, please get a hold of Joseph! :)

For that matter, if Hotstuff gained the features of Synchrotron and was easy to install/maintain, I'd probably drop Synchrotron for it myself. Necessity, however, is indeed the mother of (re-)invention. ;)

fire up the synchrotron!

2011-01-05T01:17:00.004Z

Over the Christmas holidays, I spent some time coming up with a solution to a new challenge we have been running into in Plasma, and which I suspect other KDE teams may be as well: quick and easy deployment of application addons.

An Overview of the Problem

An increasing number of Plasmoids are relying on web services that we don't control: share (nee, pastebin), weather, public transit, remember the milk, etc. etc. When these services change (which they do randomly, web developers seem to have very little awareness of service stability) our users get stuck with Plasmoids that don't work. We've been working on making the Plasma components that rely on such webservices scriptable so that it would, at least in theory, be easy to post updates that anyone could install on their system. Artur recently made the share DataEngine use Javascript for this, just like the comics and some other DataEngines have done for a while.

Similarly, we've been adding more and more scripting options and features in Plasma Desktop and Netbook. KWin is now quite scriptable (why isn't that blog entry on Techbase as a tutorial? :), and the Plasma Shell Scripting now supports "snippets" that are stored in nice little packages. This isn't unique to Plasma, either: Kate, Amarok and many other KDE applications have also gained similar scripting support.

Problem is: we don't have a good way to distribute these add-ons. There's opendesktop.org, but there are four major downsides:

Creating a new download type (e.g. a feed for share DataEngine backends) there means making a request of the opendesktop.org crew; they are usually quite responsive, but it's still one more set of human roundtrips

Anyone can post additions there and there is no way for an upstream such as Plasma to approve select items

It, understandably, remains a manual process where one has to package the results up, upload them, etc.

It is driven by non-free software

Even without the last matter, the first three practical matters are not great and probably not easily solvable. opendesktop.org is meant to be a social networking driven community creation site, and it does a great job of that. In this use case, however, that just isn't what we need or want.

My dream solution

So I sat down and sketched out what my dream solution would be, namely:

A git repository to hold the add-on files

A simple config file in the repository in which I could define feeds

Open Collaboration Service compatible feeds automatically created from this, so it can be used via knewstuff (aka "Get Hot New Stuff")

This would make the workflow to start a new feed for the share DataEngine (as an example):

Edit the providers config file in the repository with:
[org.plasma.share]
compression=zip
packageSuffix=.plasma-addon
metadata=content/metadata.desktop

Make a directory called "org.plasma.share" in the repository

Commit the addons in org.plasma.share, each in their own sub-directory

Push the changes to the main repository

Adding a new addon would mean adding a new directory and committing. Updating an addon would mean editing the files and committing. Simple, easy and fits the development workflow we have seamlessly: it's the same way we write any of our code.

Synchrotron

I carved out a few days to work on this idea and finished up the last bits today. I called it synchrotron. It goes with the whole particle physics naming theme in Plasma and sounded like something out of an awesomely bad sci-fi movie. Win-win, really.

You can find the code, currently in what I'd consider to be "alpha" state in my scratch space on git.kde.org. (I'll be requesting a move to playground and starting a review so that it can be moved somewhere more permanent later.)

Synchrotron consists of:

a PHP script that scans a local clone of the source git repository and builds feeds, packages and a database cache (currently using PostgreSQL) of the providers and content

a set of pretty simple PHP scripts that power the (minimal) OCS feeds, allowing for listing and downloading only (no voting, no uploading, etc. supported)

All in just a hair over 2,000 lines of code, not that I tried very hard to keep things minimal, though. Huzzah!

Now I just need to get some code review, put it all on a KDE server somewhere, start the source git repository and start having fun.

The path forward

If you found yourself thinking, "I could make that so much better!" or "I could totally write a bit of PHP for that item in the TODO file!", please don't hesitate to get involved. Send me patches, clone the git repo and get hacking .. I am not a web developer and PHP is not my specialty, so I'll be the first to admit that there are problem a bajillion ways to improve on what's there. Some features, like i18n for names, simply aren't implemented yet.

If you found yourself thinking, "I could so use that for my KDE application!" please get a hold of me by email or on irc and let's coordinate. I think KDE Games, KDE Edu, KWin, Kate, Amarok and who knows how many other KDE application teams could benefit from something like this, and I'd love to share an addons repository with all of them! :)

There are some interesting possibilities for improvement in knewstuff, too. For instance, it would be great if the Share Plasmoid could check on startup for addons in Synchrotron and either grab them automatically or offer to. It would also rock to be able to check periodically for updates to installed addons and have them drawn down automatically.

So in some ways Synchrotron is just a beginning, even though its functional already on my laptop and does what I set out for my "dream system". If you're interested in helping out, don't hesitate to clone the repository and get in touch.

Right now, though, I'm off to make some dinner before popping off some requests to KDE's sys admin super hero league to get the Synchrotron spinning. :)