on a slightly more positive note

On a slightly more positive note, I've been very nearly overwhelmed by the response from people at the Summit on Sustainability here as well as from the 4.2 release event. I have met a large number of very interesting people and am now suffering from a somewhat monumental backlog of email from them. It's going to take me a while to get through it all, but having so many new quality contacts to catch up with can only good problem to have.

I'd also like to thank the FSFE team here in Zurich (Shane, Georg and Graeme) for their time the other day. What an intense and useful set of conversations! I can't wait to start working on the issues raised; while very big topics things such as raising awareness of issues around data integrity and identity in online services are important to add to the F/OSS "agenda". Extra thanks to Georg for coming out to present at the 4.2 release event.

The local team here, particularly Luca and Pascal, have been wonderful and I have managed to not get lost even once thus far in Zurich. An amazing achievement for me. ;)

Anyways ... back to the email salt mines. ;)

Read More

i will remain in spite of you

Right now I'm sitting in Zurich far from my home at a decidedly non-IT conference whose topic is sustainability attended by a number of rather wonderful people from around the world. I have been serving as an envoy of Free software and bringing awareness of the connection between social issues and our technology choices with me. I have also been busy outside of the conference: I spent my day yesterday speaking with the FSFE about three very large issues that are facing Free software right now, I spoke at the 4.2 reease event in Zurich and spent quite a bit of time talking with people who came out (probably well over a hundred people). I go home tomorrow across the Atlantic only to turn around in four days to head back to Europe to work some more on this stuff. I keep joking that I'm just going home to do my laundry.

It's been a long week, but a good one in terms of effort and result. I should be happy as I sit writing this in a naturally lit room with windows looking overlooking a wonderful Swiss lake, but I'm not.

Instead, I'm wrapped in an ongoing saga and yesterday LWN carried an original story on the whole Linus-switches-Aaron-replies thing.

To be blunt, I really dislike writing about topics such as that. They just aren't fun: the forensic analysis of January 2008 is extremely non-trivial in terms of cause/effect/solution dynamics and I know that it will always result in a certain amount of reaction from certain individuals that can only be described as non-useful. So while necessary to engage in, there is no short term win to be had; only hard work. If we don't talk about these things, though, we end up risking not learning how to improve process. If we do talk about them .. well .. I get to deal with days full of shit. (Sorry for strong word, there just is no other set of letters that quite captures it.)

As a result of this story breaking last week and continuing to be dragged this way and that I've had other things to do than celebrate 4.2. For instance, I spent time the other day discussing the issues with a Fedora KDE team that had to first be led away from blame-gaming to solution-gathering. That kind of stuff is neither easy nor enjoyable. In fact, I found it extremely tiring and stressful. Keeping patience and building consensus are not easy tasks. Realize: I don't even use Fedora, I just care about what happens to Free software.

So this morning I found time to read Jake Edge's article on LWN and came away disappointed and discouraged because there is nothing new at all in it. Why bother to editorialize if you all you do is repeat what has already been written? I keep hoping for some bone fide critical thought, consideration and the generation of improvement.

What I find most amazingly depressing about this situation is that it is happening precisely as we are releasing 4.2: a really good release that shows quite plainly what we are aiming for today and beyond and which is in no small way a result of the hard decisions around 4.0. I can't really feel any of the "win" around this moment however.

When I read this in the LWN article:

"KDE 4.2 has just been released, and early reports would indicate that it is very functional. With the problems from the KDE 4.0 release—now a year old—fading in the memory of many, a rekindling of those flames is probably less than completely welcomed by the project."

All I could think was, "Well, no kidding. How about letting me enjoy the release for a couple days?"

There is no particularly useful reason for writing this blog entry (and I'm sure several people who contribute little beyond entropy to existence will step up to remind me of that) other than to just "get it off my chest". On a week I was hoping to enjoy, to breath a deep breath and say "good work, everyone!" for the 4.2 release, I have found myself surrounded in the past.

It's not like we couldn't have had this conversation a week or two from now, right? The past isn't going anywhere, but the present is fleeting.

*sigh*

Read More

feedback

Waking up this morning at ~06:45 I took some time to think about the questions raised in the Q&A that followed my presentation two days ago. The questions people ask tell me three things:

• What I missed completely, didn't explain well enough or with enough impact to be memorable


• What they audience is particularly interested in (sometimes they hear the explanation in the presentation, but are so interested in it that they will ask about it anyways to hear about it again)


• What the audience disagrees with (expressing disagreement by posing tough questions is commonplace)

What was very interesting is that my audience was not technologists, aside from a couple of people who came to hear my presentation because they use KDE or Linux. Most, however, were students working in the social and political spaces. Many of the ideas I presented were completely new to them because software isn't something many of them have reason or opportunity to ponder very often. I don't blame them, as it probably doesn't seem like a very tasty topic to most people. "Computers, how boring!"

So what did these smart, driven people ask about?

• How do I switch? The fellow asking worked with a person who used Linux and had been interested in switching, but hadn't quite figured out how or if they should do to readiness of our products. They use a Mac, live in the first world, they are their own tech support and use their computer as an office tool. They represent what is probably one of our hardest demographics for switching: high expectation, computer literate, self-supporting home user. (Sign of interest)


• Are there kinds of applications that will always be proprietary? Specifically, why would vertical or niche applications go open source if there aren't many people interested in them? (Something I didn't cover)


• Does Free software destroy the industry and economy around computer technology? (Something I did cover, but either not in enough detail or the person asking disagreed with me)


• If anyone can participate, what ensures the quality of Free Software? (Clever question, not something I didn't cover as I really didn't have time in my talk to dissect the mechanics of the open source model)


• If Microsoft has been saying for years that they will produce secure software but seemingly can't, what chance does F/OSS have in doing that? (I only manage a small tangent on security in the talk in relation to trustability of the software and how that can impact sovereignty.)


• How can non-software endeavors apply the principles that have made F/OSS successful? (This was actually asked twice in slightly different ways.)


• When will we get an open source Facebook? (Something I didn't cover at all.)

What fascinates me about this body of queries is that these are the kinds of questions people have about Free software when they first start thinking about it seriously and critically: economy, security, universality and self-applicability.

The one question that jumped out at me as being unusual and not a question I'd heard a hundred times before at presentations was the one about an open Facebook. I was very impressed that at least one person in the audience put it all together and realized that Free software is great but what about web based services? It's not a question we have great pre-made answers to yet, though things like identi.ca are starting to flesh out the answers.

So ... How will these web sites work? How can we open them up to have the same benefits of Free software on the server, desktop and device? What about the data involved? How about choice of provider? etc..

I hope that online services are simply so young (in their current form) that they will simply mature into a Free software landscape naturally as they go. I hope that we will wake up a little on the server, desktop and devices communities and find ways to make fertile soil for Free online services to give them an additional edge. (On that note, the microblogging Plasma widget now supports identi.ca.)

These are, however, just hopes and hints. I don't see convincing, concrete solutions just yet. We must change that, though, if Free software isn't to find itself being run around by proprietary services online. Food for thought.

Read More

Today's tip: getting to widget menus in the panel

Eventually people find out that widgets can, and therefore inevitably will, intercept right clicks and make it really hard to get at the applet's own contextual actions. Right, Will?

There's nothing Plasma can really do about that. We could try and intercept every right click and show a menu, but what if a widget actually uses right clicks for something different in a defensible use case? It would also be a bit hacky to make that work perfectly, though doable.

So, we have a situation where controlling right clicks is a problem. On the desktop, we offer widget handles and the desktop toolbox so we can guarantee levels of service regardless of what plugins do.

On the panel, we also use the toolbox button to a similar end. If you click on a panel's toolbox and bring up the configuration interface, you can then right click on any applet ... and get the applet's own context menu!

So don't hunt for the one pixel in between taskbar buttons or around the system tray, just click the cashew and then right click the applet. Voila.

Read More

a big day

Yesterday's presentation went very well and I met a lot of really interesting people in the process. You can see my slides here if you're interested.

Lots of dancing and drinking afterwards at the after parties (plural :) and when I eventually got up mid-morning I had a couple hundred emails waiting for me, way too many of which required my attention. I ended up unexpectedly in a few online meetings which altered my expected schedule significantly. Oh well, tomorrow's another day ... on which I have two more presentations to give.

In that same time, The Dot got a great new look and KDE 4.2 was released.

Exciting times indeed!

Where do we go from here? I think we have a lot of work to do to improve processes still, something that will only improve if enough people openly analyze what our processes are, identify challenges, and problem solve. Distributions have a lot of work left here, as right now audio via PulseAudio is experiencing the same problems and for the same reasons as KDE 4.0. That is something that distributions, by examining both their communication and version inclusion strategies, can fix. Upstreams need the room to innovate and that requires making releases in the process of doing so, and distributions can make it possible to both get those "bleeding edge" releases to people who can and will engage in testing without it endangering their work (and our shared reputations) and the "more boring" releases that are "retail ready" to people who rely on our work for day to day productivity.

For 2009 my personal agenda for KDE includes:

• Education: how can we take Plasma and the rest of KDE and provide the most useful system possible without creating a separate silo of code that people won't work on, let alone test.


• Management: kiosktool isn't ported to KDE4. Kiosk itself is still there in KDE4 and works just fine, but the tool isn't. We can also do a lot better than kiosktool in KDE3. I do wonder why these tools bit rot so. I hear that Sabayon doesn't work in Ubuntu either. In both cases distros played a big role in the creation of these tools and then they got abandoned, despite these tools being critical to so much of our user base.


• Marketing: repositioning the KDE brand is really important as we continue to grow to be able to accurately get the message of what KDE is out there. I'd hoped we'd have this done by 4.2.0's release, but now that the release is out maybe we can find the time and attention in our promo community to finish the work.


• Socializing our software: we need to open doorways to the community via our software. There are many ways to do it, we just need to make it happen.


• Plasmaliciousness: continue to make Plasma rock ever harder and do ever more with ever greater elegance.

What are you working on?

Read More

plasma is now plasma-desktop

"Istanbul was Constantinople
Now it's Istanbul, not Constantinople
Been a long time gone, Constantinople
Now it's Turkish delight on a moonlit night"
      - They Might Be Giants

When Plasma was first ripping its way out of my meandering thoughts, I was rather preoccupied with one thought only: "I need something that can improve on kicker ..." When I eventually added the desktop to that thinking I felt I was making progress and getting ambitious.

Well, we're a ways further down the road now and Plasma has become a lot more than a desktop and a panel. It's blossomed into a component model on top of Qt's canvas that is being used by "regular" applications and has katamaried other component systems in the process in a romp towards becoming a more universal canvas.

This has left us with two little historical accidents: the shared settings of libplasma-using applications are in plasmarc with the desktop's view settings and the desktop shell binary is called "plasma". Neither seem overly brilliant ideas given the current usage of the Plasma library.

So this morning I made some commits that changed "plasma" to "plasma-desktop". This makes the desktop shell fall more into line with things like plasma-overlay (screensaver widgets), plasma-mid, krunner, etc. in not claiming sole ownership of the term "plasma".

This also means that the settings for the desktop are now plasma-desktoprc and plasma-desktop-appletsrc. I added a kconf_update entry that will migrate your setting auomatically if you log out and back in or kick kconf_update manually from a command line.

Speaking of command lines, you'll also need to get used to "plasma-desktop" instead of just "plasma" and "kquitapp plasma-desktop" instead of "kquitapp plasma".

One rather positive result is that theme settings are kept separate from the desktop shell settings. They are still in plasmarc. In turn, this has made it easy to add a straight forward approach to have libplasma using apps to re-load the current theme when one of the other libplasma apps modifies the shared theme settings.

These changes will show up in 4.3, and shouldn't really impact the usual interaction of the average user.

"Even old New York was once New Amsterdam
Why they changed it I can't say
People just liked it better that way"
      - They Might Be Giants

Read More

in Zurich

I wrote my last blog entry while at the airport in Toronto between flights, and am now in Zurich. Luca Gugelmann was kind enough to meet me at the airport and hang out for much of the day with me. :)

Besides eating a most amazing vegetarian meal in a restaurant founded in the 1890s that specializes in vegetarian fare, I spent my first day here adjusting to time zones (9 hours of difference), getting acquainted with the city and its public transit system enough to be able to travel about without getting lost too badly and working on my presentation for tomorrow.

The next few days will be very busy for me, so I may be not quite so reachable as I usually am. I owe a few people emails about the book deal and I need to write a blog entry about the results of a meeting I had with educators and educational distro makers last week (we have exciting opportunities for 2009 here), but I may not get to any of that for a couple of days due to my schedule this week here in Zurich.

So if I have a pending communication for you, please excuse my tardiness this week.

Spending tomorrow at the sustainability summit will be interesting ... I really have no idea what to expect yet. I do hope to see every KDE user in town at the 4.2 release party on the 28th here in Zurich.

Read More

choices and punishment

So apparently Linus is using GNOME right now. He mentioned it in the middle of an interview with Computer World and then Slashdot (and I'm sure others) picked it up and ran with it. On Slashdot, the entire six page interview was boiled down to "Linus Switches From KDE To GNOME".

Let me address the "Linus issue" first, because it's the simpler and less critical issue. Linus is precisely one user. For every Linus Torvalds (there's exactly one of them), we have 10s of millions of other KDE users and a few billion who don't use any F/OSS solution at all yet. I don't like losing any user, though, and such a happening can be deflating and make one second guess what they are doing (which isn't an entirely bad thing either, as long as it doesn't result in bad decision making or paralysis).

The decisions made in KDE 4.0 were for the future. A future which we are about to be living in with 4.2 released on the 27th. KDE 4.2 is a phenomenal release and unlike KDE 3.5, which was also a phenomenal release, this new release is a platform that we can successfully build on and compete in the market with for the next decade. It's cross platform, the libraries are much clearer and the technology available in KDE 4 for the user is appropriate to modern computer usage.

While 4.0 was a brutally hard decision and one that cost me (and I assume others) sleepless nights, it was what we needed to do to ensure that we didn't end up stagnating ourselves into irrelevance. By "ourselves" I mean the F/OSS desktop, which includes the Linux desktop. KDE 4.2 is a validation of those choices and while '08 will be remembered as a freaking tough year (mostly for my nerves ;), we're already past that time period and into the beginning of the pay off period. That period will extend several years out, and will gain us yet millions more users on all sorts of systems.

I already know of at least one significant downstream that is migrating to KDE 4 due to 4.2; and no, they aren't migrating from KDE 3. This is the start of the pay off period, though we still have a large amount of territory to explore before KDE 4 is "done". Nepomuk, for instance, is really still only getting started despite the huge leaps forward already.

Now, if Linus needed to get off the train while we rode through '08, that's just fine. It's a strength of F/OSS that you have choices. It's a strength that we can speak openly about it, too. Linus knows that, too, as he said in the article:

"I realise the reason for the 4.0 release, but I think they did it badly. They did so may changes it was a half-baked release. It may turn out to be the right decision in the end and I will re-try KDE, but I suspect I'm not the only person they lost.

I got the update through Fedora and there was a mismatch from KDE 3 to KDE 4.0. The desktop was not as functional and it was just a bad experience for me. I'll revisit it when I reinstall the next machine which tends to be every six to eight months."

I don't think that Linus was out of bounds saying this publicly, either. That's another strength of F/OSS: the ability to engage in open discourse. Compare and contrast how Linus approached it and how the "Linux Hater Blog" style writers do it, though. Linus is using his noggin, being honest and being analytical. That is cool in my book, and I'm confident that when Linus reinstalls his OS in '09, we'll win his attention back; KDE 4 has become just that good. One thing he wasn't in that interview was confrontational and repugnantly rude.

Interestingly, when I said something similarly even handed, accurate but negative about Canonical and Ubuntu in the media once, I got a serious "spanking" in private by the Canonical people and as a result people from other distros chided me as well. ("Don't make waves, Aaron!") This is where the cracks in our community start to show. We need to be willing to accept cross-talk between ourselves.

In that article, Linus said he got burned by his distro updating him to 4.0. I have to admit that it's really hard to stay positive about the efforts of downstreams when they wander around feeling they should be above reproach while simultaneously hurting our (theirs and ours) users in a rush to be more bad ass bleeding edge than any other cool dude distro in town. I hope this time instead of handing out spankings, the distros can sit back and think about things and try and figure out how they played an unfortunate part in the 4.0 fiasco.

The real Kings of Disappointment, however, are the community press who sensationalized the article and raise the choice of one person above the result it's having for all. This, by the way, is why I keep my own choices in software fairly quiet. While certainly nowhere near the same level as Linus in the community, I know just how untrustworthy the community press can be. The behavior they display on a regular basis means we have to treat them all with kid gloves for fear of collateral damage to others.

Here the collateral damage will be fear of innovation. "Don't do anything too big, because it'll cost you and cost you ..." is the lesson some are taking away from all this. Fear is a killer. It's also something that tempers unreasonable risk taking, but it can also prevent healthy risks from being taken. Trotting out a sensationalized story about 4.0 when we're about to release 4.2 is going to have exactly that effect unless we are conscious of this.

I will make another small prediction: there won't be a single follow up story on this if Linus does install KDE 4 in the future. After the damage is done, the community press has a way of just "moving on". There is very little long term commitment to full stories; instead there is rife sensationalism. It's more fun and interesting, after all, and besides who cares about our future?

I hope that everyone proves me wrong on this one, though. I hope someone writes an article taking what Linus said about 4.0 and analyzes the path through to 4.2, the role of distributions in coordinating sensibly in light of upstream advisement and the humps we in KDE tripped up over as well. It wouldn't stand much chance to be sensationalistic, but it would be a useful contribution to the dialog we as a community need to have.

Nobody and no project is perfect. Mistakes will be made, sometimes even in the process of producing success. Punishing each other unreasonably for it is stupid, learning from it is smart. I know we've learned a lot from it and made various changes to improve. We've worked really hard with downstreams to help improve coordination; we've worked really hard on improving external communication; we've worked really hard on making the community robust against divisiveness; we've been working on how to improve the development process with things like "always Summer in trunk" (which has evolved into "always Autumn in trunk" ;) such that we can more effectively chase innovation with less risk.

When 4.2 is rolled out to users, I hpe that we can take some time to do some round-table follow up as a community and engage in some deep reflection on how 4.2 (and future releases built upon it) was made at all possible.

After all, Linus' "hobby kernel" ;) needs a world class interface to match what it has become, and it's up to us to make it.

Read More

do you believe in fate?

I'm not talking about destiny, but rather the new feature tracking system recently launched by the OpenSuse crowd. You can read more about Suse's Fate system on their wiki as well as on Klaas' blog.

It's no big secret that I'm not a fan of Bugzilla. It does the job, it's well known and understood, but .. yeah .. it could be better, shall we say.

One thing I really don't like using Bugzilla for is feature requests. It's just fine for defect reporting, but as a feature request system it leaves a lot to be desired. Uploading screenshots, having discussions, tracking status and much more that is pretty important to the feature request dance is really not well supported by Bugzilla's workflow in my opinion.

The OpenSuse guys, in particular Andre Duffeck and Klaas Freitag, contacted me a little while back about Fate and asked if it might be a good solution for KDE as well. You can read more about their vision for a KDE Fate on their wiki. They even set up a nice little VM image so that I could take Fate and the KDE4 client for a test drive.

Now, all things have strengths and challenges. I think there are benefits to Fate, but also things to consider before recommending it as a successor to Bugzilla for feature tracking. Below is a short list of them with regards to using Fate that I can see.

Strengths

• It's actually designed for feature request workflow. Sort of like Brainstorm, but with more structure. It's actually very "Suse" in that way. =)
  


• It has a rather comprehensive KDE4 fat client so KDE developers aren't stuck with a web browser.
  


• The Suse team would set it up and manage it with/for us.
  


• It seems more suited to enabling upstream/downstream coordination, at least on features.
  


• Fate could improve our communication and remove some overhead. For instance, in the area of feature plans: instead of managing them by hand on a wiki, we could simply approve features in Fate and then Fate could generate reports for us automatically. This would likely be easier for users to track and would certainly be less work for developers to maintain. Essentially, the feature plan would become a by-product of managing feature requests. This can't be the only such opportunity, either.
  

Weaknesses

• We have a ton of feature requests on bugs.kde.org. I have no idea how we'd deal with a transition.
  


• It is Yet Another Website that our users would have to know about and get used to. We could put a link from our Bugzilla to the Fate instance, however.
  


• It is Yet Another Website that our developers would have to know about and get used to.
  


• The fat client is usable, but certainly not refined or 100% feature complete. It's new software though, so that isn't a surprise at all.
  

I'd like this to be launching point for discussion within the community on this topic. I wrote about it in my blog because this is the kind of thing that needs input and support for from users, our community coordinators and the development teams and this seemed like the least audience specific place to put it. =)

Read More

party like it's 2009

In about a week or so, the wraps come off of 4.2.0. That means you have about a week to either make plans to attend one of the 12 KDE 4.2 release parties that are already planned or plan one of your own.

The parties range from as simple as meeting with other KDE enthusiasts in a pub to celebrate with pints of wonder to as orchestrated as the one I'll be at in Zurich which includes food and presentations by both myself and Georg Greve of the FSFE. Regardless of the sophistication involved, each party will be a blast, I'm sure.

We already have parties happening on five continents, but there's a lot of geography still left un-partied. You can fix that by getting something going in your area. If you do, please add them to the wiki page so others can find them too!

Read More

Call to authors

For the last couple months I've been quietly working on a publishing deal for KDE books. I now have a contract in hand and we're making our way to Making It Happen. The number of books under this deal would be significant: 3 250 pagers, 15 100 pagers. That's a lot of writing.

We get to pick the topics and the books will be sold as eBooks both on the publisher's site as well as Amazon (well, pending that part of the deal also going through, but it looks good at this point). Print-on-demand for dead tree versions will also be made available. The intended audiences are end users, developers and/or IT professionals.

Due to the increased efficiency of the digital format, the authors will get a rather healthy commission (above typical industry rates) and KDE e.V. will receive a portion of proceeds as a good-will donation from the publisher.

We have collected a small group of three who will oversee the project, but now I need to start gathering a stable of authors to actually write these books. With that in place and some contract polishing, we can sign off on it and start writing KDE books.

So, if you have decent writing chops (in English), knowledge of KDE and the commitment to pound out 100 pages or more of material (text + images and what not), please email me with your topic idea and I can share further details with you and we can figure out together if it's a good fit for you.

As for non-English versions, translations are a "next phase of the project" item.

Read More

education oriented desktop redux

A week or so ago I blogged about making Plasma components that are designed for classrooms and younger people. Since then, we've had some draft code dropped into playground, a good amount of information written on the wiki and some commitments made to testing the results in real world settings.

It is very heartwarming to see such immediate and voluminous response to a simple blog posting. I'll be taking these early results with me to Tokamak in a couple of weeks to discuss them with others there.

I hope we can get something ready for production use, even if it is something simple and basic but an improvement over the current situation, in 2009.

Input, both of the data gathering as well as the code writing variety, are still welcome, desired and needed.

Read More

living room rock stars

I have a small confession to make: I love playing Guitar Hero and Rock Band. We recently got Rock Band 2 for the household here, unfortunately the drums were defective. A quick visit to the support website followed by a fair amount of traipsing about their pages led to a form to fill out. A couple weeks later and a new set of drums showed up at the door. I didn't even send them my receipt to provide proof of purchase within the warranty period either, even though they said I'd have to. Odd. Still .. yay!

I very much understand why people love to play these games and why they sell so well: it's a way to participate with a very low barrier to entry with something that a lot of people enjoy a lot (music) wrapped up in a fairy tale story (the rock star dream). I think it's fascinating that these games are introducing people to entire bodies of music fr the first time, both old and new, driving popularity and sales for the artists. The integrated song stores are an obvious progression.

What I dislike, however, is how the innovation in the software just crawls along at a snail's pace. Rock Band 2 is not all that different from the original Guitar Hero in most respects. Ok, sure they have the world you travel around on in a more on-linear fashion, there are drums and vocals, you can play with people online, download new music and the crowds and bands are animated much nicer ... but there is really not that much new in the game play. The things you can dress up your characters with are pretty boring at this point. Oh look! Crazy looking guitars! *sigh* The tattoos and what not are interesting, but it's still pretty limited.

None of these progressions are non-obvious or even what I'd classify as "clever".

Here's an example of what would make a really nice touch of the sort that would impress me: providing proper support for combining vocals and an instrument.

I know a fair number of the songs included pretty well, sometimes well enough to sing them properly without lyric prompts. Heck, I play some of those songs on my real guitars, and I've been playing real guitars and singing along at the same time for a number of years. I probably couldn't make a great living doing it ;) but I can entertain friends and family (and myself ;) well enough. So it is that I'll put the mic the stand I still have back from when I was in a band and play an instrument and sing at the same time. Great fun!

There are, however, a few annoyances and all because the game has no way of knowing that you're both singing and playing. Take the vocal "solos" for instance that simulate banging a tambourine or whatever by plonking on the mic. Well, that's not going to happen if I'm also playing an instrument at the same time and is just very annoying. Or how the lyrics stay at the top of the screen; if I'm playing an instrument and singing, I'd like at least the option to bring the lyrics closer to the "play line" for my instrument; this would let me sing more songs that I only sorta-kinda know the lyrics too. Bonus points for showing my character on stage with the guitar and actually singing.

These are not rocket science type things, and I know that the idea of singing and playing occurred to someone working on the games because it was an in-game hint to do try singing while playing an instrument in the first Rock Band game.

The music store, at least in Rock Band 2 (haven't seen Guitar Hero's offering, to be honest) is also painfully annoying to use. I understand there's a way to offer user generated content somewhere, but how about opening that store up to independent artists and splitting the profit with them?

I don't know .. when I first came across this game genre a couple years back I was really impressed with how neat an idea it was. It was like someone took all those crazy stomping and button mashing games like DDR and made something I'd actually enjoy doing while creating a simulated experience. Since then, I've been disappointed with how they seem to just be filling i the cracks here and there but not really Thinking Big or completing the experience with extra slickness (like allowing one to pair up singing with an instrument in the game properly).

This reflects my disappointment with most products on the market these days.

Read More

today's tip: turning off the fancy schmancy notifications in the panel

If you are one of those people who would like their old notifications and/or download windows back, have no fear. Plasma is not greedy.

First, stop plasma with `kquitapp plasma`. Then open up `kde4-config --localprefix`/share/config/plasma-appletsrc and put this somewhere in there:

[AppletGlobals][plasma_applet_systemtray]
ShowJobs=false
ShowNotifications=false

Start Plasma again and voila.

If you're looking for a nice easy job to slide into Plasma or KDE development with, we need a configuration dialog done up for that. Two checkboxes and add it to the config dialog in Applet::createConfigurationInterface(KConfigDialog *parent) in kdebase/workspace/plasma/applets/systemtray/ui/applet.cpp. Easy peasy, and you'll make 4.3 that much nicer.

Update: A patch for this has already shown up on the plasma devel list. Nice..

Also, if you'd like to try your hand at some completely different way to show notifications or jobs in Plasma (or both!), the system tray uses the applicationsjobs and notifications DataEngines and so can you. Hook into either or both of those engines and all you have to care about is the presentation.

Enjoy. =)

Read More

Tokamak II

"After the very successful first Tokamak in Milan, Italy we would like to repeat this at the second Plasma developer meeting in the beautiful city of Oporto, Portugal. The local ISEP institute, kindly offered to host this meeting. ISEP is very interested in Open Source technologies especially exciting and promising ones like KDE's Plasma. ISEP wants its students of computer science to experience Open Source Software creation and community." - From the Tokamak II planning page on Techbase

Tokamak II will be held on February 6th-9th and we currently expect 15 members of the Plasma team to attend, along with some local visitors on the first day. We'll be sure to keep you all informed via the blogosphere as to what goes down at this developer sprint. The focus will be on planning for 4.3 as well as a bit longer term, with an emphasis on integration social features into Plasma and generally extending the power of Plasma even further.

A huge thanks to Nuno Pinheiro for taking the organizational role in this Tokamak, ISEP for hosting our crazy bunch of peoples and KDE e.V. for providing funding.

Read More

what do you get when you remove 128 lines of code?

Shawn Starr was probably the first person to actually start writing a sophisticated DataEngine for plasma: WeatherEngine. He started working on it before 4.0.0 was released even. Yes, he is a mad man, but thanks to his brash insanity Plasma::DataEngine got the crud kicked out of it. It was also where we first found the need for Plasma::Services.

Still, thing weren't perfect. The WeatherEngine uses DataEngines itself and chains them together. So when you ask for weather for a given location, WeatherEngine actually loads a second DataEngine that talks to that specific service. This makes each service nicely compartmentalized and plugin based without a whole lot of duplication of effort.

Chaining the DataEngines was not exactly a straight-forward exercise back then, but Shawn muddled through and the DataEngine API improved alongside those efforts. It did, however, work.

Today on IRC while discussing things like being able to easily add new WeatherEngine plugins, I realized that by using DataEngine for the plugins we should also be able to get scripting and package support ... for free!

Well, almost for free. You see, due to be written "back in the day" there was a lot of code in WeatherEngine for managing its own plugins. Something that today's Plasma infrastructure pretty much obsoleted. I added just one convenience function to DataEngineManager, which I could have just put into WeatherEngine, really. That would have lead to code duplication eventually, though, so into the library it went.

I then put about taking out the custom code in WeatherEngine and replacing it with the libplasma equivalents. The end result was a patch that weighed in at a net loss of 128 lines. Yep, the WeatherEngine actually got smaller and simpler. In exchange for the lost complexity and half an hour of my time, WeatherEngine instantly gained the following functionality in return:

• Support for Plasma::Package'd plugins


• JavaScript, Python and Ruby scripting support


• The ability to list and explore plugins with `plasmaengineexplorer --app weatherengine`


• A very easy way to hook into Get Hot New Stuff / DXS

Remember, while this was initially all designed for the Weather widget, it can be used by anybody who cares to find out weather information. Currently only the Weather and LCD Weather Station widgets do use it, but with libplasma in kdelibs the doors are wide open. Did I mention that neither widget required any changes to their code, not even a recompile, to take advantage of the new and improved engine? =)

This made us all very, very happy. Tears of joy and ticker tape parades through the streets of #plasma type happy.

Code less. Create more. Oh, wait, someone's already taken that slogan, haven't they? ;)

Read More

today's tip: KDE_SKIP_ARGB_VISUALS

If you are having performance issues with Plasma, it's most likely that your graphics card driver has issues with the fancy hotness known cryptically as "ARGB visuals". In plain terms, they let us do fancy translucency. Without them, you still get a nicely composited desktop, but the panel will not be translucent, popups will look a bit more plain and you won't get all the hot sizzle you deserve from Plasma.

Still, for some, that's the only option. Today I was talking with a fellow on IRC who manages thin client KDE deployments in school environments, and they have the challenge of old hardware for which there is no realistic chance of new and improved drivers appearing. It occurred to me that we ought to have an environment variable for this.

When I opened up the appropriate source file, I was delighted to see Seli had already stumbled upon this idea and implemented it. Huzzah for open source!

So for those in such situations, you can selectively turn off ARGB visuals when Plasma starts simply by ensuring that the KDE_SKIP_ARGB_VISUALS environment variable is set to the value "1" (without the quotes, obviously ;) and life will be slightly sweeter for you, if a little less pretty.

This appeared during the 4.2 dev cycle, so KDE 4.1 users are probably out luck ... but you wanted 4.2 anyways, right? ;)

Read More

purpose specific containments.

Reading this article got me thinking again about a set of ideas I was playing with back in 2006 that helped lead to the Activities concept: use case specific Containments.

Right now we have a few containments (Desktop, Folder View, Panel, etc.) but they are all general purpose containments. They are meant to be general containers that can contain random sets of widgets in any sort of layout. Useful, no doubt, and absolutely required.

I don't think they are suitable for every use case, however. Listening to one of the people involved in the desktop roll out in the Gran Canarias at Akademy a couple years back, it became rather apparent that they really wanted to use the desktop in a way that most people didn't. They fudged a solution together, but it was a hack.

The article linked in the first paragraph above brings out another interesting point. Now, they could do what they want with some kiosk settings, but it would be a rather bore to do so and I'm not sure how teacher friendly that would be.

The bits we already do alright with is that you'd need to lock down console access so students can't run arbitrary things and then provide custom menu layouts and sets of apps on the desktop. Still, not exactly a five minute job and I think it should be. Locking down console access is one kiosk entry, but the menu arrangements and setting up the kiosk groups: quite a bit more time and a fair amount of technical details. Not teacher friendly.

Given how often teachers end up having to do the set up themselves, this is important. So I think we ought to have a set of containments and widgets appropriate to the classroom, then it's just a matter of creating an appropriate Activity, changing the panel a bit perhaps and voila.

Thing is, I'm not a school teacher and that means I shouldn't be the one to design this thing. If you are a school teacher, you'd be the "right" person for this. In fact, I would like to see a small group of educators or education IT support staff get together and brainstorm what a perfect desktop would look like and work like. I'm not suggesting a full classroom system with grading and all that stuff (I'm not insane ;) but just the desktop bits. What would make it work better for you?

I've created a page on our developer wiki where you can go and start putting ideas down. Feel free to use pictures, words, whatever. We can sort it out and then figure out how to implement it. I get the feeling this could make an awesome Google Summer of Code project.

But we need you, the educators, to step up and give us feedback. Not sure when the last time you were asked to help design a desktop just for your needs, but now's your chance.

Read More

KDE: Linux Format's Free Software Project of the Year

Linux Format recognizes stand out projects and members of the Free software world with their Reader Awards. The readers of the magazine send in their votes, Linux Format (LF) tallies them up and then publishes the results.

In the awards overview article, LF observes that "it takes a lot of planning, a lot of hard work, some serious code fu and, above all, a commitment to the ideals that underpin our movement."

How true. In recognition of the path KDE took in 2008 from the initial 4.0 release through to our current effort, the readers voted overwhelming for KDE as the Free Software Project of the Year. This wasn't a desktop only category, it could have been any Free software project. To all the users who voted: thank you! To everyone contributing to KDE in any of the many ways possible (coding, translating, usability, artwork, community guidance, marketing, biz dev ...), a huge congratulations and thank you to you as well.

On the awards broadside page, LF writes:

"A landslide for KDE, and rightly so: the team have done an incredible job of getting
KDE 4 stable and they deserve the glory. To celebrate, we think we should dedicate our
next cover to KDE…"

So be sure to pick up the March edition of Linux Format: it's going to be chock full of KDE goodness.

Read More

Qt goes LGPL!

As of version 4.5.0, Qt will be released under the LGPL version 2.1. Jaw off the floor yet? Good.

The motivation for the licensing change is summed up by the mantra: "Qt Everywhere". Nokia and Qt Software are committed to removing every single blocking objection against using Qt that it feasibly can. This includes licensing quibbles. Whatever the merit of the GPL vs LGPL arguments were, this is a pragmatic decision taken to make it all a moot point and broaden acceptance of Qt.

As can be seen here, the LGPL v 2.1 is compatible with all the LGPL / GPL version combinations. License exceptions for other Free software licenses will remain in place and commercial offerings for those who need or desire them also remain, complete with commercial support.

Just as exciting is Nthat okia will also be opening up development of Qt to the broader F/OSS
community. The maintainership, governance and overall ownershp of the core products will remain with Qt Software as they have, but a path for external contribution is being built. That includes public repositories and the whole nine yards. Details on this will be provided by Nokia as it becomes available.

This is next step in the evolution of policies around Qt will grow the market for Qt substantially, both in the F/OSS as well as the proprietary software worlds.

Qt everywhere, indeed!

This is not a signal of Qt Software or Nokia distancing itself, slowly or otherwise, from Qt as a viable product and simply "giving it out" to the community as a move towards abandonware. Nokia and Qt have reiterated their commitment to a commercially viable Qt and Qt remains the Nokia mandated toolkit for all their internal development. The simple fact of the matter is that Nokia is not nearly as reliant on the income from Qt licensing as Trolltech was, and this gives them greater latitude to try new approaches to the market.

All-in-all this means tremendous things for Free and Open Source software in general. The possibility of extending the reach of all of our work is exciting in and of itself, and this will undoubtedly lead to a veritable explosion of Qt and KDE adoption.

Read More

i will not drink the koolaide.

Quick note: when I started using Phonon everything Just Worked(tm), including Skype and Firefox and mplayer and DragonPlayer and Amarok and ... everything cohabited and was beautiful.

I upgraded my operating system and was "blessed" with PulseAudio. Now nothing Just Works(tm).

This is the difference between a system well thought out (Phonon) and a system so convoluted and in search of a problem to solve that it simply messes it all up in the process.

I had no need for PulseAudio. I had Phonon + Xine and Phonon + GStreamer and life was wonderful. I hope, based on my personal experience with PulseAudio, that others wake up and realize that, no, it's not necessary and that yet, it does complicate things and that, why, we'd prefer things to Just Work(tm) versus become a mess.

I've seen the block diagrams, I've been to conference presentations explaining how it works. The insane complexity of it all horrifies me.

Regardless of what others say about PulseAudio, I will not drink that kool-aide.

Read More

little hints

It's no secret that I'm a slightly busy person. Thankfully I'm surrounding by companions who are graciously understanding of this. However, from time to time they drop me little hints.

For instance, the other night before going to bed I noticed this sign above the stove giving me breakfast instructions:

Apparently the P-man got tired of answering my questions in the morning and then me subsequently getting it wrong anyways. Fair enough, mornings are not my best time of the day. Ask any of the KDE people who have the .. uh .. "pleasure" of experiencing me before, say, 10am.

(Those who have seen me at conferences and whatnot up before then and appearing spry and alert and full of energy: just know how much effort it takes to override my natural state of being at such ungodly hours of the day!)

P's favourite morning food these days is eggs, but apparently without ketchup, with a knife and a drink.

He's not the only one to drop little hints. While doing the dishes the other week another of my constant companions, George the Cat, decided to let me know that he wanted some attention. He did this by cleverly pretending to be a plate, knowing that I'd soon be by to put other plates in that spot:

Others appear less frequently, but with no less impact or obviousness. It always surprises me, in a warming and confirmational manner, when someone pops up from five or, sometimes, even ten years prior to let me know that they, too, are still there.

Karen from Australia: if you're reading this, hello! =) I still have and love those green socks, and now I truly wish I'd dropped you a line when I was in your country last year. I'll try and make up for it with some strumming on my little guitar, fed into the computer, spat across the world ...

Read More

p.s. above all, enjoy.

There is a "post script" to my last lengthy blog entry about building community around a project. I wasn't sure where to put it where it wouldn't get lost, so here it is in an entry of it's own:

Above all, in all things you do in your project, enjoy it.

That last blog entry may have sounded full of dreadfully hard or boring things to do, but they aren't really hard and they aren't really all that boring. They just take adjusting to and need to be integrated into your daily process. Once of the hump of "newness" you won't even notice it any more.

Before, during and after integrating whatever changes you may decide to make (or not) be sure to guard with jealousy the enjoyment you derive from doing what you do. Enjoyment is the single most potent feeling a human being may ever feel, as it lasts longer and lifts us up higher than other things we may experience. Enjoyment over time leads to fulfillment, and keeps us going during the hard times.

So always enjoy, and let other people enjoy, whatever it is you do.

Post-script concluded. =)

Read More

building a community around your F/OSS project

Today has turned into another writing day for me. Huzzah! I started going through my list of blog-posts-I've-not-yet-written and decided to punctuate the day with a couple of them. So let's talk a bit about building a community around your F/OSS project.

Usual disclaimers apply: this is what works for me, it may not work for you; I could be completely insane and talking about my posterior; I probably am just repeating what other people have said elsewhere; I'm going to be hypocritical in places by giving advice that I don't follow overly well myself. So there.

Onwards!

Why It Matters

It is not uncommon to read about projects that are suffering from lack of development resources. Let's be honest: no project has "enough" people, ever. There's always something else that could be getting done "if only we had another pair of hands!" Some projects suffer more than others, however.

Recently, one of the OpenOffice.org developers opined about the demise of developer contributions, a KStars developer sent out a small S.O.S. on their blog on planetkde.org, we watch projects like Enlightenment or Perl flounder endlessly in forever betas that really damage their developer base, Pidgin was highlighted as suffering from development stall and there are many other projects I keep an eye on that have me .. well .. concerned.

It makes little sense to invest time and energy into a project only to see it hit a Good Point In Development(tm) and then erode as the original developers leave. It is a fact of life that churn will occur in a project. "Churn" is a term from corporate human resources that refers to turnover in job positions. There's always going to be churn in any organization, though: people's lives change in many ways that result in them no longer being with the organization. Free Software is no different, and is often worse than one would like to see in a corporate environment.

This is why building a community around your project is so important: it will either outgrow your current team's abilities to keep up with and/or your current team will no longer work on the project. When that happens, it's a little late to start thinking about project longevity and health. Build now for when things are less good later, and then things never will be less good. This is called "sustainability".

So ... your project requires new blood on a regular basis. Here's maybe how to get some. (New community members, that is.)

Principle 1: The Barrier To Entry Can Never Be Too Low

Every minute someone has to spend getting up to speed before hacking on your project represents lost contributors. Spending time eliminating barriers is therefore one of the best investments for the future you can make. There will always be some barrier to entry, after all a new code base is a new code base and takes some measure of time to get used to. How high the minimum barrier can be will vary from project to project, as well. The more technical and complex the application or library is, the higher the minimal barrier will be. Still, reach for that minimum barrier.

Here are some things to watch:

Code Clarity

Before I worked on F/OSS full time I used to spend my evenings reading the source code of various projects. (These days I'm a bit too busy for such luxuries.) I read the source code to Apache, OpenSSH, PostgreSQL, numerous Gtk+ and Qt based applications, etc .. Not much different from reading a book to relax, really. The consistency, or lack thereof, of the code in some projects was striking. It was amazing how much quicker I was able to read through well structured code and get a feel for what was going on compared to some of the less well structured messes I opened up in my text editor.

Best of all: this is low hanging fruit. It's the kind of stuff that is easy to keep in shape with just a bit of discipline and the kind of stuff you can fix on a rainy Saturday when going out isn't such a fun prospect.

What makes up clarity in code structure?

• Code consistency: There is nothing more frustrating when reading a new code base than having N different coding styles. Be strict about style adherence; don't worry about this chasing people off because they can't "code they way they want to". For every one of those people you might lose (and they will be few), you'll gain more to replace them.



• One file, one concept (or class): By putting each class (or concept) into one file you will make it easier to find things, easier to edit things and quicker to build. A decent IDE can mitigate the finding issue, but editing is still done per-file in most IDEs. That means that if you have a file with 10 classes in it that are all related, chances are you'll be forcing the developer to jump around in that one file. You may have a perfect mapping of it in your head, but allowing people to have 3 files open to the exact place they are editing and switch between them is great. A good IDE will provide multiple views on the same file, but it still is a headache to peruse files with multiple classes. What an IDE can't do is limit compile times, and a file that is 5000 lines long will take longer to compile than a file with 1000 lines of the same general complexity. For header files this is multiplied by every file that includes that header. Time spent compiling is time spent doing nothing, and time spent doing nothing is discouraging for new users. For those with awesome IDEs, they aren't harmed by the one file, one concept approach, so there is no downside to doing this. In the F/OSS world, a lot of people don't use an IDE, however.



• File structure: Having one directory with 100 files in it sucks. The new comer will look at that and run screaming. Divide up your code into directories that are topical and make sense. This becomes a sort of self-explanatory mapping of your source tree and helps immensely. Don't get silly and have one directory per file, of course, but if you have a directory with more than a few concepts represented, think about breaking it out.



• Don't get clever: You may some super duper clever way of doing something, but if it comes at the cost of code readability think twice. If it doesn't really gain you all that much pass on the opportunity to be clever. Keep it simple and the people who come after you will love you for it.



• Document your cleverness: There are times you have no choice but to be clever. Some problems are just not easy to solve and to be solved well they require non-trivial code. When that happens, be sure to leave meaningful comments in the code so people can understand your cleverness.



• Readability: Remember that most people learn to read a natural human language before they learn to code. Human language is messy and imprecise, but it evolved around our strange, messy and imprecise brains. So when you write code, make it readable: don't use single letter variable names unless they are "well knowns" like the "i, j, k"s of loop counters. If you can't figure out what a variable represents by the name alone, your name is probably crap. If your name is crap, new comers will take longer to understand what you were doing. That would be bad.
  
  There are many other ways to make code readable, such as using whitespace effectively. There are other places to read about that, though. Just keep in mind: the code should be readable.



• Document Your Design: (This is where I become a bit of a hypocrite ;) Document the design so people can get a high level view of what's going on right away. Reading the code should simply be filling in the details. If I can read a design overview, then look at the file structure on disk (or class hierarchy in an IDE) and then read the code I care about ... I'll be hacking on your codebase in no time.



• Keep The Edges Easy: Concentrate complexity into the inner core of the code base. Spin simplicity out to the "edges" of the code. The "edges" are the bits that people are most likely to start reading or working on. They are the bits that deliver the most visible functionality, for instance. Keep those parts of the code base extra, extra clean and happy. That way there is a "shallow end of the pool" for people start off in and they can slowly wade their way in deeper and deeper until they start crunching on the hard core concepts at the center of your project. Plugin systems and scriptable interfaces are awesome for creating "wading pools" for people to play in.



• Use The Tools: In the case of a Qt/KDE based app, that means use things like KConfigXt, Qt Designer, etc. By using standard tools people may already be familiar with from other projects, especially related projects, you lower the learning curve. Resist the urge to do it by hand or "do it better". Use the tools and you'll get more contributors who have transferable skills. This, by the way, is why one should choose a version control system and programming language based on a maxima of the combination of technical appropriateness and audience familiarity. Writing something in Haskell using Mercurial is basically saying, "I don't want you working on this." Unless, of course, your target developer audience is rife with Haskel hacking Mercurial lovers. Note that this has nothing to do with the Goodness(tm) of Haskell or Mercurial. Sometimes life really is about popularity contests.

Be Ready For Contributors

Making the project ready for contributors is like cooking a nice meal: people will want to eat something that smells good, looks tasty and is full of nice ingredients. However, if they show up for the meal but you don't have plates and cutlery and places for them to sit while they eat ... it's going to hurt your turn out. Imagine a restaurant with the best food in town but no tables, chairs, serving containers, eating utensils or people to take your order and serve you. It probably wouldn't go so well.

Don't be that restaurant:

• Have a host: You know that person who greets you at the door of the restaurant? You need one of those people. That means you also need to have a "front door". That might be IRC, it might a mailing list. Whatever it is, people need to be able to find it and you need someone(s) there to say, "Hi! Welcome to the project.." Nothing hurts more than showing up with a question or a patch and being met with silence. If I walk into a restaurant and nobody comes up to at least greet me within 5-10 minutes, I leave.



• Have appetizers: Appetizers are not supposed to be the main meal, though I have been known to, on occasion, order a bunch of them and make them into a meal. =) Regardless, appetizers are small, tasty bits of food to get your palette and stomach started with. Every software project should have appetizers ready, too: something easy and quick to do. Some projects call these "junior jobs". Whatever you call them, keep a few of them in mind at all times. At some point, someone will randomly ask you, "I'm new here, what could I do?" You must have a quick answer for them, and the answer must be precise and describe something reasonably simple (relative to the project's overall complexity) to tackle. The goal is to get people into the shallow end of the pool munching on appetizers as quickly as possible. This is how you hook people.



• Have a main course: Without a main course, your screwed. Everyone just fills up on appetizers and the core of your project rots. Make sure there is a path from appetizer to main course and that people are encouraged to follow that path. Not everyone will. Some will be like me with appetizers and just fill up on those. That's Ok, of course, but encourage those with bigger appetites to move on. They are the people who will one day replace you. That is a Good Thing(tm).



• Have a menu: Without plans, you're screwed. Nobody will know which way to go and so everybody will go nowhere in particular. Know where you are going and when you are going there. Communicate this on a regular and timely basis.

Remember There Are More Than Coders!

I've been talking mostly about coding so far, but remember that you also will need documenters, translators, community representatives for user relations and marketing, artists, etc. Treat these people just as well as you would a prize coder. Most importantly, let them do their job. If a translator says "I need more context for this string to be able to translate it" bloody well add that context! Don't ask why because it doesn't matter. If an artist says, "This is the image I want to use", use it.

Now, this requires trust. It also requires goals. Hey, that's just like with coders! Only we developers tend to forget that art also needs a direction and an end point. You can define what you want the end artistic impact to be for your project, but let the artist doing the art determine what it means to reach that goal. If they stray from the goal, then you apply leadership. But don't micromanage these contributors out of your project, and remember that when it comes to something like localization, documentation or art ... these people probably are better at it than you are. This is not something developers are good at admitting, so practice it in front of the mirror. ;)

Create A Culture That Inspires

No matter how boring the topic is, a friendly culture can make nearly any task enjoyable. For those of us who like to write and work on code (those are the people you want most, btw), what the code is matters less than having a fun place to work on it in. So make a fun working environment. This takes leadership.

Leadership is a learned skill like any other. If you don't feel that you are a good leader, that's not because you have an irreparable character flaw, it's just because you haven't practiced that skill enough. You can be a good leader, and that will mean being your kind of leader. People lead in different ways, so I'm not going to preach a given leadership style. I am going to make some clear suggestions that can be applied to almost any style of leadership and which are pretty critical in my experience for dealing with creative brainy types.

• Communicate: Have meetings on IRC, respond to emails on the mailing list, blog regularly, set goals for your project and then communicate them to others. Better yet, work on those goals with others and, through communication, build your goals together. Sometimes people will need to speak with you one-on-one, and that personal communication will often decide whether the person stays or drifts away. People bond through relationship building, and relationships are built by communicating. That means open, honest and truthful communication. Don't be a dick, but don't treat people like 2 year olds, either. Speak straight to them as equals and speak as you'd like to be spoken to. Also realize that you will fail at this from time to time. Work on it, always.



• Know your stuff is cool: Why are you working on that project? If it isn't because it interests you, you need to reassess how you make decisions on how to live your life. Seriously, no job and no amount of money is worth working on something you don't enjoy. There are enough opportunities out there for any hard working person to find something you enjoy doing. That said, if you enjoy doing what you are doing, then there is something inherently cool about what you are doing. You don't need Slashdot goofballs to tell you what's cool and what isn't: if it's enjoyable to you, it's cool to at least one person (you). You are not unique. Therefore there will be other people who feel it is cool, too. So without shame, fear or hesitance tell the world exactly what you're doing. Blog about it, and don't apologize for doing so. It may seem silly, but if you write about it someone, somewhere will find it interesting. Tell people what is happening, how it is happening and where you are going. Use screenshots to communicate that coolness, or better yet: screencasts! Expose your own enthusiasm for what you do, and others will respond with their own enthusiasm. Like finding a lover with interests similar to your own, this may not happen immediately. But it will happen eventually. Keep talking about it, and do so from your place of personal enthusiasm. Telling people how crappy and hard your project is won't help, so keep the venting (we all need to from time to time) to a minimum. Telling people about what you actually accomplished last week, however, will inspire even if it's "mundane". One of the KWin guys blogged mostly about bug fixes made over the last month or two and I actually found those blog postings inspiring: long lists of bugs crushed! And yes, your project is as sexy as Plasma or whatever else is considered the new hotness. Never doubt your own interests.



• If you are successful, you will end up being wrong: Successfully creating a community means you will end up with people around you who are better than you at some things. Let them be. It is a gift and a blessing to be surrounded by talented individuals. This does mean that you will at times likely feel a bit intimidated by them on certain topics and that they will at times prove you to be *gasp* wrong. If you are never proven wrong and you always have the best ideas then you are (a) fooling yourself, (b) a deity, (c) your team sucks or (d) your team is not really trying. This is why not being the best at everything all the time in your circle of friends and workmates is actually a sign of success. The people you surround yourself with will make your project better than you ever could alone.



• Allow mistakes, reward success: Mistakes will be made. Let people know when they've made a mistake. Don't berate them for it (more than they deserve, anyways ;) and always show them how it could be done better. When you make a mistake, admit it. This builds trust both ways. Nobody cares if someone makes a mistake, they only care when someone refuses to admit it. Conversely, when someone succeeds, give them the props they deserve. Say thank-you whenever you can and tell someone when you think what they did was cool. If it was a hard, long road (particularly if you made it long and hard on them by demanding excellence) be triple sure to let them know that you respect what they did and appreciate the results. By acknowledging success, you will also have more latitude to correct mistakes without hard feelings.



• Don't let people tell you you are wrong if you aren't: This is going to sound a bit contradictory, but you need to also know when you are right. People in your team, and particularly people outside your team (the transparency that comes with F/OSS also comes with numerous loud mouths who actually don't know squat), will sometimes challenge you on a point. If you know you are right, stick to it. Don't just follow the wind whichever way it blows. This is perhaps one of the hardest skills to pin down with leadership: knowing when you are right, and knowing when you might not be right. Having a confidant you can bounce ideas off of for a reality check is helpful.



• Don't play politics inside your project: Don't let politics enter the picture. Demand that everyone comes in on a level playing field. Require people to work together with the same expectations and commitments. If someone can't figure that out, let them know they can leave. If they refuse to figure it out, tell them to leave. If someone tries to inject politics into your project, come down like a ton of bricks on them. Most importantly, do not ever be the person injecting politics into your own project. Set standards, adhere to them, expect others to do so as well .. but leave the politicking out of it. If a company joins your project, require them to do the same. No amount of money today will save your project if they screw up the culture. If you care only about money, hey, go for it and sacrifice your baby. If you care about your project, prioritize it above money, popularity or other vanities. You will attract more money, popularity and vanities that last and do not kill the project in the long term this way.



• The project relies on you: Take personal responsibility for the project. When problems arise, commit to a solution. When hard work needs to be done, show how it's done by doing it.



• Make yourself irrelevant: Having achieved the above, this is the most important thing you can possibly do. You will not live forever, your interest in your project may not live forever, your life may not forever allow you to work on your project of passion. Therefore, for the sake of your project, you must be replaceable. Anything you know, someone else must also know. New people coming into the project must be taught these things, too. Now, sometimes you'll have someone who does have a special spark about them ... a certain crazy creativity or vision or whatever. The shocking truth is that even after those people move on, any project can continue on successfully as long as you do not come to rely exclusively on that one person. Apple never learned that, and they had to bring back the Man That Makes It Happen as CEO to get the company back on track. That is a consummate failure on Apple's, and by extension Steve Jobs', behalf. Never rely on one person and never, ever think you are such hot shit yourself that you ought to be irreplaceable. You aren't. I'm not. Nobody is.

Build Clocks Rather Than Just Tell Time

In the book "Built to Last" they talk a lot about "clock building", which is the practice of building methods of doing things and passing that knowledge on, versus "telling time" which is simply observing what the right solution is for other people. Steve Jobs can certainly tell the time on the Clock Of Technology Cool, but has he built a clock for others to use when he's gone? He didn't the last time he was with the company and it nearly killed Apple, which is why while I have great admiration for the man, I also think he's something of a moron who suffers at the hand of his own ego. If he was actually doing his job, nobody would care about his health nearly as much as they currently do because it wouldn't matter nearly so much if he were there or not. That sounds harsh, but it's reality.

So it is that I ask myself constantly if I am building clocks for the KDE community to use or if I'm just "telling time". I have no plans of leaving in the foreseeable future, but the future is just so unforeseeable that I try not to fool myself that I'll always be here. One day I will not be here. If in spite of my absence KDE becomes greater than it was when I was involved, then I will have personally succeeded. I will have done the most I can do for the project once there is nothing the relies on me and me alone. Perhaps I already have nothing left unique to offer. In which case, I can continue to do what I do until such time as I'm done doing it.

This brings us the principle of being able to let go. Delegate, pass responsibilities around the project, let other people hold the leader stick at times. Teach by doing, and remember the people who show they are learning by what they are doing. Take care of those people, because they will be the people to step into your shoes when needed and who will grow your project bigger while you are still around.

Well, this post has become far too long as it is, though it is also far too short to cover the topic at hand in any sort of useful manner. I hope it doesn't come across as preachy, it's more a "brain dump" of things I've learned. I wish it also contained the things I haven't learned yet, too, but I'll have to wait for a future me to write those blogs. ;) Perhaps, though, you will find some bits of usefulness in this post as it is. My hope is that you do, and that it becomes a part of the clock you use in your own project.

Read More

monday is a writing day

After taking the weekend mostly off (I hardly hacked, just barely kept up with email and was on irc for only a handful of hours) I'm feeling refreshed. Laziness in doses has its merits. Namely, to give one the energy and hunger for action that keeps laziness as a general state of being at bay. ;)

Today is a writing day for me. I have two documents that I've started that must be completed by today. One is for the membership of KDE e.V. and should be arriving in their mailboxes sometime tomorrow. The other is for my keynote presentation at the Student Summit for Sustainability in Zurich later this month.

I love to write code, I love to design, I love to write, I love to listen to and make music and I love to consider the deep mechanics of complex systems (which makes humans a wonderfully fascinating topic). The problem is that I love to do all these things quite a lot, and so whenever I spend too much time on one of them to the neglect of the others I find myself "itching" for "something". Usually I find that "something" is one of the other topics of love in my life.

When I sat down at the computer this morning I knew it was going to be a day full of writing, but it wasn't until I actually started into it that it occurred to me that I have had a writing day in far too long and that I was just itching for it.

So while I probably have mountains of code to write, design ideas to ponder and far more questions about complex systems than I could ever hope to untangle in ten life times ... today I sit and indulge in the process of stringing words together.

I hope you all are having an equally enjoyable Monday. If not, be sure to put aside some time for something you love today. I find that even fifteen or twenty minutes of such "indulgence" is usually enough to smooth out an otherwise frustrating day, and when I forget that bit of wisdom I lose entire days to darkness.

Hugs ... aseigo.

Read More

git library?

I went looking for a library interface to git tonight. (I can already hear some of you laughing.) Turns out that my assumption that there must be a nice git library out there somewhere might have been a bit .. naive.

Git itself makes an archive of the common files that it uses in its various C apps and links those into each app. In what can only be a fit of humor, it calls this thing a "library" in its Makefile.

Yes, more humor: a naked Makefile. After all, real mean don't use pansy tools that might make life easy like configure of cmake, right? Anyways .. I really didn't go looking for a build system, I went looking for a library I could use to interact with a git repository.

Why a library? Well, I really don't want to be running external commands and then parsing their output. Unfortunately that seems to be what most other apps that provide git fronts seem to be doing.

I got slightly excited when I saw the "Interfaces to other programming languages" on the Git wiki. I though, "Ok, so I won't be doing this in C++, that's ok .." only to find out that I could write in ObjectiveC (uuuuh..) or Java (mmmmm.. no.) Both fail for not having KDE4 bindings. Unfortunately both the Python and Ruby git thingamabobies are for read only access. After all, who wants to commit, anyways, right? *sigh* Dashed once again, I return to the idea of doing it in C++, but the specter of having to parse command line output just makes me cry.

A small spark of hope remains in me knowing that I am not intimately familiar with the world of git and therefore may be missing that wonderful bit of interface glory that I call "libgit.so" in my daydreams.

Why would one want such a thing? With a nice sane API to a nice flexible SCM we might actually see some cool integration into desktop applications to make user's lives easier.

So .. does anyone out there have a link to such a "libgit.so" type thing? If so, I promise to make something cool with it. =)

Read More

bugs.kde.org

I work with bugs.kde.org nearly every single day.

Most people who report bugs on it hardly ever visit it, and that's not a bad thing.

Some people who do end up there are frustrated due to some problem they ran into and so show up a little less than happy. Most are congenial, however, which is nice.

Unfortunately, there's still that familiarity gap. I have built up over the years a set of internal expectations around handling the bug system that I know are completely non-obvious to anyone who doesn't use bugs.kde.org often .. which is most of our reporters .. which leads to frustration. Everyone couple years I blog about this frustration. This one of those blogs.

Sometimes I honestly think a "bugs.kde.org driver's test" should be a prerequisite to using the system. It would go miles to improving the quality of the reports. In lieu of that, here are some quicky notes on handling bugs.kde.org:

• Always include the version of KDE you are using. If you build from svn, then include the svn revision #. Otherwise, `kde4-config --version` is perfect.


• If reporting a crash, provide a detailed description of what led to the crash. If reporting a functionality bug, describe the steps in detail needed to reproduce the problem. If you don't know, just describe as much as you can about what you or the machine was doing at the time. These descriptions help us replicate your experience which is critical to solving many reported problems.


• If you are reporting a crash, always include a backtrace. If it has lots of "unknown symbols" in it, though, it's not likely to be very useful and your description of how to reproduce will be even more important. However, first consider reading this how-to on creating nice backtraces and get a realy good backtrace for the report.


• Do not upload backtraces as attachments to reports! Instead paste them into a comment. This lets us easily search the database for similar backtraces. It's easy to search through comments in Bugzilla, not so much so through random attachments.


• If the bug is rendering related, include what the graphics hardware and driver version is. It may not be relevant, but it often is and will save a "what's your graphics hardware?" roundtrip question.


• If the bug has a visual manifestation (e.g. you can see the bug itself or symptoms of it somewhere on the screen) consider taking a screenshot of it and attaching it to the report. Screenshots are often very, very useful to understanding bug reports. Pictures and a thousand words and all that.


• If you can't reproduce the bug after a while, let us know. That's useful information.


• If we ask for more information, try and respond as soon as you can. Some bugs are easier to fix at certain times than others, for various reasons. Helping us by being attentive is much appreciated. If you can't get to it right away, or if you feel the answer you have isn't a good one (e.g. you tried what was requested, and nothing happened) still report back with either a "I'll get to it when I can" or "I tried it and got nothing useful back". At least this way we know you're still there.


• Do not post to random bug reports unless your problem is the exact one in the original report. If you have a crash and your backtrace does not look identical at the top of it to the one in the report, do not add it to an existing report. If you have a similar sounding but not identical problem, do not add it to an existing report. File new reports. Bugzilla lets us merge reports, but it does not let us take a single comment and break it out into its own report. I wish it did, but it doesn't. Yes, this is a shortcoming in Bugzilla, but it's one we have to live with. This means that if you just pile in new bugs into old reports, we end up with reports that are completely unmanageable. Eventually, I just end up closing those kinds of ruined reports and make everyone file new ones.


• Which leads to: one problem per report. Yes, Bugzilla is not the fastest tool to use and so it can be tempting to just pile in 2, 3, 5 or sometimes even more issues into the same report. Don't. It becomes very hard to track which issues are fixed and which aren't. Again, this is mostly due to shortcomings in Bugzilla, but it's the reality we deal with. File separate reports for separate issues; and yes, even if it's two different issues on the same topic. ;)


• Whenever you comment on a bug, the assignee(s) and the people on the CC list get an email with your comment in it ... even if the report is closed. So feel free to add comments to reports, someone somewhere will still get a notice of them.


• Fixes will not appear immediately on your computer. You will need to wait until you update your installation to a version that contains that fix. Depending on when the fix is made and how you install KDE, this can even be many months time. This may sound like an obvious item, but many people seem rather surprised when I mark something as fixed with a commit to svn but the problem is still there on their computer.


• Describe your problems thoroughly, but don't get too clever unless you've actually read the code. Way too often I get reports where the person has a pet theory about why something is happening and unfortunately the theory is dead wrong. At best it's just a waste of my time reading that part of the report, but more often it ends up confusing the report with some misinformation and worst case (which happens too often) the reporter gets so caught up in their idea of why the bug is happening that they end up describing that theoretical problem as opposed to what is actually happening. This risks confusing the bug triager, and often just means a long series of back and forth questions. If at all in doubt, just describe the problem as it manifests itself as thoroughly as possible. Leave the root-cause sleuthing to those with the code in front of them.


• You don't have to suggest a solution. It is perfectly Ok to say "This doesn't work for me." and leave it at that. If there is a preferred way you'd like to see it happen, describe it in those terms: "I would prefer if ..". But as the reporter you don't have to come up with a solution.


• I hate the term "wishlist" because it makes it sound like something you'd like to have but probably won't get. I far prefer the term "feature request" because that's what it really is, and "feature request" lacks all the implications of "wishlist". Some people get really annoyed when I mark their report as "wishlist" and in one sense I don't blame them; if you didn't know any better it might sound like your report has just been brushed off. That's not the case, however: if the request is for a new feature or new functionality, as opposed to fixing existing functionality, it's a feature request not a defect report.


• Don't bother overstating the severity of your bug. It won't fool anyone. Seriously. =)


• Don't bother linking to your favourite bug report from your blog, on web forums, on irc, etc hoping people will vote for it. When I see a bunch of people randomly showing up to vote on a report, I assume this is what has happened and ignore those votes. Such vote canvasing only distorts the statistical distribution of voting on bugs.kde.org and makes it impossible to distinguish between reports people actually, really want fixed and ones that someone has just done an effective job of campaigning for in online forums. ;) In general, I put far more weight behind how many duplicates a report has than votes.


• When it comes to feature requests, a judgment call is often required. That call belongs to the person(s) designing the software. If they decide against a feature, don't belabor the point by endlessly trying to convince them or getting angry with them. It doesn't help anything.


• Saying thank-you even once makes up for 10 mistakes made elsewhere. It's really encouraging when a reporter is civil, cordial and says "thanks" when the fix goes in. Dealing with reports on bugzilla is, quite frankly, not the sexiest thing in the world to do, so anything that makes it go a little easier and nicer helps.

Probably not an exhaustive list, but there you go. Hopefully something in that list is useful to someone out there at some point in the future. =)

Read More

4.2 RCs tagged, trunk is now 4.3.

Earlier today Dirk sent a message to the release team and KDE core devel mailing lists noting that KDE 4.2 is now branched off of mainline and that the the first RC is being tagged. That means trunk is now what 4.3 will be.

As I've been reminded a few times already today myself, that means we need to backport bugfixes made to trunk that we want to appear in 4.2. The svnbackport script in kdesdk was updated today to backport to the new 4.2 branch and makes the process of backporting your last commit trivial.

The last few weeks leading up to a release are always exciting and nerve wracking for me. There are numerous details that always need to be worked out, though the project is getting better and not leaving things to the last minute. The promo team has been working on release materials since sometime in December, even. Hopefully that reduces the stress levels and burn out rates. =)

In a couple week's time it'll be full throttle on 4.3 ..

Read More

hell freezes over: death of the system tray protocol?

Over on planet.gnome.org, Ted Gould blogs about how the current system tray protocol sucks. I've written about the systray recently, but I started writing about how much it sucks 5 years ago. I wrote about it in a number of places, and sent mails to the xdg list.

Of course, I was always busy with one more thing and nobody else really seemed to care. In fact, some told me I was being silly and the current system was just fine. I wonder if those people even remember. =)

In any case, it seems like hell is finally freezing over: we have a system tray widget in 4.2 that is built for multiple backends (and already has a couple) so that we can freely mix and match old with new as a realistic path forward, and people in other projects are talking about doing actual work in the same area too.

Hopefully Ted isn't going to make the same mistake I did, which is to realize the error of our ways then not actually do anything about it for a couple years because there are so many other pressing things to do. ;)

I also hope that in their thinking about these things that as they move to implementation that they keep us (the F/OSS desktop world) information and even share their plans as they go forward. I personally plan on sending something to freedesktop.org once we have something we can show works reasonably.

Yes indeed ... I think the Devil be shaking, and it ain't out of fear.

Read More

basic JavaScript engine: the go forward strategy after looking back

After 2008's Tokamak in Italy, I blogged about scripting and my cracktastic thoughts on it. I mumbled on about ninjas and myspacers and apparently the drugs are still in my system because I still think it's a solid approach to the problem.

Thankfully I was able to convince a couple others of that as well and the widgets API we put into libplasma, which really just wrap plain QWidgets-in-QGraphicsProxyWidgets thereby taking the boredom out of using them and giving a nice scripting-friendly view on them, was one result. The other was the JavaScript AppletScriptEngine in kdebase.

Rich Moore started the work on these and got a fair ways into it. Then he got busy with his day job. Then he got really busy with his day job. We talked about it on IRC a bit, and I said I'd try to help pick up the slack. Chani and I ended up doing the widget API and Rich got some more work done on the script engine. Then Rich got really, really busy and things stagnated. It happens. (Rich, if you're reading this, we can't wait to see back around. =)

Then Chani decided the other week to write a Plasmoid. Something simple. After months of work on the widgets-on-screensaver insanity project I totally understood her desire for something a little less frustrating, a little more immediate and lot more fun.

However, I begin to think that "Chani" means "trickster" in some devious ancient language because she started doing it in JavaScript. Not with the "ninja" engine in playground (sensible, it's still in playground after all) but with the "myspacer" one that had already trundled into kdebase. That was when we got reminded how incomplete it was.

So Chani, Marco and I jumped on the poor beast and over the span of a few days implemented access to DataEngines, Services, context menu actions, configuration settings, layouts, access images shipped with the Plasmoid in its package and more. The foundation we built on (Qt, QScript, the core KDE libs, libplasma and Rich's initial work in the engine) were all solid and so we raced ahead at great pace and now you can do actually useful things with it.

We wrote a few little test applets to poke at the engine with and as tagging approaches within the next 24 hours for RC1 it's actually moderately useful. =) Take this guy for example:

If we remove the debug output and whitespace, it's 27 lines of JavaScript that can control any music player that exports an MPRIS controller interface (thanks to the nowplaying DataEngine). It all starts with:

engine = dataEngine("nowplaying");
watchingPlayer =  engine.sources[0];
controller = service("nowplaying", watchingPlayer);

Yep, it just rips right into things, grabbing DataEngines and Services and flinging them around. In C++ we would've written a couple dozen lines of code (class declaration, constructors, etc, etc) and a CMakeLists.txt to get this far. So while the Plasma, KDE and Qt APIs are great, there's entry overhead we can avoid by using higher level langauges in the right places, no doubt about that.

Next it defines three functions: dataUpdate, stop and setProgress. I won't bore you with those, you can see them yourself over on websvn by looking at the whole file. It then makes a simple UI, all sparkly, performant and themed thanks to libplasma and Qt:

layout = new LinearLayout(plasmoid);
layout.setOrientation(QtVertical);

label = new Label();
layout.addItem(label);

stop = new PushButton();
stop.text = "Stop";
layout.addItem(stop);

progress = new Slider();
progress.orientation = QtHorizontal;
layout.addItem(progress);

It then glues stuff together:

stop.clicked.connect(plasmoid.stop);
progress.sliderMoved.connect(plasmoid.setProgress);

controller.associateWidget(stop, "stop");
controller.associateWidget(progress, "progress");

engine.connectSource(watchingPlayer, plasmoid, 500);

Those controller lines are somewhat magical. They connect the widget to aspects of the Service, so when for instance the music stops the Stop button automatically fades out and becomes disabled. Neat.

The last line connects the DataEngine up and the widget "goes live" at that point. When the music player starts playing, the Stop button becomes enabled, the name of the song, artist and time is printed in the label above and the progress slider starts marching along.

Clicking Stop actually stops the player as you'd expect:

plasmoid.stop = function()
{
    controller.startOperationCall(controller.operationDescription("stop"));
}

Moving the slider seeks within the song:

plasmoid.setProgress = function(progress)
{
    operation = controller.operationDescription("seek");
    operation.seconds = progress;
    controller.startOperationCall(operation);
}

All pretty simple stuff, and documentation for the entire API exposed in this simplified window into Plasma is on the way.

Installing the Plasmoid itself is a snap: plasmapkg -i script-nowplaying. In it's final form as a zip file (so `zip -r nowplaying.plasmoid *` in the root dir of the plasmoid), `plasmapkg -i nowplaying.plasmoid` suffices or you can install it via the Add Widgets dialog in the Plasma desktop shell. The Plasmoid above becomes a 1.5K file on disk that you can toss about quite easily, including between operating systems with completely different toolchains and hardware architectures.

We have planned out some tools to help you create Plasmoids extremely easily, so there will be no need to know the packaging details at all for instance. These things will only get better.

I'm really impressed with how quickly it came together over the last few days compared to how actually useful it already is. Writing a high quality language runtime is not an easy task. Writing frameworks like Qt, KDE's core libs, Solid, Phonon, Plasma, etc are also not easy tasks. But gluing the results of those two efforts together? Amazingly quick, if a little black magic-y in places.

Thanks go out to everyone whose worked on those hard bits, and especially Rich Moore, Marco and Chani for helping bring this part of the puzzle together.

Where Do We Go From Here?

If you care about non-C++ languages and Plasma, come join us. We've already got a few Ruboids and Pythonistas hanging about on plasma-devel@kde.org and on #plasma writing Plasmoids, but we need more of you. JavaScripters with an itch to scratch should come join us, too. We need to kick the living crap out of these ScriptEngines and torture them in all sorts of ways, just as we have the C++ libplasma over the last year, and create cool things with them in the process. This way we can go from our first-cut ScriptEngines in 4.2 here to kick ass ones in 4.3.

We're willing, in fact desiring, to improve, modify and grow the ScriptEngines in response to usage. It's the best (some might say only) way, really. =)

I'll be announcing the documentation for the Basic JavaScript ScriptEngine when it's ready to go so you can all jump on it. The docs will come pre-4.2.0, so that you should be able to upgrade to KDE 4.2 and start hacking JavaScript with documentation in hand all in the same day without compiling any C++ on your own. Huzzah.

Read More