the fun in banging our heads together

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

Read More

platform ho-ooooOOO!

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

Read More

shoot the messenger

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

Read More

panel hiding

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.

Read More

battling misconceptions, even within KDE :)

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.

Read More

collaboration's demise

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

Read More

home again ...

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

Read More