a rose by any other name

Preamble

I'm going to share my thoughts on Calligra in this blog entry, but I am not a member of the Calligra team. I do follow the mailing lists, and have spoken to several of the people involved over the last year about the various situations. This affords me a somewhat special viewpoint: I'm fairly aware of what's been going on, but not directly involved.

Normally, I wouldn't feel compelled to write anything about it, but there have been a few attempts to provide some analysis on the situation by people outside of the KOffice community. Let's just say that these attempts have been less than impressive, full of speculation and short on fact.

Some Factual Information

So, let's start with some facts: KOffice has experienced an internal fork and in the process has been renamed "Calligra". The fork itself came about through unresolved differences between a member of the KOffice team and the rest of the members over how to manage both long term targets and day-to-day development. This eventually resulted in people coming to the conclusion that those differences were not only unresolved but also unresolvable. To call a one person schism a fork may seem a bit overly dramatic, but that's certainly how it felt to those involved and was not a triviality. Coming to a fork, the rest of the KOffice team took the opportunity of change to rethink various aspects, including the name.

What's in a name? Well, certainly not the quality of a product. It does, however, impact two important things: what people expect from it and what those involved in creating it aim for. It's psychological in both cases, but can have important affects. For a project with a storied past such as KOffice, it seems that the symbolism of changing the name to something new, something that sounds more elegant is significant.

The level of activity around Calligra has been terrific, both leading up to the moment of the fork and rebranding as well as afterwards. There is new energy in the project, and that's a good thing. It may even be viewed as a good turn resulting from a series of sub-optimal choices.

The biggest challenge laying ahead for the people working on Calligra is going to be building a healthy, dynamic community with real leadership around it and a coherent vision under it. In other words: the challenge is to tap the momentum before it dissipates to improve on the foundational issues that KOffice struggled with.

I have faith in my fellow KDE people, and I wish them the best in this.

Where Now?

Future direction is something that the Calligra team will need to communicate clearly over the next weeks, and that will need to build into a visible foundation for where it is going in the long term. What is obvious right away is that Calligra has a dual focus: desktop and mobile. That creates a significant set of design requirements in terms of user interface capabilities and footprint.

Done right, Calligra could become another WebKit, but for documents rather than HTML. It has many of the same characteristics KHTML did back in the day: it's light weight, it's got a number of compelling features, it's flexible and easy to hack on relative to what else is out there and it has the start of commercial adoption.

There is an additional wrinkle here, of course: not all of the Calligra apps are going to be suited for mobile due to the form factor. I expect to find Krita on my desktop as a serious work tool, but not on my N900 due to the tiny screen size if nothing else. Krita on a tablet sounds fun and useful, though.

To really get the most out of Calligra, it would be a tremendous bonus for me to be able to use apps with the same behind-the-scenes engine on my desktop, tablet and smartphone. It's similar to Plasma in this way, only that where in the code the shared-versus-abstracted division starts is a bit different. For Plasma, it's quite high up in the stack allowing for large reuse; this is important as Plasma is meant to be used to create small apps (Plasmoids) with. For Calligra, it's probably going to be deeper in the data and logic handling code, with the user interface being the point at which divergence occurs.

Due to applications like Kexi firmly anchored on larger screen sizes, I don't see a significant shift away from the desktop, but expect this to result in a growth of scope rather than a simple shifting of it. This is good news for everyone using these applications, though it presents some new challenges to the Calligra team both in terms of logistics as well as technology.

It's early days, but I can already see where Calligra could go with this .. and it's an exciting set of possibilities.

Read More

multihead saga continues

I received no testing feedback from my last blog entry about multihead improvements for Plasma Desktop, which underscores the challenges we face with multihead support very nicely.

In any case, today I went through plasma-desktop and moved all the relevant code over to the new solution and committed all the changes to trunk. In theory this should improve plasma-desktop on multihead even further, with things like moving panels around with the mouse working as expected and what not.

Again: in theory, and I can't stress that enough. For those of us without multihead, the changes make zero difference as in the non-multihead case they are just small detours in the code that lead to the exact same calls that were being made previously, so there is quite literally no way of testing this beyond "Hey, it compiles, let's commit that." To know what the impacts are, we need people testing this.

These changes will not be a part of the 4.6beta1 release, but they should be part of beta2. Please install and test that if you have multihead and let me know how it goes.

Read More

20 years ago, a story

(Note: This is not KDE or F/OSS related in the least, but rather a personal reflection on a musical work that I find a lot of meaning in and which I realized only tonight was experiencing its 20th anniversary. Feel free to skip this one, but I felt compelled to write about it. :)

In 1990, an amazing piece of modern art was being created out of the ashes of grief. What made it beautiful was not only the qualities of the finished work, but what inspired it and drove its creation. A landmark in the art of the generation, it became a punctuating moment, an ellipsis between what was and what was coming.

In that year, two young musicians were sharing an apartment in the city, which is in itself a completely unremarkable event. They were both front men for local bands who were starting to enjoy touring successes. As friends and roommates, these creative minds shared the journey of finding a way to make a living doing what they loved. At the end of winter, in March, their paths separated dramatically.

One of them had become addicted to the musician's drug de jour: heroin. On the very day that his roommate returned from a road tour with his band, he died of an accidental overdose. Such losses of creative souls to the drug was becoming a disturbing trend, and this was just one more ugly notch in its belt.

The surviving roommate was set to leave again and go back out on tour in just a few days. With the black cloud of his friend's death following him while on tour, he turned to what he knew in search of solace and wrote two powerful songs in memory of his friend. When he returned home, he approached the bandmates of the deceased and suggested they record and release those two songs as a tribute, and perhaps even find some closure in the process. The idea grew and they started writing more songs together, eventually producing an entire album's worth of material: ten songs in all, each amazing. What a fantastic way to deal with such a horrible experience: to create something beautiful and lasting, something that caries meaning and memory, that heals as it commemorates.

While creating the album and its material, the now singer-less band went in search of a replacement and along with it a sense of new direction. They found a rather amazing person to fill those shoes before the tribute album was complete. In fact, he (famously) joined in on back-up vocals on some of the recording sessions and sung co-lead on one song on the album. It was, in retrospect, such a perfectly seamless bridge over such troubled waters.

They released the tribute album in the spring of the next year and went on their separate creative paths. Both bands recorded new albums, toured extensively and rose to fame, fortune and acclaim in the process. The band with the new lead singer would rise meteorically, in fact, and crank out album after album of songs about human passage with great success, even though they often did so in a manner that was stubbornly industry-uncooperative. They also created one of the most enduring, large and active fan clubs for a band in recent times. The roommate's band would also become a house hold name, thought it would take them a few more years to do so before eventually breaking up, after which the singer carved out a successful solo career.

It was their musical successes of the early 90s that ended up bringing their tribute album, and with it the story and memory of their friend, into the limelight. After their breakthrough debut album, people wanted more and they found it in this obscure piece of work that had been released earlier the same year.

The tribute album definitely stands on its own merits, however: the inspiration and energy can be experienced in every word and every note. They had erected it as a doorway through their grief, and on the other side success fueled by their profound musical expression was to be found.

Perhaps it sounds like a movie script or a plot from a novel, but this is precisely makes it so amazing: it actually happened just like that. The creative dominoes that led to a great piece of modern art were tipped, and now it sits there for any one to find and listen to twenty years later.

In fact, I still find inspiration in the music and what it communicates even though I've listened to it countless times. For me it is a testament to the healing that can be found in a creative endeavor. It also serves as tangible evidence that fantastic yet true stories are unfolding in this world around us, probably far more often than we expect. It is so easy to become jaded and to start thinking that such events only exist as the products of our imagination, floating about in the words and images and sounds of art. But these events are as real as they are profound. They underwrite our musings, forge our imaginations and are the bedrock upon which we lay our art.

They are not just products of our creation, but cause us to produce great things.

Read More

KDE and web developers

KDE contributors are typically not web application people. Most of us can create something resembling a web app when push comes to shove, and we have some shining exceptions to this in our community such as the stellar KDE Forums, the ever improving kde.org family of sites, identity.kde.org and the increasingly useful, but sadly still powered by a proprietary code base, OpenDesktop.org.

(The OpenDekstop.org situation is something I truly struggle with given my personal ethics with regards to Free software and what I feel KDE stands for. The people involved know this and have their reasons, which I don't agree with (for what it's worth), for the current state of things. This is not what I want to write about here, but I am not comfortable with appearing to be in tacit approval of the state of that.)

What I want to discuss is the open-ended question of: "Can the KDE community grow to also encompass a web development component?"

What do I mean by a "web development component"? Well, increasingly our applications use services, but not all services we'd probably find useful are available out there randomly on the web. For instance, I'd love a way to manage the queue of user contributed data addons (scripted Plasmoids for Plasma Desktop, widow manager scripts for KWin, puzzles for Palepeli, routes for Marble, etc.) before they are set to appear in the "Get Hot New Stuff" user interface.

Then there's the issue of "things that would make KDE function more efficiently", such as a development sprint manager. Right now we use a wiki and lots and lots of copy and pasting, manual editing and pestering of people to plan and run a developer sprint. My dream solution would be a simple bespoke web application that uses identity.kde.org for authentication and provides a set of forms for someone to start the process of setting up a developer sprint (KDE e.V. board could even get an automated email notifying them of this), allowing people to register their interest in attending (a single simple form plus their identity.kde.org account should suffice) and provide a simple web form to record the results of the sprint for use in Dot stories and KDE e.V. quarterly reports. Back when we did a handful of sprints a year, it wasn't a big deal to do all this "by hand", but now that were doing dozens every year it's getting to the point that some level of standardization and automation would be most welcome. The process is pretty well documented on commuity.kde.org these days, it "just" needs to be made into a web app.

Unfortunately for us, I don't see any external web application project whipping up such a thing on their own. We're one of the few F/OSS communities that drives so much development through such sprints month after month, so the audience for the app is fairly limited, though I do believe we're starting to see more F/OSS communities picking up a similar model that would also benefit from such software.

I also don't believe that it is reasonable to expect these works to spring up out of the web-developer-poor soil of the current KDE community. What web focused people we have are already amazingly busy doing really important things.

Then I look at communities in KDE like KDE Games or KDE Edu. These are tight knit bands of developers who work on very specific topics and who have their own home grown sets of expertise. Is it beyond imagination that one or more similar groups could form around the idea of creating web based applications that are written with KDE applications (on mobile, desktop, whatever) in mind and/or the needs of the KDE community itself? Is it possible that one day some intrepid individuals with the web developer spirit and skills would start Just Doing It and build up a whole new area of the KDE community, just as our artists did some years ago for visual design efforts?

I don't know the answers, nor am I in a place to attempt to explore them in full. I just know the needs exist and the questions are there to be asked. Discuss ... :)

Read More

multihead plasma desktop needs YOU!

Multihead, where there is more than one physical screen and one X server per physical screen (not to be confused with xinerama, xrandr, mergefb, etc.), and Plasma Desktop is getting into a rather usable state thanks to testing and feedback from users with those systems that goes beyond "it doesn't work". Thanks to the digging and debugging work of several individuals, my "coding in the blind" has produced finally produced useful results as of the 4.5.3 release. There are still some KWin issues, apparently, but plasma-desktop is pretty well there.

Today I added a boolean multihead variable to the Plasma Desktop Scripting, and yes it is documented. This allows scripts, should they need to, do different things in a multihead setup.

There are some unique annoyances with multihead, though. For instance, when enumerating the screens with Kephal it will report that there are N screens, but each the origin point of the geometry of each screen will be (0,0) meaning that it looks like they overlap, even thought they don't. This leads to some awkward behavior both in the initial layout set up as well as things like repositioning panels on screens other than the first one. Nothing fatal, but not optimal either.

An approach occurred to me today that might make this easier to handle: make plasma-desktop's Corona "lie" when in multihead mode and say it has just one screen and map screen "0" to the real screen id transparently behind everything's back. It's a bit of a hack, but so is multihead. ;)

I have no idea how well this works due to not having a system to test it with, though in theory it should be an improvement. What I need are people with multihead systems who are running trunk to try this patch to plasma-desktop and report back what happens. I expect that it does nothing for the panel moving issue, but other things should improve or at least not degrade. If that is the case, then fixing the panel moving issue becomes trivial by extending this approach there as well.

Please test if you can and let me know on plasma-devel at kde.org or in a comment on my blog here. Cheers.

Read More

articulation

"Articulate" is a fascinating word in that it captures a very fundamental idea related to connectedness, harmony and flow. A person can speak articulately, and they can successfully (or not) articulate an idea. A mechanism can be articulated, such as the human hand or the links on a chain. Likewise, ideas can be articulate in how they are connected to each other. This also allows us to say that a painting or a philosophical position is articulate.

Among the 250 to 750 thousand words estimated to be in the English language, only a small and hallowed few contain the essence of such a fundamental idea that it pops up so profoundly in so many contexts.

I have a fondness for the word, if that wasn't already apparent by this point, and it has a lot of personal meaning for me. I relate to the word in terms of speech and writing, two things I enjoy doing and which I have practiced for most of my life. I also associate the word with how my life has been put together, its articulation.

I keep expecting after that passing of each year that it will be the one in which unique surprises and new plateaus start to thin out and become the exception rather than the norm. Over thirty five years in to this existence of mine and it hasn't happened yet. The punctuation marks in my life have come in an unusual stream with fewer comas, semicolons and periods than one probably should expect. Rather there's been a fairly steady series of short loud phrases mixed with questions of unusual severity that have combined to create something like a Jackson Pollock canvas. Not that I would change anything. The path we each walk is the one that leads to where we are, with no other path leading to that point. It is a process that is sacred in a way that requires no deity to say it is sacred for it to be so.

It's been a pretty amazing ride at times: I've had the privilege to live in what can best be described as "magical" places. I recently heard one such former home described as being "idyllic" during the period that I happened to be there. (To be clear: it obviously wasn't idyllic because I was there, but I had the opportunity to experience that.) I was blessed to have met two particularly amazing people who played roles in my life that my parents probably should have, and I had a sister who watched over me with her heart and her being. I have had the opportunity to love great loves, though none greater than the love that found me in the form of my son. These are among the experiences that I cherish.

The universe likes balance, however, and there are stretches in my story that I would not have chosen for myself. Every mountain leaves a valley, or as Eddy Vedder wrote, "I have faced it, a life wasted. I'm never going back again." I've lived in places and experienced moments far less than idyllic. Yet while life has been unpredictable and untamable, it has also been alluring and rewarding. It has held me like the ocean does a ship.

Today is the usual. I'm in the midst of a confluence of events that in combination have been taking all the attention, energy and resources I can provide. I am embroiled in a custody battle for my son so that he may accompany me to Zurich, something that would be amazing for him and which would provide a continuity to the last three years of he and I sharing an abode together. Regardless of the outcome, I am moving to a new the place that will become my home from which I can do that which I do, and a place where I will be doing something quite specific that I had honestly not foreseen for myself even a couple years ago: getting married to a rather wonderful person. That she is half-way around the world from me seems to make it all the more fitting. As all this swirls in the now, I am looking forward to this future that begins at the end of winter, even if the right now is proving challenging to walk through.

Those who may have been wondering at my relative absence from some of my usual haunts (irc, for example; personal business projects for another) may understand a bit more of the why. I feel rather poorly about things like "Project Elegance" not getting lift-off (especially after the work some of us put into the foundations for it), but such is life and I know that there will be space later for all of this.

Last night I poured myself a hot bath, added some gently scented oils, lit candles and turned off the lights; I cracked open a new (for me) book that is turning out to be brilliant (he says, only 85 pages in) while listening to music sung by people with perfectly imperfect voices, voices they used to present our collective souls through. Most simply, and profoundly: I breathed. It's easy to forget how fundamentally useful it is to do that task well. It was cleansing, literally and otherwise, and the thinking has been denser and clearer since.

Thoughts have been turning around and around during and after, pondering the articulation of my life. I thought about those I've spent time with in the past and those who are part of my life now. I thought about how I am using my existence.

Among other things, I started drafting some thoughts about articulation within the context of KDE. That is for another blog entry, however. We have much to do.

Read More

commonality and community

Jono Bacon, Ubuntu community manager for Canonical and Heavy Metal Thrash Machine, has just put up a website he named OpenRespect. It's an interesting read, and I do encourage you to go read it because I think there are some really good points made in it, in particular this bit:

"When we place respect at the center of our interactions, we enrich our lives, discover new ways of thinking, and expand our horizons with new ideas and experiences. When we remove this respect, our conversations suffer, which in turn makes our community suffer, and this ultimately risks our ability to bring our message of freedom and openness to others."

Words to live by, no doubt.

Jono asked if I'd be interested in becoming an "OpenRespect Advocate", which means my name would appear on the website in support of the text and I would generally go and tell others about it to spread the meme and support for it. Not entirely unlike what I just did here, I suppose. However, I declined to sign on as an advocate of OpenRespect. Horrors!

Wait .. what? Didn't I just use the phrase "words to live by" right before "I declined"? *confused look*

Simply put, here's how I feel about it: the statement is great for people within a given community (any given community), but I do not believe it to be applicable between communities as written. With something like respect, if you set up a set of non-applicable aspirations, it will only cause more problems than it solves.

It's perhaps quite counter-intuitive that promoting respect could result in anything but good things, but it comes down to what community is, how respect works within that context and the assertion that everyone who is "creating software, content, and culture that is freely available for others to share, enjoy and enrich their lives" is part of a single community. Are we?

Community can be described from the individual's point of view as a combination of membership, influence, integration, fulfillment of need and shared emotional connection. This is not my formulation: it's what the social scientists have told us. There's a nice article about the sense of community on Wikipedia, if you're interested.

This means that despite the fact that I am most certainly involved in creating artifacts of Free culture and that I personally identify as being part of a few communities that have Free culture as a central concept, I am still unable to state that I am a member, have influence in or am influenced by, am integrated into or share an emotional connection with the vast majority of Free culture communities out there. Why is that?

Community is a deeply valuable thing. It's valuable because it is based on a richness of investment that takes the form of trading of goods between people that are both tangible and intangible. The key word there is investment, aka "value". Like most resources in my life, I only have so much to invest and therefore I can only truly be part of so many communities. I can slap my name on as many Free culture products as I wish, but I'll still only truly be a part of a small number of communities.

Hold on, though! At the same time, I do deeply sympathize with other Free culture communities and (nearly) universally empathize with their efforts and goals. This is because there are commonalities between these communities. Jono hints at this when he says, "Together we believe that freedom is good. We believe it helps people do good things, make better choices, and lead safer and more secure lives." It is tempting to try and paper over boundaries between communities by emphasizing such commonalities. This does not, however, change the reality that there are many different communities. Empathizing with commonalities is not nearly the same thing as community.

Why does that matter? Here are some reasons I can offer:

• Respect is communicated and earned in culturally specific ways


• Assumed respect fails where earned respect holds up


• Respect does not actually equate to better treatment


• Respect operates under different assumptions within a community versus between communities

Let's drill down a bit into each of those assertions.

Respect is Cultural

I've traveled through a fairly significant number of cultures, and lived for periods of time in a few different ones. One thing I learned in doing so is that people are more alike than different. I also learned that culture changes how we communicate just about everything, including respect. It also influences how we gain respect and display the things that we do or have that earn us that respect.

One of my favorite personal stories about this involves sitting a table discussing business issues with a German fellow and some North Americans. Both started demonstrating their respect for each other in conversation, but in short order the German had been too blunt for the Americans in sharing his viewpoint on the topic at hand and a dispute arose because of it. My German friend was actually acting out of his sense of respect for the others at the table: he felt they deserved only his true feelings on it, and he delivered them openly without any emotionality behind it, just the facts. My American friends were shocked by this as "obviously" he couldn't muster the basic courtesies anyone who had a shred of respect and dignity would! They told him so, though as only (at least in my experience) a good American can. ;) This was deeply shocking to my German friend at the table. Who was not showing respect to whom? Both thought the other party wasn't. Truth is, both were trying to, but culture got in the way.

I've also traveled around the Free software ecosystem quite a bit and to a lesser extent the larger Free culture world. I've come in contact with various communities within those spheres and have found that the cultures in those communities are just as varied, and entrenched, as the geographical ones. Some are soft and put listening first and foremost; some relish creative flair above all else; some respect hard criticism; some demand rigor while others look for nuance; some come together and have a big fight before embracing each other again (often "in their own way") over issues that other communities will sit back and become introspective over instead. There is huge variance, and this has led me to realize that there is huge variance in what respect means between these communities. You earn it differently, you display it differently, you act based on your respect differently depending on the community.

So asking for respect between people of random communities doesn't work very well unless you first step back and define what is meant by that respect. Jono's definitions include the highly cultural subjective terms "quality and content of discourse", "civility", "sharing", "persecution", "honest", "polite", "sensitive" .. all highly concepts whose definitions are highly cultural.

Therefore within any given community, I think what Jono wrote is excellent material. Unfortunately, we are not one culturally homogenous community, we are many communities with a high degree of commonality. Unfortunately, it often turns out that communities with large amounts of similarity often end up polarizing around their differences much more so that people from communities with larger differences. Democrats and Republicans in the USA are the example de jour. It is glib to hope, due to the cultural underpinnings of respect, that urging people towards the abstract notion of respect is enough.

Assumed Respect is to Earned Respect as Glass is to Plexiglass

When I meet someone from the Free culture ecosystem, I assume a level of immediate respect about them. This is because I know we have similarities and commonalities due to our expressed interests in Free culture. So there is an immediate affordance of respect and understanding, something I certainly don't immediately feel to someone who is, for instance, openly lobbying for software patents. This respect, however, it speculative: I am speculating that there is reason to respect this person because of the commonalities, even though I don't know many specifics. Speculative respect is a cheap commodity, however, and like a glass window can be broken fairly easily. (Something I used to specialize in as a child. ;)

It is understandable why it is this way: there is no real foundation for the respect, and so if there is a hint that the assumption is wrong, the feeling of respect can quite quickly turn to feelings of betrayal. We rarely feel we have misidentified the other person, rather we tend to assume they misrepresented themselves. This often feels like being lied to, and that calls up feelings similar to those engendered by betrayal. I've witnessed people being treated absolutely horribly as result of this phenomenon.

If we remove the cultural underpinnings of respect and with it an earned foundation for that respect, we are left with only assumed respect.

Respect that is earned through culturally relevant means (e.g. specific actions, assets or behaviors) is much, much stronger. It can withstand misunderstandings and even actual instances of betrayal. It can give two aggrieved parties the opportunity to put aside other feelings and readdress their relationship, work through issues. As such, it is an amazingly powerful mechanism by which to modify our behavior to one another, much as Jono describes in his OpenRespect statement.

To think, however, that we can use assumed respect in the same manner is a false hope. The problem comes if and when it fails to prevent a problem due to its brittle nature. At that point, we then deal with the overly negative feelings that may never have existed if we didn't start with the required assumption of respect. It is therefore my experience that when bringing people together from different communities to encourage the creation of respect rather than ask for the assumption of it. Mutual respect is indeed always the goal, but without the fabric of common community and its culture to hold it together, one is served well to start a step back from there.

Respect is a modifier, but in which direction?

Respect (or lack thereof) moderates behavior, there is no doubt about that. How it does so is dependent on the relationship between the people involved, however. Put another way, the effects of respect on interactions is only predictable if given the context of the involved parties.

For instance, I may respect an opponent that I face off against in a game, but that may result in me playing harder and with a more ruthless strategy against them than I would against someone whose skills I respect less. In fact, in situations where there is competition at play, feelings of empathy are more of a powerful way to get equitable behavior out of people than respect is.

Let's be honest with ourselves here: there are many instances where Free culture communities compete with each other. The competition can be for monetary resources at the most crude level, but often they involve competition for minds, hearts, attention and "superior" results (which is another qualitative, culturally dependent term). As such, encouraging respect as the driver in such situations may not lead to more equitable behavior at all.

I have seen this time and time again in the Free software desktop world, where one project will use highly political means to attempt to "get one over" on another project. For some projects, this becomes the modus operandi for dealing with other projects (other in general or just for specific "outsider" projects). The lack of empathy between the communities coupled with a deep respect for the capabilities of those same communities has led to many unnecessary and, quite frankly, stupid struggles. I have a whole bag of fun GNOME and KDE stories that follow that plot line. We've gotten quite a bit better over the years, though sometimes old demons raise their heads, and those advances have come through a mix of empathy building exercises and appeals to self-interest by making the argument for "only together we can". Respect hasn't really been a positive factor, nor has it been lacking. There have been lots of polite, respectful conversations and agreements and lots of mutual admiration for various achievements in times when the results or actions ended up not being equitable.

What I'm trying to say is that respect is an important thing, but it's not enough on its own. It is often not even useful as a primary driver. Empathy, shared assumptions, protocols to build the interactions we seek among other tools are as or more important.

Respect, Inter- versus Intra-community

I immigrated on the day I turned 12 to a rather different community compared to the one I had lived in up until then. I went from part of the visible majority (fair skinned people) in a stable middle class environment (rural West coast Canada) to being a visible minority (white in a predominantly Polynesian and Asian community) in a community with many struggles (drugs, gangs, violence, visible racism, visible poverty). Both communities I lived in had their dark sides, and both had their amazing sides. I feel privileged to this day to have been able to a part of both of those communities.

In both, respect was expected and in evidence everywhere one cared to look. But I learned something from being dropped into another community like that: I could not demonstrate my honest respect for others in my new community the way existing members of the community could to each other, and I couldn't use the mechanisms of respect from my old community verbatim in my new one. I was not yet part of their community, so trying to behave as if I were by adopting their affectations immediately was perceived as not being genuine; indeed, it would be mere mimicry. Those who attempted this were treated poorly. At the same time, my cultural respect cues were just plain confusing from their cultural perspective, to the point that I (seriously!) almost got beat up a few times simply for asking a polite Canadian "Pardon me?" when I didn't understand what someone else had said.

This was my first brush with respect as a foreigner in a community. My strategy became to present myself using my "natural" respect mechanisms from Canada, while making it clear that this was what I was doing. This lives on in my habit of often introducing myself as "Aaron, from Canada" when I meet people abroad. It allows me to communicate in a genuine way, while letting the others know that while it will come across as quite honest it may also seem a bit odd to them due to cultural differences. If nothing else, it saved my teenage hide more than once and has gotten me into a few fun parties while traveling abroad. ;)

In my adult years, I've had the privilege of discussing these issues with people who do this professionally, people who work as international ambassadors, cultural specialists with the U.N. Their insights are far more fascinating, profound and deep than my "down home" offering above, but resonate with me because I often hear similarities to my own experience: you have to come from a genuine place, but you also have to know it's going to get lost in translation to some extent and prepare for that.

So it is that building and effectively demonstrating respect between communities is a very different experience with a very different language and mechanism behind it than building respect between members of an existing community. Given that Free culture does not have one monolithic community, we need to acknowledge that and prepare ourselves for it. Oversimplifications will fail us and lead to disappointments that lead to fissures that are very hard to mend.

(I could also go on about our lack of skilled ambassadors and the scary job some of us do when we pretend to do that kind of work between F/OSS projects ... but I won't do so here. :)

Monoculture?

This begs the question: should we strive to become one big community, then, with one big set of cultural standards? This turns out to be a useless question to ask because it is not be possible to achieve such a monoculture.

Whether or not a single culture would be useful, it is not attainable if we are large and successful. Community evolves due to interaction over time, and that evolution causes drift in culture and values that are not "wrong" relative to each other but which are (usually) merely different ways of interacting with the same issues. We would have to all start working together on near-daily basis to counteract that, and that's simply impossible due to the basic logistics that come with the scales we deal with. Success begets scale, and scale begets cultural drift: there are too many people working on too many very different kinds of projects in too many different interest areas to build a single community. This also happens to be amplified by the decentralized mechanisms that drive Free culture at its core.

We can certainly celebrate our commonalities, but we will probably never have a single common culture or community. We can form agreements and draft papers together (which OpenRespect could be a good start to, in my humble opinion, if it is evolved further), but that doesn't engage the spirit of individuals (which is what community does). Instead, it relies on the intellect of groups. This is not to cheapen it in the least, just to put it into a realistic frame.

So what about OpenRespect?

Community agreement and coherence isn't a simple topic, and global agreement even less so. They are, however, both very important ones. I applaud Jono for tackling it so directly, and I have to give him some mad respect ;) for that. I do think that to be a useful tool, versus one that will set up false situations and lay land mines despite good intentions, it needs to be evolved considerably.

If what was there was simply refined to talk about "within a given community", it would probably work as-is, but I don't think that's what Jono is after. I get the impression that he wants to see us "all just get along" and that is something I think we could really use. To accomplish that, OpenRespect would need to take in the realities of interaction between disparate communities.

OpenRespect talks about sharing and debate, but listening with openness, without judgment and engaging in forms of communication other than debate (which is conflict centric) are at best hiding between the cracks.

There is a mention of honesty in debate, but the undermining effect of half-truths, convenient positioning and other tactics that undermine community relations outside of debate are not covered at all, despite being a key to building as well as demonstrating respect.

Today many communities, including both KDE and Ubuntu, have codes of conduct that are culturally relevant and which emphasizes mechanisms of respect as part of their core tenets. In fact, they tend to be documentary of the existing cultural norms and expectations rather than prescriptive. For OpenRespect to add to that conversation and bring real additional value, it needs to be similarly documentary rather than perscriptive and what it should describe, at least in my opinion, is what it takes to bridge between communities.

OpenRespect could even house both: a template for community codes of conduct that have a strong basis in mutual respect as well as a realistic framework for a commitment that disparate communities can buy into to good effect. Those are not the same documents, however, even if they are complimentary. They are also documents that are probably best drafted not on our own, but with the aid of people who live and breath community bridging as their profession and passion who can bring profound understandings that we can only poke at in the dark with sticks.

I'd be proud to advocate such an achievement.


With much love,
including to Jono and his effort thus far with OpenRespect,
coupled with and tempered by a deep care for this topic,
Aaron.

Read More

quick notes on using review board effectively

The Plasma team has been using review board for quite a while. We were the pioneering project within KDE for its use, in fact, which leads to an interesting observation about how such things often come up in KDE: one group tries something for a while, determines how well it works (or doesn't), other groups either start adopting it or express interest in it and eventually it is proven enough, consensus is reached and if it is a good thing it becomes a "KDE thing". It's a bit of a slow process at times, but it lets us as a community perform many experiments safely and pick out the ones that work well for people.

During our time using review board, I've noticed a few things that make it work better or worse, and I thought I'd share them here in case others were interested:

• Closing requests when they are done (committed, rejected, withdrawn, etc) is really important to keeping the queue useful. If I can't distinguish between reviews that have been languishing unattended for a month or a review that has been committed but not closed it isn't helpful.


• Screenshots for things that change the UI are hugely valuable. I've been tempted to start a "if it has a visual consequence and there is not screenshot, it won't be approved" policy to try and get more people doing this, but I also don't want to raise the bar too high to contribution. Still, screenshots make it so much faster and easier to communicate about a give patch.


• Give the patch a useful name before uploading it, otherwise I end up with a directory full of patches named "bug(N).diff" and other similarly unhelpful information. Names like "improve_foo_visual.diff" are much nicer. It makes it faster to apply them and lets me clean out my patches dir quicker if I can identify which is which.


• Start the diff at the lowest sensible directory. Diffing a change against a component 3 directories deep against the top level module isn't the most helpful: I tend to apply not at the top level but where the work is being done, e.g. at the application's or plugin's directory if in a combined module. For example, if patching the plasma-destop app, start the diff at kdebase/workspace/plasma/desktop/shell as opposed to kdebase or kdebase/workspace. This makes it easy to guess where the diff will start from and leave me at the "right" place in the tree once the diff is applied.


• Keep conversations on the review request. Usually, at least in KDE projects, all comments get CC'd to a mailing list. Replying to mailing list, however, results in the conversation being split up, partly on the review request and partly on the mailing list. Keeping it all on the review request keeps the comments together and closest to the actual data in question.

Do you have your own set of best practices for review board? Share them in the comments! I plan on adding such a list to Techbase for future reference. As review board is becoming a more and more common part of our workflow, using it efficiently is important.

Read More

+10 on Linux Journal Reader's Choice Awards

The 2010 Linux Journal Reader's Choice Awards are out and several KDE efforts have done paricularly well this year. While these kinds of awards can not be used as reliable indicators of real world usage patterns, they do give some insight into how the vocal and involved F/OSS community feels about things and they do provide some interesting hints at directions within F/OSS.

Amarok and Digikam both took top spots in their respective categories, and quite deservedly: they are awesome applications. They are also both "Extragear" applications: applications that are not bundled with the KDE software compilation that gets released twice a year along with the Development Platform and Workspaces. Like many such KDE applications, Amarok and Digikam have reasonably large and dedicated development and development support teams. It is great evidence not only that terrific apps can be made with the Qt and KDE Platform, but that the bundled apps in the software compilation are not the only path to support and success as an application.

There were also several runner up, 3rd and 4th place showings for applications such as Choqok for microblogging, Kopete for IM, Konqueror for web, KMail for email, Konversation for IRC, Krita for graphic design tool and KOffice for office document creation. VLC, an application that made the jump to Qt in the last couple of years, also showed well taking top spot for media players and making a show in the best audio tools section. It wasn't the only Qt app in their either.

MeeGo and the N900 from Nokia also took top honors in two different categories, showing the momentum Nokia and Intel have built around the MeeGo platform.

The real good news to me, though, was how "KDE", by which they mean our desktop offering, did. In the last few years we have gone through some hard, though somewhat necessary, progressions. There was the difficulty of the transition from KDE 3 to the 4.x versions of the platform, desktop and applications. We adjusted our branding message to reflect a more complex reality and experienced a number of technology speedbumps, some of which were firmly in our control and some of which were less so. In the last year, we've emerged from that period with a stronger technology foundation, better applications, clearer communication, stronger vision and a healthy community. This wasn't the only challenge we faced, however.

There was also the rise of Ubuntu in popularity amongst the F/OSS enthusiasts with a near constant spray of articles and communication labeled "Ubuntu" regardless of whether the content was Ubuntu specific or not. Ubuntu has quite firmly been a GNOME distribution, though with the move to Unity and the increased support we're seeing for Kubuntu, Qt and KDE applications from Canonical this isn't as black-and-white as it once as. Still, this "Ubuntu, ergo GNOME" connection was hugely helpful for GNOME and it sometimes came at our expense. We persevered through it, and various things in the landscape have shifted.

I think this is reflected in the "Best Desktop" and "Product of the Year" awards. KDE's desktop offering jumped 10 points in Linux Journal's poll over last year, reaching parity with GNOME's poll numbers. That is a significant jump, after a two year slump. It was also very telling that in "Product of the Year", we snagged the runner-up position behind only Android. That is a huge achievement for people to consider what we do, year in and year out, as something that contends for F/OSS' best achievement of the year across all categories.

Four years ago, we knew we had some very hard decisions to make. We knew that we could try and ride our laurels and past success and likely fade out into the sunset as we did so. We knew we could also take on the task of retooling that which needed to be, though that would bring disruption with it. Not an easy decision, and not one you get to make twice. There is yet so much more that we can explore and accomplish thanks to the decisions we did make, how we dealt with not just the positives but also the uncomfortable negatives and how the entire community of contributors around KDE picked up their boots in support of what needed to be done.

We're not done yet. Next year I hope to see even more KDE and Qt applications polling at the top spots in their category, and we'll certainly be shooting for another jump in the Desktop Environment poll based on great upcoming releases.

Cheers to everyone involved with making KDE software winners in the minds and hearts of ourselves and our users! :)

Read More

becoming a cog

I spent a couple weeks more or less out of the loop, on purpose, to take some personal time. I did make a few commits (including a large set of maintenance work on the QGraphicsProxyWidget based widgets in libplasma), met with some local KDE and Free software enthusiasts, answered emails and started a few blog entries (before stoppng myself before they consumed too much of the day I was supposed to not be doing such things in ;). In general, though, I stayed away and allowed myself to breath in the air of the city of what will be my new home.

One great thing that I enjoyed during that time had nothing to do with me: I watched the activity that kept on rolling even without my constant full time involvement with Plasma. Some 300 commits to Plasma, dozens of mails to the list, several review requests ... all concrete signs of good healthy activity. Amidst the bug fixes, new features, performance improvements was the sense that this community is alive and breathing and happily busy. This is why I became a cog in KDE in the first place, and it's stunning to see that same kind of environment thriving to this day, and not just in Plasma but all over the KDE community.

Another example of this is how the KDE Commit Digest is back again. Thank you to everyone involved, both those helping Danny crank the new issues out and Danny himself for putting together new infrastructure for it and getting a team put together.

One more example is how the Git services for the KDE community keep improving, from Git integration in KDevelop to the rapidly maturing infrastructure the sysamdin team have been tooling up for us for some time now. projects.kde.org continues to get better and better and Tom is doing an awesome job of keeping everyone informed about that process.

I had told myself this morning that I wouldn't blog today, but I couldn't help it. I caught up on news and a bunch of email communication and after all I read and saw, I just had to race over to share the great feeling I was left with.

Read More

plasma in 18-24 months?

In my last blog entry, I mentioned QtComponents, QML and the new Qt scene graph and then vaguely alluded to profound implications for Plasma. I will not tease you, dear reader, for longer than necessary: this blog entry contains my current preliminary thinking on the what this could all mean for Plasma going forward.

First, I'd like to note that none of this would be possible without the fantastic work going on at Nokia's Qt development offices. They are tackling hard and interesting problems with gusto and producing some very nice results in the process. QtComponents is being developed very much in the open right from the start: an open mailing list for all dev discussion, a public git repo that even contains experiments and early code sketches, a set of use cases and open tasks in Jira. Outreach to community members such as myself, which allowed me to join their design sessions last week, is just one more piece of this. This open from end-to-end, right from the beginning development model is part of the "new Qt" ecosystem that is the culmination of years of consistent effort on the part of many individuals involved with Qt. It's paying off now, and I hope that all new Qt components undertake a similar, or even the exact same, type of approach.

Enough about that, however... what does all this new stuff mean for Plasma?

There are two things that I'm really not very happy with when it comes to Plasma right now:

• libplasma provides some very elementary UI components that really belong in Qt, but because they aren't in Qt have ended up in libplasma out of necessity where they are more of a distraction (in terms of code clarity and design) than anything else


• QGraphicsView, particularly QGraphicsProxyWidget, is not nearly as performant as it could be. It's gotten pretty good in terms of being quite usable even on modest hardware with Qt 4.7 and KDE Platform 4.5, but it could be so much better.

The new scene graph would allow every paint operation in Plasma to be hardware accelerated on the GPU using OpenGL. Not only would effects like blur become cheap (the expense is why we don't use blur on the canvas itself, but only on top level window backgrounds where we can use KWin's OpenGL driven compositing effects to achieve blurring) but things like nice halos around text should be able to be rendered at high quality and low cost. Pixmap usage should drop, framerates skyrocket and client-side image manipulations all but disappear.

This implies moving away from QPainter, which only gets in the way of proper acceleration since the painter can do "anything" in "any" order. Which means moving all of our user interface to the declarative model, specifically QML. In turn that means needing proper declarative style widgets, specifically QtComponents. Finally, it means leaving QGraphicsView behind and moving to a scene graph only system.

This is not a small amount of work: every Plasmoid, Containment, popup and window dressing (e.g. the add widgets interface, the panel controller, the activity manager ..) that does direct painting needs to be moved over to QML. Thankfully we can do these one at a time with the results working very nicely with the current QGraphicsView based libplasma. This means we don't need to do a "massive porting effort with a huge pause between releases"; each release can contain more and more QML driven elements and fewer and fewer uses of QPainter. The result for the user while this happens is likely to be nicer looking interfaces, as QML usually makes this easier to achieve.

Marco has been working extremely hard on the first thing we need to make this process possible: Plasma <-> QML integration. This work is being merged into trunk right now and will debut in KDE Platform 4.6. This means we can start the process of QML-ification of Plasma now. Plasmoids written in C++ can create Plasma::DeclarativeWidgets, Javascript Plasmoids can load QML files from their package and Plasmoids can be written entirely in QML (using the Plasma Javascript API from within the QML).

We will also need to replace our current QGraphicsProxyWidget based pushbuttons, sliders, etc. with QtComponent based ones. This is mostly an issue for Plasmoids written in C++; Plasmoids written using Javascript should shielded from this set of changes. Other scripting languages such as Ruby and Python expose more of the implementation details and so those Plasmoids may require some adjustments. However, moving to QtComponents means waiting for QtComponents to be "ready" and dealing with the baggage of our existing C++ QGraphicsProxyWidget subclasses in libplasma.

Of course, we're not simply waiting for QtComponents to magically mature on their own. Several of us (Artur, Marco, myself) are engaged with the QtComponents project and its team already. Marco has also already provided the first QtComponent push button whose text is set using a source from a Plasma::DataEngine, all done in QML. So we know the basic ideas work in a very practical manner.

Here's the big bomb-shell, however: to fully complete the migration process, we'll need to create a "libplasma2" which is binary and source incompatible to the current libplasma. Corona will cease to be a QGraphicsScene subclass and instead become a scene graph manager; Containment and Applet will become some kind of QML item; the QGraphicsProxyWidget subclasses will be dropped.

The good news is that this is an almost completely internal set of changes. The design of Plasma lends itself very nicely to this set of changes, and the C++ classes in libplasma are nicely aligned as well. For instance, Corona right now is the QGraphicsScene and manages Containments and provides "global" management of things like configuration data, screen geometry hooks, etc. None of that would change, except it being a QGraphicsScene. DataEngines, Plasma::Services, Plasma::Svg, etc. would not change in the least, either. So the external impact looks like it will be surprisingly small for anything written in Javascript or which uses QML for its user interface. Note that Plasma Mobile is already 100% QML, modulo the components it inherited from other Plasma workspaces, consisting mostly of individual Plasmoids.

All of this means that it isn't going to happen in the next release, or even in the release after that. It will be a measured set of changes over the course of many releases to reach the final goal of "going scene graph". User disturbance will therefore be kept to a minimum and we'll be able to continue to make regular releases with noticeable improvements while we do this.

The end result of full hardware acceleration, a fully QML driven user experience and a much improved resource footprint are, in my estimations, worth all of this effort.

There are some potentially very exciting things this could mean beyond simply improving what we already do, though. One of the main ones involves threading. The scene graph is capable of rendering the scene in multiple threads. QML needs some adjustments to take advantage of this, but if/when that work gets done it would allow Plasma to run each Plasmoid in its own thread. (Note: this is different from multi-process.) That would mean that any pausing in a given Plasmoid or other user interface components would cause no annoyances in the rendering or interaction with any other part of the user interface. It would also enable fairly trivial resource management: we could then track per-Plasmoid memory and CPU consumption, for instance. Achieving such a multi-threaded Plasma will require some additional work on top of everything already discussed above, including things such as DataEngine access (which is not currently designed for multi-threaded access) and sharing of Svg renderers between Plasma::Svg objects (something that lets us gain significant performance benefits right now). My initial scan over things says that it isn't insurmountable: we can make rules about things like Plasma::Svg (can only be used in the same thread as the Plasmoid; so no sharing Plasma::Svg's between different instances of Plasmoids) and probably adjust things like DataEngine successfully (the idea of putting the DataEngines out of process, something I've toyed with conceptually since the 4.0 release, becomes even more attractive under this scheme).

It's an exciting set of possibilities, though none of this is certain yet. It's all still "work in process" research and none of the above may happen. I'm hoping it will, however, and the pieces are actually falling into place. Huzzah.

Read More

oslo was, zurich is

I was in Oslo for a few days last week to meet with various people in the Qt offices there. The main purpose was to collaborate a bit on the design of QtComponents, which is a framework that provides a modern widget abstraction for users of QML. The problem to solve is simple to state: create a way to have "MeeGo widgets", "Symbian widgets", "Plasma Desktp widgets", etc. that developers using QML can easily hook into and use so they are both native looking as well as don't have to re-implement buttons and other basics themselves over and over. It's not a very easy problem to solve given the various constraints we face. I'm increasingly happy with the direction QtComponents is going, however, and think the combination of "a reusable core" with "enabling easily rewritable components for a given platform", while perhaps non-conventional, is very compelling.

I also met with Gunnar to talk about the new scene graph he's working on, as well as with Thiago to discuss MeeGo / KDE strategy and Aron Kozak to discuss community integration and how to ramp up KDE and mobile success. Not bad for 2.5 days, even if it left me a little tired at the end of it all.

The scene graph thing is particularly interesting, though, as it allows full and proper hardware acceleration for Qt interfaces. Think "gaming style performance and graphics capabilities" for Qt applications. To really take full advantage of this, the UI will need to either use the scene graph directly (unlikely and undesirable) or else be written with QML which will use the scene graph internally.

Combine this with QtComponents and the ramifications for Plasma workspaces (or any other application that decides to go this route) is absolutely profound. But that's something for my next blog entry. This one is about my traipsing about the European sphere this month. ;)

Which brings me to Zurich, my future home. I received my first piece of mail addressed to Herr Aaron Seigo, which was rather exciting and a little surreal all at once. We went to see the new apartment, which is well on its way to being finished. Between all the "yes, this is really happening" reinforcement, we also took time out to wander about Zurich a bit, stopping in at a book store (where I picked up a cool book for P. about Zurich for young people), cafes and generally enjoying the city. This includes biking about everywhere (Zurich is, despite protestations otherwise by some of its locals, very biking friendly) and wandering the streets with bags of heisse maroni (hot, fresh roasted chestnuts) in hand, which is such a lovely pre-winter time thing to do.

Today I am hanging out at ETH (where S. works), the same university that Albert Einstein (one of my personal heroes) attended, catching up on communication and getting down to some work for the week. I'll probably do similarly tomorrow.

It's feeling more and more natural, home-ish, to be here. :)

Read More

activities as homonyms

I've been reading around the blogosphere about activities in both KDE Plasma and the upcoming GNOME Shell. There's an unfortunate thing at play here: Plasma and GNOME Shell use the word differently. Yes, it's the same spelling and pronunciation and, worst of all, they are used to describe something in the same area of the interface (the desktop shell), but they aren't used to describe the same thing.

In GNOME Shell an "activity" is a virtual desktop, the same thing we've all come to know and love since X got support for them in 1989 based on work done earlier at Xerox PARC. Virtual desktops rock, and GNOME Shell has added an enforced overview (with +/- buttons to easily add and remove virtual desktops, something also in KWin these days) along with an integrated application and document launcher sidebar to the idea. They call this "activities" in an attempt to make the abstract and geekish "virtual desktops" more approachable to people. It is not, however, what most humans would call an activity in every day conversation. It's just a more recognizable name for an old concept that they gave some polish.

In KDE software, an "activity" is actually much closer to what we'd call an activity in the real world: it's a collection of tools with a task based theme. What the theme is remains up to the person using the computer; Plasma just provides an interface with which to create an activity and start defining what belongs to it.

The concept of activities in KDE software is not limited to Plasma, however, as activities are in GNOME Shell. KDE's activities are orchestrated behind the scenes, transparently to the user, by Nepomuk. Other applications can hook into this information and adjust their presentation accordingly. For instance, KWin recently gained support to not only hide and show windows associated with a given activity, but also to stop and start applications using session management. This means that when I switch to my "personal coding project" activity, I get a Kate window with the files loaded in it that I was last editing related to that activity.

Any application can talk to Nepomuk and get notified of activity changes or even create new activities. The idea is to create a task centric workflow allowing one person to use the same laptop or desktop system for multiple (potentially very different) tasks, keeping each one out of the way of the other.

Virtual desktops are really not particularly related to this concept at all, as should be fairly obvious. It's unfortunate that GNOME Shell developers decided to use the same word we are using for something so very different. Ah, well.

In Plasma Mobile and Netbook, we also have activities though they are slightly different beasts. Here they are sets of mini-tools and related applications. So using Plasma Mobile, there are different activities for different common tasks on such a device, such as communication (e.g. "making a phone call") and playing games. When switching between these activities, different sets of home screen applications and tools are presented and run (user customizable, of course).

Again, no relationship between virtual desktops and activities there, where activities map directly to "what I am doing with this device".

It is completely possible to use virtual desktops as a way to separate tasks into similar activity sets. However, it doesn't map very nicely to common use cases such as "I always have my email client (perhaps also always on desktop 4) regardless of what I'm working on". In such (rather common) cases, it becomes clear that virtual desktops and activities (as used in KDE software) are orthogonal, though they can be used as complimentary tools.

Using virtual desktops also doesn't give the applications any useful information as to what to do about the information inside of them. Being on virtual desktop 4 doesn't give KMail, for instance, any information as to what email accounts to start checking automatically. Knowing that the current activity is "Office" does, though.

One of the downsides of taking the approach we are in Plasma is that it is a new set of ideas. There is nothing pre-existing for infrastructure (e.g. we had to create all of the Nepomuk management and application notification from scratch) and we don't have the luxury of looking at other mature systems from which to copy when it comes to things like "what is the best way to switch between system-wide activities?" This means it is more work and a slower path to final results. We feel, however, that it is a slightly more interesting result, in terms of providing a new set of tools that address hard real world challenges in modern computer usage, than creating a full screen virtual desktop pager with integrated app launcher.

As activities take more and more defined shape and become more solid in KDE's Plasma workspaces, it will probably be wise for us to communicate clearly and simply what they really are and how to use them.

Otherwise people will confuse "activities" for "activities" and perhaps even miss out on this next generation of tools without ever understanding what they are missing.

Read More

on the impending future of ui greatnesses

What a title for a blog entry, huh? Well, it's rather tongue in cheek on the one hand, and almost serious on the other.

Lions, Tigers and Cloud HTML5 .. oh my!

I've written about this from various points of view before, and I just love Larry Ellison's response to a question about "the cloud", but it bears repeating and looking at the core issues from different angles because people continue to find themselves confused on the matter. This time we'll look at it from the perspective of "form factors are not programming languages".

Reality is that well over 300 million new desktops and laptops are sold every year. That number is even growing, albeit slowly as one would expect from a mature market segment that is also seeing displacement pressure from new (or revived) form factors. So the "large screen, got a keyboard and a pointing device" form factor is really not going anywhere. It's a good form factor that works for a lot of real world use cases and it will be with us for a while.

HTML5 and the "cloud" do not change that one bit. That's because those technologies are not drivers of physical form factor. I could use those technologies equally well on a phone or a laptop or a T.V. or a fancy billboard at a sports stadium. That is why coming to the conclusion that "Our idea of the desktop is gone." is so wrongheaded.

Now, our way of writing applications for "the desktop" may change over the next decade, but the desktop will still be with us. People will still want a way to launch their apps, manage the shapes they appear in on the screen (aka "windows", since I assume that HTML5CloudAwesomeness doesn't mean "everything is fullscreen with one app at a time" for most people), will want to place these HTML5CloudAwesomenesses around their screen (aka "desktop widgets"), etc. That could, indeed, be written in HTML and Javsacript, but it will still exist.

So what appears inside of our windows may change in the form of where some or all of the data being manipulated is stored and/or what language is used to write them .. but it will still be a lot like a laptop computer.

Just like a tablet doesn't become a desktop just because you run a desktop application on it. If you don't get that one, try running one of the games that are available for the N900 that are just re-compiles of games made for a desktop. It's pretty evident that the language used doesn't magically change the form factor or render it useless.

Network centric computing is awesome and is changing the landscape. How it will change the landscape in the future is not how it is changing it now in terms of creating all these walled gardens that require you to pay with your attention (ads) or with your wallet (rental sites), and I think it is imperative that Free software does provide network storage solutions that work well in this new reality to prevent all the technology from aggregating behind those walled gardens, such as Google.

We will change how we write apps

On that note, I am fairly confident that we will radically change how we write applications with a graphical interface over the next few years. This will not just be on the desktop, but across all kinds of devices. The most exciting thing won't actually be the language used (e.g. HTML vs C++ vs $WHATEVER), but in the level of modularity and subsequent re-use that happens as a result.

Ryan Rix published a screen cast about the Plasma Dashboard KPart that he worked on, particular with regards its use in Kontact. The first comment on his blog asked why use Plasma there at all. The answer is wrapped up in a new way of thinking about application development. This is something I've also blogged about in the past, but that we're starting to actually see happen now.

Instead of writing applications as monolithic things, or at best as collections of components that work with each other only, we're starting to see the emergence of applications that are written as collections of self-contained components that are then collected together into a single interface.

In the specific case of Kontact and it's summary view, it needed to be rewritten for Akonadi anyways. So it was decided to do it in a way that (a) improved what is already there and (b) made new things possible at the same time.

The version shown in Ryan's screencast isn't finished, and the layout and graphic design still has tweaking left to do so it looks a bit nicer in certain places, but even in its current state it gives Kontact's summary dashboard some nice improvements.

I'm not sure how many people new that you could actually move items around in the summary. This is both more obvious now (which is mostly a factor of the graphic design), but also has the ability to provide multiple columns in addition to rows. Horizontal scrolling is there when needed, another improvement.

To extend the summary page requires a plugin system of some sort that everyone can use. Plasma provides just such a component model that fits that perfectly. So an existing widget that is related to email, contacts, events, etc. can now be used in Kontact without any additional work being required by the Kontact team. The email summary widget seen in Ryan's screencast, with all of its great features, is Lion Mail. This was developed for Plasma Desktop in mind originally by sebas, but can now be used in Kontact, saving the Kontact team a ton of work.

What about a weather widget? It was going to have to be re-written, too, to use the new weather data fetching in KDE Platform 4 (which happens to be driven by a Plasma DataEngine now). Well, with the dashboard it doesn't need to be re-written at all: the existing weather widgets can be used there.

Conversely, components written for the Kontact dashboard can also be used in Plasma Desktop, Netbook, other apps using Plasma Dashboard, etc. So the nifty "upcoming events" Plasmoid, written for Kontact is now also available wherever you want.

This is a remarkable, if seemingly subtle, change in how we are writing applications. It's a floating mix of components that we can re-arrange, mash-up and re-use .. at runtime.

We see this not only in Plasma derived work, but also in Akonadi itself as well as KDE Telepathy which renders the functions of Kopete into a similar raft of run-time components.

Not only does this save all of us developers time, it increases consistency between applications, raises the number of features that are easily available to integrate seamlessly into your application (or mash-up) and reduces the runtime overhead of doing so.

Componentizing the Chrome

Another sort of components (don't you love it when we use the same words for different things?) is the user interface chrome itself: the buttons, the knobs, the dials, the menus, the sliders, the web canvas, the print dialog ..

The status quo has been that everyone writes a set of such components for each project type: one for this phone, one for that phone, one for desktop apps, one for PIM apps, one for T.V.s, etc. These components have traditionally been a horrible mix of logic ("when the user presses on this area and then releases on that area, then ...") and display ("paint this gradient here when it is in a pressed state ...").

The display of these elements has been further compounded by the need and desire to make things look and work differently in different contexts. So we have the Oxygen style along with dozens of other Qt styles, each of which is a behemoth of complex C++ that can style all kinds of things in all kinds of situations. There are very real limits to this approach, mostly due to the complexity it introduces and the limitations one runs into quickly due to this.

We also have a different presentation style on a small screen than we do a large screen. Dialogs may look completely different, for instance.

What would be great, however, is if we could get the C++ guy out of the room as much as possible, break up the logic and the display into different pieces so that changing one doesn't impact the other (and removes so much need for subclassing!), make it easy to define new components that overlay just those components from the defaults (so I don't have to write a whole new style just to get a different kind of toggle button semantics, e.g. checkboxes in a mouse driven UI and a slider toggle on a finger driven UI).

If that was possible, app developers could write their UI quicker and easier than they do now (thanks to logic/display separation) and platform developers could mold those application UIs much more cleanly when run on their platform.

Now imagine if this was all done using a proper scene graph allowing for proper hardware acceleration (the sort you usually only get with games these days), built upon a declarative model for user interface (lowering costs and shortening devel times), allowed designers to directly create the elements which developers could then directly use (and vice versa) and easily allowed one to step away from compiled code where desired and use things like QML and JavaScript .. though not be forced to do so, either.

This is the future that QtComponents is attempting to bring us. There is a development hot-house happening next week in Oslo (that I hope to attend for a couple of days as I just happen to be nearby that week, as it turns out) that will be critical to the future shaping of this potentially ground breaking approach.

It should, done right, result in it being possible to write UIs which are as or more powerful than the desktop interfaces we have now that look better, work faster, cost less to make and without being bound to a web browser or the technologies they provide (or don't, as the case may be). All with write-once-run-anywhere-there-is-Qt, even without a native compile if done right.

The Device Spectrum

Something that has struck me about what the Linux kernel did that was groundbreaking for the time was to view all computing devices as a spectrum upon which the kernel, albeit in different configurations, should run well on. A wrist watch, a smartphone, a desktop, a super computer .. they are all just collections of CPUs and storage (volatile and non-volatile) coupled with form factor specific stuff, like graphical displays and networking, with processes running on them, right? Hey, it's all the same! Sort of. So why not one (sort of) kernel that runs on all of them? So came the Linux kernel which now is both running rampant in mobile and owns the super computing world, two opposite sides of the spectrum.

Why not our graphical applications?

With decomposable applications and componentized interface elements we begin to approach the age of the device spectrum with our graphical applications. Right now Marco and I are helping a company in Asia working on a tablet device running MeeGo with Plasma providing the UI. They are able to simply re-use work done for the desktop and the tablet we've already done, re-arrange it, put it on MeeGo and profit. (Well, ok, that last point is yet to be proven: the product is still in R&D. :)

We can now take pieces of Kontact, be it at the level of Akonadi data delivery or in Kontact widgets written with Plasma, and use them on a phone, in a Plasma Desktop panel or in Kontact where we'd traditionally expect them to be stuck. Today, we can even pull that widget live from Kontact's dashboard and show it on my smartphone with Plasma. Tomorrow, with QtComponents, we'll go even further with what we can do with the presentation on these devices.

In Summary: It's Doing Less For More Reward, Not Just Doing It Different

I really don't care if someone writes their app using HTML5 or Javascript or C++ or Brainfuck. That's highly uninteresting to me. What's interesting is this:

• In how many environments and form factors can I run it?


• Does it look good and work well wherever I run it?


• How much does it cost to write it?


• Does it provide me with all the facilities I want during usage?

(Before you lob security and privacy as additions to the above, realize that those are actually facets of the fourth point.)

It becomes apparent that HTML5 (to continue to pick on it :) is one attempt to fill the above four points with varying degrees of success. HTML5 itself isn't very interesting at all, viewed that way. It is of high interest to groups like Google who have run themselves down the narrow alley of "web browser", but not because HTML5 is, per se, that great but because it addresses more of the above in their delivery channel (a web browser) than HTML4 does. While it certainly doesn't hit 100% on all the above points, it moves the metrics closer in that direction.

Still, HTML5 doesn't do a whole hell of a lot for my delivery channels, and it won't for many others as well. QtComponents, QML, Plasma ... these things do a lot for my delivery channels and does so remarkably better than HTML5 on every metric save one: ease of deployment. This is solely because the web browser is ubiquitous these days, even if HTML5 isn't just yet. When "Qt Everywhere" is achieved (or close enough to it, and terrific progress is being made on that goal), even this will no longer be the case. On all the other metrics, we're already at or headed shortly to a much better solution that is more than just "hey, what language can we write applications in for easier deployment?" Of course, that better solution also works seamlessly with HTML5 content thanks to QtWebKit.

This set of technologies will provide (some pieces aren't done yet, e.g. QtComponents) convincing answers to the device spectrum challenges, the component re-use issues and cost factors while opening doors to deployment. Best of all: without sacrificing existing or impending capability. (Aka "we already have OpenGL, what's so exciting about that?")

This is a set of changes that is being seen reverberating across our UI stack even now. Plasma is built around these ideas today, and whether it's a tablet or a smartphone shell or Kontact, KDevelop and Skrooge using it for a summary dashboard or the good ol' laptop with Plasma Desktop on it, we're getting to see the early days of this shift in how applications are being made and delivered right here in KDE.

Read More

be vewwwwy quiet .. i'm hunting pixmaps.

There's a great tool in KDE's svn called kdumppixmap. Once built, you run an app with `ktracepixmap ` and it says something like "Starting with pixmap tracing. Use kdumppixmap to save currently allocated pixmaps to disk". You wait until the application is in the state you want it to be in and then you run the kdumppixmap command it gave you. This creates a directory full of image files, one for each pixmap sitting on the X server. It was written by Maksim Orlovich, who borrowed some code from Geert Jansen's kstartperf and from kBacktrace.

I've spent time yesterday and today with plasmoidviewer and a tortuous little plasmoid I wrote in Javascript that has 150 buttons, 150 line edits and some other assorted jumble in a grid layout. The goal was to eliminate as many pixmaps as possible, and at 18:00 on day two, I'm quite nearly there. Here are the areas I traveled in my pixmap hunt and what I found while doing so; hopefully others will find it useful as well. :)

The FocusIndicator

The first stop was the FocusIndicator class which draws those pretty little halos around buttons and other things when you mouse over or give them keyboard focus. It had its own copy of the FrameSvg that creates those images from a raw SVG file, and it did a few unnecessary things at start up. After fixing that, there wasn't any reduction in pixmaps (sadly), but creating a button, line edit, combobox or slider got twice as fast. The remaining overhead is now in QGraphicsProxyWidget, of which there is probably desperately little we can do right now. (QtComponents is our likely savior in the mid-term; no short-term relief, however).

The PixmapTransition Animation

We do a lot of nice little animations in Plasma. You may not have noticed, but when you mouse over, press on, give focus to, etc. nearly any widget the visual states smoothly transition from one to the other visually. This is usually done using an animation called PixmapTransition, which does exactly what the name suggests.

One of the caveats of such a thing is that it needs to align the pixmaps first. No problem, just calculate some offsets, right? Well, it turns out it was doing that, but then creating new pixmaps with the original images repainted at those offsets in them. Which meant that every time it was used, there were usually two extra pixmaps kicking around needlessly. Now it just calculates the offsets and uses those in painting.

With those two gone, there was one left: the result. The way the animation works is that the animation timer ticks along from 0 to 100 over a given period of time (and a given curve). On each animation tick it would generate a new result pixmap and tell whatever it was animating (e.g. a push button) that it needed to repaint itself.

Thing is, most of the elements in Plasma are already buffered quite nicely and don't need this extra pixmap sitting around. So I made the caching optional and off by default. I also moved the creation of the pixmap into the method that the item being animated uses to get to it. This moves the creation of the pixmap out of the animation frame tick and places it at the moment the pixmap is actually used. This means that it now only creates frames in the animation that will actually get painted. Previously, if the animation loop is ticking along faster than the widget can repaint, then a bunch of painting operations that the user would never see on their screen would be generated. No more.

FrameSvg

So now we were down to just 1/3rd the number of the pixmaps being held on to, and a lot more efficient generation of the pixmaps we did use. But as kdumppixmap was showing me quite plainly, we still had one pixmap of the background for each button (or whatever) even if all the buttons were the same size and disposition. In other words, we had N pixel-identical pixmaps, where N is the number of identical items on screen. This just wouldn't do, and so I took a dive into the primary culprit here: FrameSvg.

This class creates nice four-sided frames to put around buttons, Plasmoids, tooltips and what not. It's used quite heavily in Plasma and to keep things speedy it has its own local cache on top of the on-disk cache in Plasma::Theme. This cache was per-FrameSvg object, however, and the source of all those pixel-identical pixmaps that were jeering at me from Gwenview. Damn you, pixmaps!

So I implemented a small reference counted caching system whereby identical frames are shared between FrameSvg objects. Finally, I had one pixmap for the buttons (well, four, due to different states of the buttons as I went around clicking on them) and a similar number for the lineedits. Instead of hundreds and hundreds of pixmaps, I now had a couple dozen for the entire plasmoidviewer session. The savings were well over 2 MB of pixmap data in the X server.

The Impact on Plasma Desktop

A Plasmoid with 200+ individual components in it which are all the same size in a nice little grid doesn't sound particularly "real world" does it? I also tested with a default plasma-desktop session and it turns out that, indeed, the savings are not quite as dramatic .. but they are significant.

On starting up a default plasma-desktop layout, there's ~1/3rd fewer pixmaps due to the FrameSvg caching, and several dozen fewer on top of that due the rest of the work on things like PixmapTransition. Each pixmap avoided is less X traffic, less video memory and a generally smoother experience.

During usage, a lot of transient pixmap creation is avoided as well. For instance, the tasks widget uses Plasma::PaintUtils::transition to fade the tasks buttons in pretty much the same way the PixmapTransition animation does (in fact, it seems the only reason it isn't using PixmapTransition is that the tasks widget predates PixmapTransition). As such, it gains the same benefits that PixmapTransition has, namely two fewer pixmaps per animation step.

The more Plasmoids you use, the more you gain, of course. Things like the panel controller and other such window dressings also benefit.

The Impact on Plasma Mobile

The impact on Plasma mobile should be even larger, as "bunches of things of the same size" is a very common occurrence (e.g.a phone dialer, a grid of app icons, ..) and graphics performance is a rare commodity. Keeping the animations tamed through fewer generated pixmaps, only generating pixmaps actually pushed to screen, etc. helps out as well. I don't yet have numbers of the impact on the N900, but it can only be good news there if it's noticeable on a desktop system.

So, a reasonably good investment of effort. All of this should end up in the 4.6 release coming in January. If you'd like to enjoy the benefits of these improvements now, we'd enjoy you helping us test things prior to the release. :) I know Suse provides some great packaging options for up-to-the-day builds and there's always the "build it from sources" option (kdesrc-build really helps making that easy to achieve).

Read More

a pursuit of joy

I have a knack for tending towards seriousness. This is sometimes balanced out by my penchant for the absurd and light hearted. Sometimes. Too often, however, I drown myself in thought and effort and veer towards over-focusing on certain things while paying too little attention to others. Eventually my motivation suffers because the joy in doing things starts to leave me. Finding the joy in things is more than just a nice idea, it's a survival skill.

The last couple of years have been necessarily serious in nature for me, both in personal and professional matters. There are many reasons for this, and I won't bore you all to tears with them. I am happy with many of the results of those efforts, though less than happy with others. Hopefully I've learned a thing or two from the latter. In any case, things have been arcing in a wide sweeping movement towards subtly new directions for me this year.

It has become time to re-find my joy in the various things that I cherish, but in which I have perhaps allowed too much seriousness to creep into, even if required by time and circumstance. It has been a prickly feeling under my skin for the last couple of months, a cocoon I find myself slowly emerging from with new skin to live in.

(Which is odd: we are beginning the march towards Winter, and I am experiencing Spring. I am usually more in step with the seasons than this.)

This has come in the form of simple things: I have finally searched out and found my favorite shampoo again, which happens to be a tea-tree infused magical concoction without any dies or colors or environmental nasties that opens my eyes jubilantly wide with each shower.

It has also come in the form of far less trivial things: I am moving, for the second time in two years, no less. I hate moving as a general rule, but this one has a great motivation: to share life with a special someone for hopefully a long, long time to come. So it is that I will be leaving North America altogether at the end of this Winter to makie a new home in Switzerland.

In between the trivial and the profound, another place I'm aiming to find joy again is here in my blog. It's been somewhat stunted, minus a few bright moments here and there, of late. It got more serious and less personal and more .. well .. less joyful. :) I'd like to shift that, to indulge in my joy in writing here again.

To kick this all off, I thought I'd share a little story from my childhood that came back to me in the shower this morning as the shampoo was doing its magic on my mind. It's the first clear memory I have of experiencing that "a-ha!" moment, something that I have since pursued through attempts to identify, analyze, solve and create. It involved airplanes and playing outdoors and wooden sticks and numbers. So many of the good things of childhood, really. ;)

I was 8 or 9 years old at the time and was playing alone outside on a beautiful sunny day. I saw one of the float planes that take off and land in the waters around the town of Sechelt several times a day pass overhead. As it made it's noisy way above me, I began to wonder just how high up it was. I became entirely lost in the thought of figuring out the answer. Figuring that I couldn't actually get the answer in practice, I set about thinking how I could in theory.

So I imagined myself in a simpler, more perfect scenario to bring the problem within my grasp. In this imaginary place I was standing in a flat, wide grassy field with the airplane in the sky high above and at some distance away. The sun was directly above the airplane, and as such it was casting a shadow that landed directly below the airplane. I figured that I should be able to see this shadow, and if I could somehow measure the distance from me to the shadow on the ground, then measure the angle with which my head was tilted to look at the airplane ... perhaps I'd have enough information to figure out how high the airplane actually was. I ran back to my bedroom and got out some straight wooden sticks from one of my toys and started playing with them on my bed: indeed, if I knew where the shadow was and the angle of my head and that the airplane was directly above the shadow (giving a perfect right angle), there could only be one solution for how high up the airplane could be! What a wonderful idea! I lit up inside with the fireworks of discovery. Just imagine, I thought, at all the things one could accomplish with this idea of solving triangles.

I ran to share my "discovery" with my mother, who calmly informed me that it was called trigonometry and had been discovered ages ago. She was doing the dishes at the time, and from what I recall continued to do so without stopping during our exchange. It was a little disheartening, to be honest, that she didn't share my enthusiasm and that my little idea had already been found and was common knowledge. Rather humbling, in fact. I never did forget the rush of discovery, though. Or the realization of how hard it was to think of something someone else hadn't already thought of.

I've been in pursuit of that feeling ever since, with occasional success, returning to that wonderful warm surge again. Sometimes it's a trivial thing, like writing a poem that manages to strike just the right nerve in me. Sometimes it's witnessing the creation of something new and unexpected and better unfold before me. (Which is why I far prefer live music to studio recorded music, and one reason I find such joy in writing software.) Sometimes it comes from managing to find a new way to perceive the world around me in a way that sheds a different light on what I had once thought mundane or intractable. This is, at its most basic level, a pursuit of joy.

I have not done quite enough of that recently for my own liking, though, and this is a personal reminder to myself to fix that. Perhaps I'm now one blog entry closer. :)

Read More