hiding panels feature complete for 4.2

I committed the last of the changes for panel hiding for 4.2 this morning. Here's the current status of things:

• General hiding:
  
  
  
  • unhides triggered only where the panel is, not along whole screen edges, making non-full-width panels behave a bit nicer
  
  
  • unhides on drag enter, hides again on drag leave. I actually ended up implementing the first half of the XDnd protocol (X11 doesn't actually do drag and drop natively!) by hand using xlib calls to make this work. Every time I touch xlib I am reminded how much a I love Qt and KDE libs for making it possible to never touch xlib for anything sane. (Unfortunately, desktop shells involve all sorts of insanity. ;)
  
  
  
  
• Auto hiding: when the mouse leaves the panel, the panel hide; when it hits the screen edge it unhides. General features/improvements:
  
  
  
  • will not hide if a popup is shown, hides when the popup goes away if the mouse is not in the panel
  
  
  
  Compositing-only features:
  
  
  
  • Glow: when the mouse approaches, a small glow on the screen edge appears, brightening as you get closer, to let you know there is a panel there.
  
  
  • Animation: animates in/out of the screen. Works fine with the system tray now (well, mostly; it's not pixel-perfect, but as close as we can get it) as well as with multiple screen setups (e.g. it won't "hide" by moving to the other screen as kicker would)
  
  
  
  


• Windows-can-cover: windows are allowed to cover the panel and while the panel never disappears off-screen, it can be pulled back to the top by mousing over the screen edge it is on




• Does not flicker madly after unhidden if the mouse doesn't leave the screen edge


• No glow effect since the panel is actually always on screen

The last of open hiding-related bugs on bugs.kde.org were closed, save one that has to do with how to unhide a panel that is hidden on the screen edge between two panels (which is hard to do, of course, as there is nothing "stopping" the mouse cursor from moving right past the unhide trigger area).

The hide/unhide animation speed is not configurable; I'm really not sure it needs to be. We'll see. 4.2 will ship with a sensible setting (1/10th of a second to unhide, 1/5th of a second to hide).

Things left in terms of panels for post-4.2 development include:

• Positioning of multiple panels that overlap; right now there is no code there to automatically manage such situations; you need to configure the panel widths yourself. Kicker used to stack panels, but that leads to all sorts of sad situations. This is could be an interesting not-too-complex research project.


• Optional per-virtual-desktop panels, much as we now have the experiment per-virtual-desktop Activities.


• Activity aware panels, so when the desktop activity changes, the panel could too.


• Other panel types (Containments), like a dock style.


• Manual hiding, though I'm not sure there's actually sufficient demand for that to warrant it's inclusion?

So there is still a few interesting avenues to explore with the panels in the Plasma desktop shell, but they are getting fewer. With 4.2, Plasma has virtually all the features Kicker panels did and a few it didn't.

All I know is that, barring new bug reports coming in, I probably won't be touching the panel code for a couple months. =)

Read More

passing between years

The calendar in my Plasma panel says that soon we will have gone through all the days allocated for 2008 and will start in on 2009. While a rather arbitrary line in time, calendar year-ends are a convenient time to look both back and forward. KDE sits between two great years in its history and therefore there is much one can reflect upon as well as look forward to.

Some Highlights From 2008

2008 will undoubtedly be remembered most often as the year we moved from the era of KDE3 into that of KDE4. The 4.0 release was made in January with an accompanying release event at Google's HQ in California, USA. While 4.0 was a widely misunderstood release, it was also the release that set the pace for the rest of the year ... and what a pace it was.

The KDE team managed 9,000-12,000 commits each month as we tore into a KDE 4 codebase where the libraries were no longer shifting under our feet and for which there were binary packages for both early adopters to poke at and application developers to quickly set up development environments for their porting efforts with. The release brought users which brought testing which brought improvements both in terms of features added and bugs fixed.

Bugs

The bug fixing story is an interesting one, actually. KDE has always enjoyed an active community where people find and report bugs as they find them. While our code base grew dramatically throughout the KDE3 series, it also matured and the bug report rate went down. Still, the total number of open reports continued to climb and climb. Were we just not concentrating enough on bugs.kde.org? Were too many of our applications without maintainers? Were the tools we had to work with not good enough to route out the bugs? Were there simply not enough developers to be had? I don't think we'll ever know for sure, and it was likely a combination of factors, but the numbers just grew and grew. It felt like walking uphill closing bugs only to see the total numbers rise and rise ever upwards. There were a few weeks where we made progress .. but most weeks we were in the red.

With the KDE4 series just beginning we released onto the world a huge amount of very new and relatively untested code. Anybody could have predicted the bug report rate would go up compared to the ever mellowing and stabilizing KDE3 code base. Indeed, this is exactly what happened:

The rate of bug reporting has been phenomenal. Hats off to our testers around the world (though perhaps a few less duplicates would be nice ;) and their 370+ bugs per week this year. Since 4.2 beta 2 has hit, we've been inundated with over 500 reports per week, and that's not counting feature requests.

Here's the cool part though: the bug overall count has been dropping. Why? Well, we did shave a few hundred off by putting aRts and KDesktop out to pasture and marking their reports with UNMAINAINTED, but that's only about a week's worth of reports at our current rates. The real heroes have been the bug squad and a new-found fire for quality in the software where many project snipe reports as they come in.

A few years back it was easy to crack the top 10 bug closers for the week by dusting off just 10 reports. These days you often have to do twice or more that number, and often the top spots in a given week are held by people closing over a hundred bugs, sometimes even in excess of 200! The bug squad and their planned and coordinated weekend bug krushes were an excellent success and have really helped drive our attention towards the bug count. In the Plasma team, we set release time bug count goals and often close numerous reports per day with commits fixing legitimate issues.

New Stuff, And Lots of It!

2008 was also the year of new stuff in KDE. We've been working on refining today's incarnations of new comers like Dolphin and Plasma, implementing important sets of functionality in existing apps like compositing in KWin and groupware scalability via Akaonadi, pounding on the Pillar frameworks that address everything from hardware and networking to multimedia and threading and watched as some of the Big Apps like Amarok and Digikam successfully roll towards their first KDE4 releases.

The artwork in KDE4 along with the usability improvements made thus far (on a much longer road) has also been huge. KDE's upstream design is currently in state that one can not only push out that design in downstream packages, but look good doing so.

The number of new game and educational apps was also impressive, and we finally got to witness the wheels rolling on KDE integration with things like ConsoleKit, PolicyKit and PackageKit. The advances in localization in KDE that brought with it a new translation application, a whole slew of new i18n mechanisms such as improved plurals, phrase context, etc. and the font advances that come with Qt4 were similarly impressive and will help us open Free software to ever more people, just as will the new accessibility opportunities opened up to us with Qt4.

Of course, also new in 2008 were also the first important steps to new platforms, MacOS and Windows, while finding new found energy in some of the old ones that had fallen by the wayside, such as Solaris. What's most significant about this to me is that KDE apps on these platforms don't look like odd, foreign transplants: they look quite native and behave as one would expect there. For heterogeneous environments, this will likely be a significant advancement for KDE. There simply is no other suite of software out there that is this broad and comprehensive that spans the platforms as seamlessly as KDE4 can.

There has been so much new stuff in 2008 that communicating the breadth, scope and pace of change is perhaps one of the biggest challenges the marketing team faces right now.

Community Growth

Speaking of the marketing team, 2008 was also a landmark year for the non-technical aspects of the KDE community. The marketing team found its feet, grew more finesse and continued to impress us with its adaptability, commitment and quality. When things happened in the KDE world, the rest of the F/OSS world heard about it. The marketing team also unwittingly birthed our North American event through the success of the 4.0 release event; now we have Jamaica looming next month and that's a direct result of that success.

KDE also gained a Code of Conduct paired with a Community Working Group to help keep the community in balance and healthy. While Techbase grew with technical information in 2008, Userbase was created by the Community Working Group to help our users get more accurate and timely information.

Without these efforts, our community and ultimately the project would founder and fade. Instead, we had a terrific number of new svn accounts in 2008 (nearly one per day), we had a record number of attendees at our heavily technical annual Akademy conference (somewhere around 350), KDE could be seen well represented at pretty well every interesting F/OSS event (and then some) around the world and a healthy number of people joined KDE e.V in 2008.

The Business Side of Life

Which brings us to the business side of 2008. The standout business moment of the year perhaps happened right at the start of it when Nokia purchased Trolltech and renamed it Qt Software. Many people wondered just what this would mean for KDE, and I don't think we've seen the final answers just yet. It takes a while to integrate companies and align agendas, but the level of embracement of Qt within Nokia has been tremendous. We have seen Qt speed up in development and the release of things such as Qt Creator. KDE's relationship with Qt saw new levels of cooperation in such things as the development and adoption of Phonon, one of KDE4's Pillars, within Qt itself.

KDE e.V. itself continued to grow and become increasingly sophisticated. We ratified a Fiduciary License Agreement which should actually be available soon for people to sign so that KDE e.V. may play a stewardship role in protecting their rights and their code. KDE e.V. had its first full year with an employee, whom we then hired full time due to the benefits we saw with Claudia on at half-time hours, became an associate member of the Free Software Foundation Europe, took on a number of new patrons, funded numerous developer sprints and continued to release our quarterly reports to document it all. KDE e.V. also took brave steps in discussing and creating movement in the community space as well.

Meanwhile, the level of success in KDE related companies around the world has been visible to those watching as well. It was also a year that we heard about huge new deployments like the public school system in Brazil which will end up servicing some 50 million students across that country, a country which is part of a region where a few million retail units are sold with KDE on them every year.

Indeed, 2008 was a nice step in the right direction on the business side of life.

The End Is The Beginning

2008 may have been a great year, but looking forward I see a year that stands a good chance of completely overshadowing the exciting 12 months behind us.

We have both Camp KDE, our new North American event, in January and an Akadmemy in Gran Canaria that will be co-located with GUADEC in an unprecedented move of F/OSS desktop unity and coordination. Given the financial situation in the world right now, it looks down-right prescient on our part to have done this as merely a cost efficiency measure, but I feel the real benefits will be seen at and after the event in July as developers will come together as never before.

2009 will also be the year where we reposition the KDE brand from meaning "that desktop project" to be more inclusive and accurate as an umbrella brand for all the work going on in the world of KDE and all the people doing that work. We've been working on this plan for much of 2008, and those of you who follow the KDE promo mailing list will know exactly what I'm talking about. This kind of brand adjustment is not easy nor a small task, but will pay off in terms of greater unity throughout the project and an easier time for those who have to answer the "What is KDE?" question every day.

We're still a technology project, of course, and 2009 will see the release of both 4.2 and 4.3. KDE 4.2 is already shaping up to be a truly remarkable release, quite possibly the best KDE we've ever put out there. KDE 4.3 will undoubtedly be yet another leap up the slope towards user interface greatness, and that should be happening right around the time of Akademy this year. Such timing!

KDE e.V., flush with our new full time employee, will also march forward. There will be one significant change in 2009 with regards to the board, however: I will be stepping aside as President next year. I made my decision known to the board earlier this year and we've been working on a succession plan as well as looking at candidates to fill the vacated board position. It's been a terrific experience serving the KDE community in this capacity, and I will continue to be deeply involved with KDE e.V. as well as KDE in general. It's just time for me to focus my energies on other parts of KDE that need it right now and for new blood, thoughts and ideas to percolate through the KDE e.V. board.

One thing I am working on right now is a book publishing deal for KDE where we will be able to publish over a dozen titles in 2009 in digital and print format. Our distribution could be quite significant and I'm starting to collect people who can write for user and developer audiences so that we can put together a tentative title list in January. I'll blog more about this at the start of 2009, however.

In fact, we an expect details to emerge on all of these happenings throughout 2009 as they, one by one, come to fruition. You can also expect details on a lot more, too. There are things afoot that will rock the F/OSS world in 2009. Just as in 2008, 2009 will start with a bang as announcements get made as early as January that will leave people excited and giddy with the possibilities.

Yes, I know .. I'm such a tease. January isn't that far away, however.

Personally...

Personally I'm looking forward to presenting at the Student Summit for Sustainability in Switzerland, the second Plasma Tokamak meeting in Portugal in February, OpenBossa in Brazil, Akademy in Gran Canaria and who knows what other events.

I'm looking forward to continuing to work on KDE, and Plasma in particular, with the tremendous team of people that have grown around the idea of making Free software for end users. I'm looking forward to continuing the move past Microsoft and Apple so that they get to learn what it is to see taillights ahead of them. I'm looking forward to writing code and helping to continue to extend the reach and foundations for KDE.

However, in this time of reflection, both forward and backward, I am reminded that the kernel of truth within KDE is a human one. We are people coming together to make software for people everywhere. It's not really about the business or the market numbers or the bug closure rate. It's about us: good people doing good works for ourselves and others. That is what drew me into Free software and KDE in particular, and it's what keeps many of us kicking around year after year.

The ability to balance the business with the community, the ambition with the empathy, the determination with the acceptance and the hope with the realism is what, personally, strikes me as amazing and vital to our little community of people.

I wait with excitement in my soul to just how far we will be able to take KDE in 2009. All I know is: world, you ain't seen nothin' yet.

Be Free,
   with Love and Hugs,

      Aaron Seigo.

Read More

notifications

I've been taking a few days off, sort of, around the holidays here. The P-man is visiting his mom and I have a house guest, so it's a nice time to do so. Of course, I'm still checking my mail, closing bugs and making commits (just fixed a crasher in folderview, actually) ... but I'm only spending a few hours a day on KDE around the Christmas holiday time this year. That means my blog is not getting updated. =)

I've been brought out of blog hibernation a few days early because I keep getting asked about Mark Shuttleworth's post on notifications and figured I should get something out in a mildly timely fashion.

Before I do that, however, happy holidays to everyone out there. I hope you are finding some time with loved ones or even just some quiet contemplative time if this time of year is special for you. Happy new years as well. =)

That out of the way .. I do have to say that it's a little embarrassing that Mark's blog got picked up by places like Slashdot. I really hope it was a slow news day or something, but I suspect a bit of star worship at play. This makes us all look a little .. well .. trivial when something like "how we are going to show the user notifications from appications" gets touted as important enough news to make it to a Slashdot front page (and yes, they weren't the only ones). There's lots of much less trivial and much more intriguing stuff going on out there. Were I a Mac or Windows fan I'd be rolling my eyes right now at "those Freedom software guys" because evidently they are getting all excited about such trivial things. It's also pretty sad that the other much less trivial things going on get less coverage. This isn't Mark or Ubuntu's fault, of course, but something for us as a community to think about: when we start hanging on the words of anyone too much, it reflects something about ourselves. Usually it's not exactly flattering, either.

Now, Mark's UX (user experience) team has put out a concept for notifications which you can read about in detail on his blog. There are two main points to it: notifications should not have actions associated with them, only one notification at a time.

I think the one notification at a time thing has merit. There are too many applications spewing too many notifications. We need to do a better job of compressing these down. I think simply showing one at a time isn't going to help much, though, as you'll just have to watch the parade go by slower. It's an interesting start, perhaps. I think a more compelling solution is to watch the categories and severities of notifications and prioritize their being showed by that. Add per-applications compression (so all of Kopete's notifications would get compressed into one, even if Kopete insists on being a blabbering fool =) and it should be possible to show few announcements at a time in a fashion that is meaningful to the user. Finally, the user must have the ability to tell the system very easily "show me what other notifications are out there that you aren't telling me about" because it is quite simply impossible for us to know what the user is going to deem "important" with a 100% (or probably even a 98%) success rate.

The other item, that notifications should be non-interactive, is without merit. I'm a little worried that someone who came up with that is going to have a say in the *buntu desktop experience because it seems rather .. well .. silly.

Let's play a thought experiment: you move into a new house that has come pre-furnished. In it is a phone. However, this phone only rings. Moreover, you can't get it to stop ringing by picking up the receiver and putting it down again or hitting an "ignore" button. It will ring because it feels the need to let you know someone is calling, even if you know after the first ring you don't want to talk to that individual. (Damn telemarketers!)

It also doesn't care if the person on the other end only wants to let it ring twice or 10 times: it always rings 4 times. The oddness there is that even if the caller hangs up after two rings, you might hear the third ring and pick it up anyways .. only to find that there is nobody there. Odd, no? Of course, someone letting the phone ring 10 times usually communicates some urgency. But this phone doesn't care. Everyone gets four rings.

To take a call on this phone, however, you don't actually go to the phone itself. No, the phone only rings. It then routes the call to somewhere else. Where depends on who is phoning. So you need to check the number that's phoning and then go to the appropriate place in the house, find the little speaker and press the button on it. Hopefully you, the house occupant, can figure out which rings go with which speakers.

Thankfully, most of the speakers are in the same room as the phone. So it's only mostly inconvenient. Unfortunately, you have to figure out which speaker to use for which calls still. Thankfully, some of the speakers blink when a call is coming in. Unfortunately you have two phone lines and so sometimes you have two blinking speakers. You'll want to learn which speakers go with those rings pretty well.

This sounds absurd because it is. It's also what the proposal Mark describes espouses. I had this explained to me by one of the Canonical people on irc, so I know I'm not misunderstanding his blog entry either. They really do think it's more convenient to see only one notification at a time (even if two people try to chat to you within the same couple of seconds) and that you should then have to go find out where to get to that chat request via the system tray or task bar (or whatever else) rather than simply have a "Chat!" button or clickable link in the notification.

So while there's some good points in the proposal, there's also some highly dubious ones in my opinion. I don't think this will affect the notification spec in any way, however, as the spec can support their goals just fine as is and upstream KDE currently has no intention of implementing a system which we consider crippled by design.

As for the spec itself, I have been in touch with the Galago maintainer and I truly hope to see a unified spec by KDE 4.3 that we are all shipping with.

So for everyone who's been asking me about this over the last week, there you go. I'm going to go hibernate some more. =) Cheers!

Update: something I meant to write in the original post, but had forgotten by the time I'd gotten into it was that I realize that this is an experiment on the part of the Canonical UX team. Experiments are good and we need to be able to engage in them, even ones that fail. We need to examine, test and stress experiments, but we should not dismiss them out of hand or get upset at people trying them. Too few people are trying new and useful things in the Free desktop world as it is. It's a fine balance between accepting just any idea that floats by and discouraging innovation in general. In that sense, I'm happy to see the Canonical people trying to both contribute more to the F/OSS ecosystem and do so through attempts at innovation and user interface design.

Read More

4.2 beta 2 available now!

Help spread the word: 4.2 beta 2 is available for your installation and testing pleasure!

As announced on theDot, KDE 4.2 beta 2 is out! Check out the 4.2 beta 2 announcement for an idea of what's in it and how to get it.

I'm already seeing bug reports from beta2 rolling in, so that's great. Join the army of KDE testers to help us identify and root out remaining issues in 4.2 so that we can make the 4.2.0 release at the end of January even better!

Also, please take time to install the debug packages for your operating system if installing from binaries. This makes the backtraces actually useful to developers. I still don't understand why distributions don't install them by default for betas.

Read More

pastebin plasmoid

The pastebin Plasmoid, in KDE 4.2's kdeplasma-addons module, is really neat. As annma pointed out to me on irc today, you can drag images straight from ksnapshot onto the pastbin Plasmoid and it uploads it to an image site for you and then displays the resulting URL. You don't even need to save the image first.

The pastebin Plasmoid also supports text, of course, but that image trick scores higher on the cool factor. I hadn't even thought to try it with an image. =)

That one little Plasmoid makes collaborating so easy: drag, drop, share!

KDE rocks. =)

Read More

numbers

Ah, numbers.

69.4 cents Canadian (40.3 cents Euro): how much I paid for a liter of gas today. It was nearly twice that price three months ago. Makes one think about deflation and the scary effects that could have on an economy where most people carry too much debt.

100: the number of bug reports filed against plasma in the past week. More and more of them are duplicates, though, which is good. That means people are running out of new problems to find and report. Davide Bettio went on a "find crashes" hunt today though and turned up at least one new one; until Marco fixed it. I had the exact same patch ready to go, but had to step out for half an hour so I could test it. By the time I got back, Marco had gone ahead and committed his patch ... which when I svn up'd merged with my changes character-for-character. Which was pretty cool.

The number of cool things folderview can do keeps growing as well. Frederik H. closed a bug report this evening that noted that folderview kind of sucked when viewing a remote URL on a computer that wasn't always connected to the network: when disconnected, it might time out and show nothing, and when reconnected it wouldn't refresh to see if there were changes made. Thanks to the awesomeness that is Solid, it was a pretty small patch (less than 10 lines of code IIRC) to make the magic happen. One less bug report, one more cool feature.

And one step closer to the user interface I was only dreaming of with my KDE brothers and sisters a few years back: "The computer should just react to its environment!" we'd say, and now it's actually starting to happen. Imagine: a computer that uses all those available cycles to do smart things a human would expect of it.

Two: the number of outrageous videos containing Qt and KDE related singing. I give mad props to Adriaan for this performance live on stag at foss.in; the dude even had dancers, not to mention original material. He makes my karaoke schtick look weak in comparison. I'll have to kick it up a notch. Though, maybe, not in quite the same direction as those jolly Trolls.

Four million: the number of new desktops/laptops sold with KDE on them in Asia, Central and South American markets by just one company in 2007.

Four to one: the return rate MSI suffered of it's Linux offering compared to their Windows offering. Yet ASUS says they are seeing no difference in their return rates. So while some, including MSI, might blame Linux (and granted, MSI chose a different path than ASUS's Qt and KDE heavy offering), I'd blame MSI's poor to-market strategy. ASUS communicated clearly what the device was and wasn't and got it into brick-and-mortar stores where people would put their hands on them.

Two: the number of days before I get to see someone I love in the flesh for the first time probably 4 months. Which is way too long, really.

So, lots of numbers floating around. But really, there's only one numerical answer to everything. Everything else is an approximation. ;)

Read More

hiding icons in the system tray

In kde 4.2 we have the ability to hide icons in the system tray as kde 3.5 did. Something i'm curious to try, however, is a stock list of icons to hide so that people can find this feature a bit more easily by seeing it in action. Not to mention sane defaults are a good thing.

What I'd like is your feedback however: which icons do you always hide in the system tray? Here's my list:

• korgac


• krandrtray


• kgpg


• kwalletmaager


• klipper

I don't think this is particular sane as a Default For Everyone(tm), though. klipper and krandrtray should probably both be easily visible to the user.

Leave your list of hidden icons (doesn't need to be KDE specific, either!) in the comments below.

Read More

i hate winter storms, but i love kde

Winter storms suck. Cars run into each other (sometimes right next to you while you're waiting at stop lights), you can't go outside without a bajillion layers of clothing on (and even then..). Sure, snow is beautiful, but more in an abstract concept way. It's less fun when it's blowing -30C snow flakes in yours face.

P. and I did some grocery shopping, picked up some movies to watch (holy moly is The Dark Knight a terrific film!) and generally prepared to spend the next couple days in the house. The cats are going a bit stir crazy already, but we're pretty well stocked for the weekend.

I didn't get the multi-screen bug count as I planned on as a number of other things intervened. All good things for KDE, but things that needed paying attention to right freaking now. This means I have lots to keep me busy during the weekend storm. :)

So while I grumble about the weather outside, I can truly say that I love the KDE inside. See, I've been quietly putting up with a certain crasher bug in KMail since the new header bling went in: whenever multiple messages were selected, right clicking in the message view (e.g. on a url) would cause an instant crash. That's something I happen to do a lot (part of my "how to deal with hundreds of emails a day" regiment). So this evening I went spelunking in the KMail code to see where it was crashing.

KMail is not trivial stuff, and while I have a handful of (largely inconsequential) patches in there I do not pretend to have a deep understanding of that code. I tracked it deep into the guts of things and then ended up with a quandry, not knowing exactly what the correct answer was. This is typical of KDE, I find: there's a problem, so someone at least tries to do something about it. I love that work ethic.

However, lost as I had become, I emailed the developers with my findings, my question and my surrender. Three hours later I see a response on the mailing list from Thomas McGuire saying, "Typical KMail crash. The msg was deleted via unGet() behind our back and
became invalid. Fixed in r896262." Indeed, that fixed it.

That, even more so than the lovely dram of Lagavulin in my glass, warms my heart. We may live in a world that tries our hearts and tests our stamina, but there are islands of people here and there that share a commitment that can lift my spirits even in the midst of a winter blizzard.

Some islands are big enough to be continents. KDE is a large and great tribe on one of those continents, known as FOSSland. =)

Cheers to the KDE PIMsters, bah to the people who can't drive when the snow falls. ;)

Read More

plasma, excerpt from an email

Introducing someone to the behind-the-scenes life of Plasma is something I do fairly regularly these days. I'm starting to actually get good at it, and now that we essentially have the core branding direction for KDE4 settled in (allowing me to work on plasma.kde.org without doubts lingering in my head), this is the kind of stuff that needs to end up in the technical areas of the website over the next couple months.

Today I gave someone the "five cent" tour via an email of Plasma concepts, covering the most important high level concepts to get them oriented enough to start exploring. After writing it, I thought I'd share it with you on my blog because I'm not sure how much of all of this is really clear and apparent to others. Given that I've read such absurdities as "Plasma is just MacOS Dashboard done poorly" in the last couple weeks, I'm going to guess that it isn't overly apparent to everyone. ;-P

Without further rambling, here's an excerpt from that email:

I should probably save you a few minutes of head scratching and give you a quick list of terms that ret flect the technical design of Plasma:

In libplasma we have:

* Corona: the base canvas where all things "live"
* Applet: the base class for all Plasma widgets
* Containment: a means to collect widgets into sets; Containments are not nested.
* DataEngine: a simplified and abstract API to data sets; this makes it trivial to write widgets that can access all sorts of data ranging from windowing information to device information to online services such as twitter.
* Service: a simplified and abstract API for services, be they local or remote. it provides the "write" side to DataEngine's "read"
* ScriptEngines: the glue layer between Applet, DataEngine, etc and scripting languages as well as third party frameworks such as E17's Edje or Google Gadgets.
* Svg: simplified access to themed Svg based graphics

.. and much more, but those provide the basic plumbing

we then have a constellation of plugins:

* Plasmoids: Applet based widgets
* Containments: specializations of Containment for various use cases (object based desktop, traditional icon based desktop, panels, screen saver overlays, etc)
* Runners: search query providers
* Wallpapers: background painters
* DataEngines: data providers (may also provide a (set of) Service(s))
* Services: service providers
* ScriptEngines: glue layer implementations (HTML/CSS, JavaScript, Ruby, Python, Google Gadgets, Edje, MacOS Dashboard)

we bring all these pieces together in "shells", which are standalone applications which create a Corona, define a default setup of Containments and widgets and handle the high level user interaction (e.g. wallpaper configuration). these include:

* Desktop: what you see when you log into a KDE 4 desktop
* Screensaver: provides widgets-on-the-screensaver
* Plasmoidviewer: a widget-in-a-window shell; very simple, designed mostly for testing widgets
* MID: the start of a shell design with mobile internet devices in mind

this design allows us to separate the infrastructure (libplasma) from the components (the plugins) and allow us to remix them in many various ways.

the fact that applications so very different from a desktop shell, such as Amarok2, can use this same libplasma based system demonstrates the flexibility.

Read More

winter descends

Winter is finally here. After a mild November and a very reasonable December, there is a storm on its way this weekend. It is supposed to be -30C with the wind chill here tonight, and it will reach those temperatures without the wind chill factored in over the weekend. Snow, thick and blowing, is supposed to accompany this deep freeze.

So this afternoon, P. and I will be making a stop at the grocery store on the way home from school to pick up anything we might want over the weekend. Last night P. took part in the grade one thrugh five winter festival concert, singing and dancing through a rather enjoyable 45 minutes of entertainment. Tomorrow, there will be less singing and dancing as we shutter ourselves in the house. We do have all the fixings for a ginger bread house, however, and that will help keep us busy tomorrow.

Speaking of tomorrow, I'm not going to be doing a video cast. I've now tried three different sites for doing live broadcasts, all of which use proprietary software and all of which are themselves proprietary ... and all of which have led to immense disappointments in one way or another. The sad quality and featurelessness of Web 2.0 applications reminds me just how critical it is that we keep up the good work on rich client software, particularly the F/OSS sort and with an eye to online service integration.

Franz has been working on a freej based solution that I will be able to use to do future broadcasts. This solution is 100% free software and spits out media encoded using a Free codec. Huzzah for freedom, and a round "boo" to proprietary crap. While there are some shining points of brilliance in the world of proprietary software, all too often it's just a tragedy.

This does mean I'll get to concentrate more this weekend on working in KDE's own frozen land: 4.2. Through the amazing efforts of the Plasma team, we've whittled down the reports for Plasma to, as I write this, 198. That means we're already below the target I set out for us as a goal, but that doesn't mean we are done. Not by a long shot.

There are still a couple dozen "easy" targets in that list and we have another month to work on them. Rest assured, we will. Help make our life hard by testing, finding bugs (some of the things people are shaking out are truly impressive) and then making high quality, detailed reports on bugs.kde.org.

I'm really looking forward to the end of January when we release 4.2.0, because then we can start to focus on 4.3, a development cycles that will bring us into the springtime and after that the summer with our big event in the Gran Canarias.

Read More

guesting on SourceCast today

I'll be appearing on the next episode of th SourceCast podcast. We're recording at 03:00 UTC (which is a much more reasonable 20:00 local time for me). I'm not sure when it will be released on their website, but when I find that out I'll pass that information on to all of you.

If nothing else, they have cool intro music. It speaks to my inner gypsy-slash-TMBG-fan. ;)

Beyond that, we'll see how it goes tonight as we talk all things 4.2 and FOSS-y.

Read More

Free dektop notifications

I was tempted to entitle this entry "More more downstream fun" but figured I'd call it something more illuminating to the topic at hand, namely: application notifications.

KDE sports a very robust and comprehensive notifications system that features things such as logging to files, playing sounds, popping up notifications and more. It also allows these to be fully configured, either system wide or per-user. We've had this in place for years and it's proven to work pretty well for us.

Unfortunately there has been little interoperability progress so every application framework had it's only little system for doing things like popups.

The Galago project offered up a specification for addressing one aspect of notifications: visual notifications. In KDE we've used passive popup windows for applications to let you know things like "Hey, someone's talking to you on Jabber!". The Galago spec documents a D-Bus interface, so ostensibly it's cross-desktop. Unfortunately, although they jumped on the D-Bus name of org.freedesktop.Notifications, not many other application frameworks used it. Certainly not KDE. Why? Well, to put it simply, the spec has warts. We've communicated what aspectswe'd like to see improved but to no response or headway. This makes it clear that grabbing "org.freedesktop.Notifications" was way premature in this case.

In KDE 4.2, Plasma's system tray provides a service called org.kde.VisualNotifications which is a subset of the full Galago spec with some rather minor modifications. KNotify uses this if it finds it to be available, otherwise it falls back to using passive popups. The system tray also provides support for the _NET_SYSTEM_TRAY_MESSAGE_DATA notifications that happen over X11 Atoms.

Today I found out via a third party (huzzah for having people who work on KDE things at conferences!) that user experience people at Canonical were working on notifications and tweaking the Galago spec. Via Riddle I was able to have a conversation with one of these people and hopefully we'll see a notifications spec that we can all live with and implement using the same D-Bus interface and address.

I was a disappointed that I had to find out from someone who happened to be at the event that this was going on, however. This is the kind of work that belongs on the xdg list from the very start with all the stakeholders. Far too often well meaning downstreams head off and start implementing things so excited and enthused about what they are doing that they don't lift up their head and look around at who else is being effected, or should be effected, by their efforts. I know that working with others is harder than working by yourself and that making a coherent experience is not the easiest path. It is, however, the best path.

So .. long and short of it: I'm hopeful that soon all FOSS desktop apps (KDE, GNOME, Mozilla, etc) will be able to show their visual notifications in a way that integrates well with whatever the host desktop shell is. The rough goal we talked about on irc is by the releases in the second half of 2009 to be sharing something, with the possibility of even making it happen in the spring releases.

Read More

more downstream fun

Today I talked a bit with Rex from Fedora's KDE team about their experiences with KDE's releases this last year and issues around backporting features. It really wasn't much different from what other downstream groups seem to be going through, and it is becoming ever clearer to me that we need some processes and tools in place to make the gathering of information and then channeling that into communication in place.

Nearly all our downstreams, while appreciating the improvements we've put in place over the last couple years, ask us to communicate even more. What do they want us to communicate, exactly, and how? That, it seems, is much harder for them to articulate clearly.

When it comes to them communicating in the opposite direction, there seems to be a lot of desire but little follow through on that in the good times and a scampering about without a lot of direction when challenges arise.

I'd like to know what the release goals, the release challenges and the release deviations (from upstream) are in the pipes. Preferably without having to visit each irc channel or set up conference calls with distribution representatives twice a year.

On the one hand I feel bad for our downstreams because we're obviously not their only upstream and nearly all of them could use more human resources as it is. On the other hand, it's pretty evident that we waste a lot of resources by not communicating more effectively.

It seems we could do well with an efficient mechanism of communication and tracking. Bugzilla's really not the tool for it, and it's not a matter of creating Gantt charts either. (Thankfully.) I think the patch server I wrote about a few years back is still a good idea, but that's really just for patches and doesn't address issues of coordination and communicating logistics.

Read More

audience management

Most blogs, articles and books on doing presentations for live audiences that I see tend to focus on the slides, the talk structure, effective speaking techniques, gesturing, etc. The assumption is that you have a captive audience and it's just up to you to do a good presentation while they patiently endure your performance.

Free software conferences can be a little different, however, with the audience being a bit more .. participatory. When being interviewed, it's absolutely different since the audience is not passive.

While I haven't perfected the art, I have picked up a few points that others might find useful:

• At the start of your presentation, outline the ground rules. If questions should be held to the end, say so. If you want interaction during the talk, also say so. Either way, it communicates that there is an expected structure to the presentation. It is not random. It is not chaotic. In fact ...


• ... this is your presentation, and you are responsible for managing the progress of things. The audience participates at your allowance, they do not manage the flow of the presentation. Which means ..


• Sometimes you have to move on. "That's a good one, but I'll answer that question later.." or "That's a bit out of scope, perhaps you and I can discuss that together later.." or "I'm afraid I'm going to have to move on if I'm going to get through all the material, but that's an interesting point..." or "Good question; I don't know the answer off the top of my head, but let me get back to you on it.." There are lots of ways of shutting down audience over-participation, and don't be afraid to do so. If you let them take the reigns away from you, the presentation will jump the rails and nobody will get anything useful out of it.


• During the Q/A section (or an interview), you are not required to answer every query. Some people will purposefully ask questions that they know are out of bounds just to see if they can throw you or if you'll say something silly. That sounds stupid, but it happens. Sometimes the question is a good one, but is off topic, would take too much time or is unintentionally contentious. Skip all of that; those who have listened to interviews I've done have probably heard me say "I don't think that's a useful question.. and here's why.."


• Sometimes a really enthusiastic person will try and engage you in one-on-one dialog to the exclusion of anyone else getting to say anything, the typical "loud guy". They usually don't mean any harm, they are just really engaged and enthused. Don't let that derail the presentation, however; offer to talk to them one-on-one later and move on. If they keep just speaking out, make eye contact with them directly, smile and say something such as, "Would it be alright if we discussed that afterwards? There are others who haven't had a chance yet, and I do want to get to as many of them as possible. Thank you for your input, though. Good stuff!"


• If you end up with a dead audience, try and figure out why. Is the topic wrong? Is the detail level wrong? Did they just all eat and are falling asleep due to heavy stomachs? If you think you know why, stop for a moment, pause, gather your thoughts (it may feel like an eternity, but 5 seconds of pause time is absolutely OK) and then start in with an adjusted approach. If you don't know why ... ask them. "Am I being too detailed? Covering things that are too basic? I want to make sure this is interesting for you all..."


• Of course, solving problems isn't as fun as avoiding them. To avoid problems such as the above situations, get the audience on your side from the start by warming them up. Ask them how they are doing, if anyone in the audience is familiar with the audience ("How many of you use..") how they are enjoying the event or what they thought about something else (in specific) at the conference. If nobody moves or says anything, say something like, "Ok, we can do better than that, right?" and then repeat your question. Smile and move your arms in natural gestures while you do this. The whole point of the exercise is to get them to connect with you as a person, not a stuffed-shirt mannequin up on stage.


• Remember that it's OK to pause. You don't have to fill every moment. But keep eye contact with the audience unless you are re-grouping your thoughts and it will distract you. If you do need to gather your thoughts and break eye contact, be sure to hit the audience with your presence once you being again: smile, eye contact, gesture.


• In other words, avoiding uncomfortable situations is all about engaging the audience. Make eye contact, or, if you feel uncomfortable doing that, make hair-line contact: look at their forehead. The audience member will get the feeling you're generally making eye contact, but it's a lot less psychologically intense for both the audience and you as the presenter. Remember to engage the whole audience as well: use the words "we" and "us", ask them simple rhetorical or leading questions so they feel they are part of a conversation and look at people in different parts of the audience.


• Doing this requires practice. Try your licks out in front of the mirror, imaging yourself doing it in your mind before going to sleep, subject a friend to the horror of being an audience-of-one. ;) Whatever it takes, go through the motions at least in your mind's eyes if not in actual practice. Concentrate on natural, relaxed looking gestures, eye contact, avoiding those 'uh's and 'um's and smiling (again, in a style that looks natural). You can be an absolute wreck inside when you get up to give your presentation, but if you project calmness through your body language for the first 60 seconds (confidence is a bonus, but calmness is usually enough), you can win over the people in the audience, and that will make your presentation soooo much smoother.

These points, in my experience, tend to avoid most unfortunate situations that can and do arise when giving presentations. If you have any other tips 'n tricks to share, please put them in the comments here so others, including myself, can enjoy and learn from them too.

Read More

tasks widget and multi screen

I've been picking something in Plasma to concentrate on each week since the freeze. This last week it was the new tasks widget and libtaskmanager. chrigi, who did much of the work for grouping and sorting in libtaskmanager, and Marco both pitched in and together we re-worked the tasks widget o that the code is a lot clearer internally in the tasks widget itself. Such pre-release bit rot is pretty common when one component, in this case libtaskmanager, gets a heavy reworking; often components that depend on it are kept in a basically building and functioning state during the worst of the chaos. Sometimes it works out really smoothly, but not always. In the case of porting the tasks widget from 4.1 to chrigi's work in libtaskmanager, it needed some love.

This was clear when I went to fix some bugs reported from beta 1 only to find it very hard to do so due to the fragility of the code. It was essentially working, but needed some clean up and general code quality lovin'. As usual, the Plasma team stepped up and things, while probably not perfect (things never are ;), is a lot nicer. Performance is up, crashes are fewer .. and now we can go about rooting out remaining bugs and problems with a lot less headache.

It was impressive to see in some cases how entire sets of methods from the widget could be removed with chrigi's new work in libtaskmanager. He removed, for instance, all management of startup tasks as being somehow different from regular tasks in the widget: all of that is now handled in the library, making the widget itself simpler. Loverly.

Work remains to be done, but it's getting there nicely. This coming week I'll be shifting my focus to multi-screen issues. In theory, with Kephal (the fancy dancy screen management framework in 4.2) we should be able to nail the remaining beasties 4.1 had in these situations. Dual head will still likely suck to some degree (Plasma's fault, not Kephal), but I want to work on getting xinerama style setups and hot plug monitors working flawlessly.

The multiscreen bug fixing work probably won't land in time for beta2, unfortunately, but we now have enough people running trunk with multiple screens that that shouldn't matter too much.

Thanks for all the bugs reported on multiscreen issues, it will be our roadmap for what to concentrate on this week. =)

Read More

Video cast site

This week I will be using Mogulus for the video cast. Hopefully next week, thanks to Franz Keferböck's efforts, I'll be on a freej + icecast + other magical bits pure-FOSS platform. Worst case would be week after that. Until then, join me on my Mogulus channel at 17:00UTC on Saturdays!

Read More

apathy and how engagement fixes it

I live in a wonderful country, Canada. We have democracy and wide open spaces. We have amazing wildlife and vibrant artists. We have large cities and quaint little towns, too. We have our poor and homeless, but even they do better than many in other countries. We have socialized health care and lots of jobs even in this climate. Perhaps it is too good, though, as too many of my fellow Canadians are apathetic.

We've had a recent storm-in-a-teacup in our Parliament this week (I won't bore you with the details) and all it really showed was how few Canadians understand our political system. Now, I didn't go to high school in Canada which is when you learn about this stuff and even I understood how our rather antiquated first-past-the-post parliamentary system worked. So many Canadians believe, however, that our system is more like the USA and that we actually elect our Prime Minister directly.

For many, however, this week was a bit of a wake up call, and when I've talked to some of my friends here in town about it, they became mentally engaged and suddenly started asking questions and formulating observations. Huh.

It reminded me about how the other week I and all my neighbors started getting automated parking tickets due to a snafu with the computerized GPS-and-a-database ticketing system we have here in Calgary. Essentially our block of parking "fell off" their map and so despite our parking permits started receiving tickets .. every day.

I phoned in about it and the woman I got on the phone told me I had to fax the ticket in along with my parking permit. I suggested the ticket should be enough as my permit is from them for my car (indexed by my license plate) and the ticket has my license plate on it. She insisted I had to fax it all in. I was ok with this at first until the tickets started coming in every day. This time when I phoned (and got the same person; I truly hope they have more than one person handling all parking ticket inquiries for the city!) I explained that I wasn't cool with the "fax it in" concept because I really didn't have time in my day to put together a fax (including fetching my permit from my car) every day and then tracking their follow up on it.

She insisted: I would have to fax it in.

I figured I wouldn't argue and instead asked to speak to her manager. She asked, shocked, "Why?" Evidently it didn't occur to her that social compliance (something Canadians are very susceptible to in general, in my experience) would fail her. I explained, calmly and with a smile, "Well, you aren't offering me a solution that is reasonable or acceptable. I'd like to speak with someone who might be able to do that. I assume that person would be your manager."

And then something wonderful happened.

She asked for more information from my ticket again and called over her manager. But she didn't hand me over to him (it was a man, I could hear him). So I made a little joke about how efficient their system was to be giving us all tickets on this block so regularly. We laughed and I observed that you could see the sign marking the zone as permit only and that maybe she could cross reference my license plate to double check. It turns out she could, and she informed me of this with a smile.

I now had two people helping me and they tracked it down within a few minutes to a problem with the GPS database. She said that they could track my tickets by my license plate number and deal with them all that way, and asked for a number I could be reached at.

Problem solved, and she sounded .. happy. Much happier than my last call or the start of this one. I could hear the engagement in her voice: she went from a "can't solve it, sorry" attitude that obviously was not very satisfying to her either to a "ok, let's figure this thing out!" attitude that got her laughing, found us success (and a bug in their system) and a useful conclusion for everyone on my block.

I see apathy all the time around me, and I believe it to be a curable disease. People "simply" need to touch life again, lay their hands upon a challenge, think in terms of solution ... and believe they actually can make succeed in that.

Engagement is inspiring, and not just for the one who finds themselves engaged. Conversely, willful ignorance, apathy and demanding consumerism are depressing and disempowering. At least .. in my limited experience on this planet that's what I've observed.

I know I've personally felt worst when I have nothing challenging me or when the challenges do not have success as a possibility. I feel horrible and frustrated when engaging with the disengaged. I know we can't be engaged 100% of the time ... but most days I'd settle for maybe 25%. ;)

Have you also noticed a link between engagement and satisfaction?

Read More

KDE Videocast Episode 4, December 6!

Episode 4 of my KDE videocast will be broadcast live at 17:00 UTC on Saturday, December 6th over at ... well ... still working on that little detail. ;) It won't be at UStream, and I have two options on the table, one of which is FOSS! If the FOSS option doesn't come through this week, it hopefully will by next week. I'll post details on my blog here when I know exactly where it will be.

This week's show will look like this:

• Hello, viewers!


• Week in review: Camp KDE 2009 approaches, KDE 4.2 beta 1 reviews and a development stats update.


• The Headline: Plasma in 4.3 .. The "What now?" release: with 4.2 shining with lots of newness, what am I thinking for 4.3 and Plasma?


• Feature of the Week: KDE Games fly-by: we'll look at a number of the games in 4.2 and how they are shaping up to be better than ever, including one or two that won't be in 4.2!


• Town Hall: Bring your questions to #aseigo on irc.freenode.net, or leave one in the comment section below if you can't show up! I'll have my sack of answers at the ready at showtime.


• Developer Corner: Using Phonon to add rich media support easily to your application. We didn't get to this last week, so it's a do-over for this one!

A FOSS friendly codec version with all the media and text files used in the show will be offered via bittorrent after the show so you can download it for offline viewing, in addition to the usual online clip at UStream. The torrent will also have the files provided individually this time versus the (bad idea) of a single archive. .. you know, assuming I actually get a recording of the thing. ;)

See you there on Saturday!

Read More

ustream failure

Bad news to report: for whatever reason, the UStream recording only included the last 10 minutes or so of the show. It shows the correct offset (56 minutes) where it starts, but the first 56 minutes? Not to be found.

Very, very disappointing. Only the 160-some-odd people who ended up tuning in live got to see it, which is a small % of the usual audience who tune in for the recorded shows afterwards.

I'm going to be looking into alternatives to UStream more aggressively this week due to this latest screw up. I have kdenlive freshly installed from the SVN and will be seeing if that might be the doorway to a reasonable alternative.

I'll keep you posted.

Read More

that's one big avacado.

Tonight I made up some guacamole. I love the stuff. MMmmmmMMmm avocado goodness. In went one yellow and one red tomato, freshly squeezed lemon juice, finely diced garlic, diced white onion, a couple of finely diced red chilies, a little cumin, basil, sea salt and fresh ground pepper to taste. (Yes, no cilantro; I got out of the habit of using cilantro when P's mom, who hates the stuff, and I lived together.) In the large metal bowl I used for these things, I mashed it all up with a fork. I use a fork instead of the blender or other puree-er of food as I like my guacamole to have some texture. So nothing very out of the ordinary ... except the avocado.

I usually use 2-4 avacados, depending on whether I'm making a little bit of gauc for myself or enough for a bunch of guests. But tonight I only used one avacado. Despite using just one avacado, the mixing bowl is full and the proportion of avocado to other ingredient is perfect. This was managed because I purchased an extra large avocado. That's what the sign said, and they weren't joking: these things are massive. When P and I saw the bin of them in the grocery we just had to get one. There was probably somewhere between 4-6 avocados worth of fruit in this one extra large avocado.

The flavour is great, too, as I "had" to try some while making it to ensure a proper mix. =) It tastes just like any other avocado, it was wonderously, perhaps even a bit absurdly, large. And that humoured me for some reason. Perhaps I'm easily amused, after all. ;)

The guac is currently sitting in the fridge letting the flavours permeate the avacado mash fully. In a couple of hours I'll pull it out and wage battle against this extra large avocado goodness with a bag of tortilla chips. =)

Oh, and I finally downloaded the video from yesterday's KDE video cast and I'll be putting up a torrent for it tomorrow. Sorry for the delay, it was just a busier weekend than I anticipated. I'll post a link in my blog when the torrent goes live. Unlike the avocado, however, it will only be regular size.

Read More

Break even weeks on bugs.kde.org!

KDE developers around the world: we're currently just 14 closed bug reports away from a break even week! As of right now 475 bugs have been opened in the last 7 days, and people have resolved 461 reports.

I'd love to see KDE 4.2 get released with bugs.kde.org hosting less than 17,000 open reports and the only way to get there is to turn those status columns green!

Last week we delivered a crushing blow with twice as many closed as opened. If one removes the mass resolution of the 300+ aRts bugs with UNMAINTAINED, we were still 200 or so reports in the positive side of the ledger when Saturday rolled around.

Obviously, we won't have quite such a dramatic showing this week, but let's at least not lose ground after we've done so well recently.

Here's towards a better, slightly more perfect KDE 4.2.0! =)

Read More

KDE Videocast Episode 3, November 29!

Episode 3 of my KDE videocast will be broadcast live at 17:00 UTC on Saturday, November 29nd over at UStream.

This week's show will look like this:

• Hello, viewers!


• Week in review: KDE 4.2 Beta 1, Gran Canaria Desktop Summit and a developer activity recap.


• The Headline: The realities of meeting modern user needs, or "Why do Amarok and Akonadi use MySQL?"


• Feature of the Week: It's a two-fer! Migrating to Akonadi using kres-migrator and finding places with Marble's new search capabilities.


• Town Hall: Bring your questions to #aseigo on irc.freenode.net, or leave one in the comment section below if you can't show up! I'll have my sack of answers at the ready at showtime.


• Developer Corner: Using Phonon to add rich media support easily to your application.

A non-flv version with all the media and text files used in the show will be offered via bittorrent after the show so you can download it for offline viewing, in addition to the usual online clip at UStream. The torrent will also have the files provided individually this time versus the (bad idea) of a single archive.

See you there tomorrow!

Read More

abi checkers

Do you know of a tool that runs on Linux, preferably is FOSS, and can compare the ABI of two C++ libraries? If so, leave a link for me in the comments! =)

Read More

on my other perspective

I didn't mention it in my last blog entry on supppy chains because .. well .. it's not anything I can really say much about at this time, but: I'm currently spending some time consulting to a commercial project where one of the integral components is based on a Linux distribution. (Holy crap, how is that for vague?)

So for a good part of my days over the last while, I've had the experience of being downstream from KDE as well as the distributions who are KDE's downstreams. Some days it feels like I'm in a mobius loop as I shift positions in the production sequence. =)

It's been nice to be able to hold that perspective for extended periods of time, though. Being downstream (once removed!) from KDE (and the rest of the stack) is a rather different experience and mindset from being upstream to a distro. That's probably stating the obvious, but it's certainly another part of what has gotten me thinking about these issues more deeply.

Holding both experiences concurrently has given me the context to do things like explore negotiating with myself, role playing both sides of the conversation. (I don't actually self-negotiate when it comes to the real-world work issues; this is more a "mental exercises for hot showers" type material.)

More practically, I have to apply my goals and needs as a downstream without prejudice because I have a team that relies on and demands that; in a different point of the week (or sometimes the same day, even) I have to apply my goals and needs as an upstream without prejudice because, well, I have a team that relies on and demands that.

It is said that you can not slave for two masters, and at first I thought I'd run into issues with this until I realized that my master for whom I slave is one and the same: Free software. I just get to play the role of two different servants whose work must dovetail.

Given that these "supply chain" issues are kicking my ass in both of my servant roles, it's become something of an un-ignorable burning itch. Like athletes foot, or jock itch. Yeah, not pleasant.

I do also want to give a positive example (that I personally had nothing to do with) to show that this up/down coordination can work out well. The challenge was that a KDE4 user interface to network manager was needed.

Preferably it would be an improvement over the KDE3 one and it should work with the latest, greatest network manager stuff. Now, network manager is "upstream" to KDE and the distributions who really, really want this are downstream from us. Along comes Novell, one of our downstreams, and they say, "We really need both a better KDE network manager GUI for OpenSuse and it needs to use KDE4 libraries." They (Will Stephenson being huge in this role) start working on it. That work goes into the upstream repository while it is worked on, thus building a partnership through shared infrastructure.

Unfortunately KDE 4.2 goes into feature freeze before the network manager interface is ready. So people talk about it and determine that it could be in shape by the time 4.2.0 comes out, it just can't be part of the 4.2.0 release proper. OpenSuse could then ship this thing with their KDE4 packages even though it's not actually released via upstream yet. Sebastian Kugler, an "upstream" Plasma developer, starts pitching in to help make it happen. Everyone is informed and comfortable with the situation.

It seems to be working out well, but what happened differently here?

People along different parts of the production/supply chain got together and coordinated. Needs were communicated upwards in advance of crunch-time, and a coordinated effort emerged. Upstream was given a heads up about the inclusion of a non-released component that is just That Important(tm), and upstream actually got involved and puts resources on it to help ensure success. Upstream's happy because they get help from a much needed component from downstream, downstream's happy because they fill a need.

It's not a perfect world (perfect would have been inclusion with 4.2.0, or heck, even 4.0 if we really want to go for Perfect(tm)), but it's close enough (they are still using the KDE3 network manager in the meantime) and everyone is informed and comfortable with the plans. Needles to say, the user wins across the board and nobody is losing.

This all seems common sense, doesn't it?

Yet it is a much rarer occurrence in the FOSS desktop world than it ought to be. We are often chasing our upstreams, who are often running off on their own tangent, while we're doing the same thing to our downstreams. Every so often someone screws the upstream over because they don't feel they have a better choice, and the upstream gets miffed. All perfectly logical, but not very brilliant.

So why did common sense prevail in this case? In part because Will, Sebas and the Plasma team all know each other and get along. We talk often, have shared values and open lines of communication. Obviously this is not an easy dynamic to replicate.

So we know that with agreeable circumstances it can work out. We know that release schedules don't need to get in the way even if they don't line up perfectly. We know that resource allocation can be modified in response to voiced need. We know that different points in the chain can work together as if we were actually coordinated in some logical fashion. We do not have to guess at the plasusibility of it, then, we just need to figure out how to replicate the phenomenon.

What we are (or at least I am) missing are sure-fire ways to replicate these results when:

• We don't all know each other, or know each other very well


• We aren't in constant, regular communication with each other


• We rely on each other for different pieces of the puzzle


• We have independent bodies setting each group's agenda/roadmap


• The topic isn't always as limited and focussed as "an interface for the user to activate a network connection".

And it all needs to fit into 40-60 hours a week. Cue the Mission Impossible theme song? =) It may sound like it when it's put that way, but I have faith that we can construct an 80% solution that will blow away our current 20%-because-we-get-lucky track record.

Read More

free software supply chains

Over the past few months I've been quietly tracking our upstream and downstream interactions. The motivation for this has been my experience with the KDE 4 series, in which we have both been on more people's radar (when was the last time NVidia mentioned KDE 3 in a driver release?) and seen more trainwrecks both up- and down-stream from us.

In particular, the "distribution backporting" issue has really gotten out of hand. It's no longer just individual unbaked features that are being backported and shipped with stable KDE releases, but now entire applications are being pulled from pre-beta SVN and shipped with stable KDE releases. I know of two different applications this has now happened to.

Just as disturbing, some downtreams feel that they have the right to speak for us as an upstream to their communities and have, by doing so, misled people and abused KDE's relationship with users in doing so.

Of course, I'm still reeling from the issues Plasma has run into all across the X.org and Qt map. Features those projects have advertised, in some cases for years, simply were not mature or tested until we showed up and found out the hard way by running headlong into pointy skewers of buggy or simply featureless code bases which got that way due to not having real world applications at the ready to tease them into shape.

The losers in this are all around: users get sub-par product, KDE's relationships are damaged both with users and downstreams, upstreams look incompetent when really they just got caught out unawares and downstreams provide a muddled experience in their delivery phases.

This is not a healthy situation. I hope that's stating the obvious and that we're all in agreement thus far.

Note that I haven't really said anything about who's to blame for this. Take the case of lacking real world applications to test our frameworks with: who is at fault? Should KDE have been there earlier pushing on these areas back when these features were first being trialed? Should those writing these frameworks have ensured there were real world type applications doing meaningful things with their new fangled hotness before claiming stability and maturity? Not easy questions, are they? Personally, I'm not one for fingerpointing unless you really get it obviously wrong after having had a workable solution pointed out to you. We aren't at that point, however, with nearly any of the above.

While tracking these issues and trying to make heads and tails of them, often with great frustration draped across my brow, I have also been looking for analogs elsewhere. Most problems have already been at least identified, and most problems that have been identified have a history of attempted solutions. Just because I haven't had to deal with a particular problem first hand doesn't mean someone else hasn't, and so I've been searching for solutions (good or bad) elsewhere.

In talking with some of our downstreams, I've found it increasingly useful to talk about things in terms of supply chains and the kinds of relationships that end up forming around them. Unlike "traditional" software development where the supply chain is tightly managed and usually completely or nearly completely internal, the open source model seems to me to be a lot more like the free market dynamics seen in commodity markets and how supply trickles on through the machinery to eventually create products the consumer purchases. At least, that's been my impression. Feel free to correct me in the comments section of this blog entry. ;)

Mapping our current situation on to that of supply chain dyanmics does give us a well studied and highly optimized set of solutions that other people have already torn their hair, hearts and souls out over. So I'll be slowly edumecating myself about SCM (no, not that SCM, this SCM), something I'm only mildly versed in at best, and thinking about how to apply it sensibly, if at all possible, to improve our current state of affairs. It could be a dead end, but it could also be a source of inspiration. There's only one way to find out.

I'm devoting brain time to this because it is going to be increasingly critical to get our act together if we want to take on the next level of competition we face in the market without gutting our values and our resources. We have to communicate and coordinate much, much better between the different points in our software supply chain and get our roles correctly aligned with each other. Right now it's very ad-hoc and the network of people has grown beyond that which is sustainable based on a who-knows-who game masquerading as personal relationships.

I hope to meet with several of our partners at the Gran Canaria Desktop Summit in mid-2009 to discuss these things directly, and to have brought myself up to speed enough on the issues to be able to formulate and deploye systematic support solutions. If you have a great SCM book you think I should be reading in the next couple months, please comment below. I'm also wondering how I might gain access to the Supply Chain Council's full SCOR reference manual.

Read More

KDE Video Cast, Episode 2: Torrent it!

I got up early this morning so I could luxuriate in a hot shower, get dressed and go over my notes before the video cast this morning. It was an hour earlier and the second episode, so live attendance was down a fair amount: it peaked at "only" 194, which was 27 fewer than last week. I expected a spike on the first week (curiosity) and I knew shifting the time by an hour would suck as well. Oh well =)

I did, however, manage to figure out how to put text messages on the stream as well as videos hosted on Youtube. Unfortunately, these only show during the live broadcast and are not part of the resulting recorded version. I put a link to the show notes on the screen during the live broadcast thinking that would help people downloading it later, but ... fail. Additionally, UStream dropped out twice. My internet connection was fine (I was still in the chats), the server side just thunked out twice in a few minute span.

On the plus side the audio was better, I used a solid color backdrop, and the downloaded version is in mpeg format this week instead of flv's that won't work for anyone. Also included in the torrent are the show notes and the media I reference in the show, including a short Kopete screencast and a couple of JavaScript Plasmoids.

I am learning exactly what I want from a DIY broadcast software and am becoming increasingly tempted to see what Solid+Phonon in KDE 4.3 are capable of doing for me. For now, I just learn the quirks of what's available and soldier on improving each episode incrementally.

You can grab the torrent here and enjoy it at your leisure. Cheers! =)

Read More

Video Cast Episode 2, Nov 22nd!

This week's show will be one hour earlier than the usual schedule calls for: we'll be going live at 16:00 UTC on Saturday, November 22nd over at UStream.

This week's show will look like this:

• Hello, viewers!


• Week in review: KOffice beta, Amarok release candidate, bugs.kde.org improves and developer activity recap.


• The Headline: Entrepreneurial opportunities and the Free Software desktop: where is all the diversity?


• Feature of the Week: New MSN bling and graceful interfaces in Kopete


• Town Hall: Bring your questions to #aseigo on irc.freenode.net! I'll have my sack of answers at the ready.


• Developer Corner: Writing a Plasmoid in JavaScript.

An ogv will be available via bittorrent after the show so you can download it for offline viewing, in addition to the usual online clip at UStream.

As for why the bump up by an hour this week: There is a winter fair at the P-man's school on Saturday, and we'll be there for much of day. So I'll be broadcasting at 16:00 UTC instead. Apologies for the inconvenience, I hope you can still make it! We'll be back to the regular time next week.

Update: Due to popular demand metelliuscode's suggestion in the comments section, if you can't make the live broadcast for the Town Hall section but have a burning question to ask, leave it in the comments section of this blog entry and I'll pick one or two of the better ones to address during the Town Hall.

Read More

plasma systray, 4.2

So I've talked abut the system tray in 4.2 a few times recently, though mostly in passing. Today we hit a new milestone which marks the system tray area being feature complete for 4.2 (though not defect free .. yet!):

The white arrow on the edge is the expander: click on it and hidden icons show up. If you have no hidden system tray icons then the expander isn't shown.

You can see a progress meter for a file copy in there as well. Application jobs stack up there, as do system notifications. They automatically hide within reasonable times, are fully themable, support user interaction (such as pause, stop, resume, open, etc. buttons) and, since they are Extenders, can be detached and put elsewhere. This isn't limited to file operations, however: any application job can use this and in fact gets support for this for free when using KJob from libkdecore. Yes, that means even apps without a GUI can show their job progress in the system tray area! Possible uses? How about print progress, or K3B's burning status, or..?

The last icon on the right is pretty interesting as well. It means "you have some application jobs on the go or some system notifications available". Clicking on it hides or shows the list of jobs and notifications. We're using a generic computer or laptop icon (depending on whether it's a laptop or not) but still, we ought to have some more specific art done up for this use case. So it's a useful bit there: you can click it to hide long-running jobs so they don't endlessly bug you on the screen, and click it to get them back easily. But that's not the really interesting part. That icon is doing two pretty neat things in particular:

First, it's saying "put me at the end of the list, because I'm a special kind of entry". This marks the start of us starting to make the system tray experience richer, and we will eventually extend this kind of expressiveness to all KDE 4 system tray using applications.

Second, it's not "really" a system tray icon. At least not in the freedesktop.org sense. The system tray Plasmoid doesn't care though. It just sees it as another entry to manage like all the rest. Well, it can do a slightly better job with it because it's a native QGraphicsWidget, but it doesn't really know that either. It's more of a nice side effect of not using XEmbed in this case, but a set of D-Bus protocols instead: one for jobs and one for notifications. And yes, we've talked on the XDG list about both these systems for adoption as freedesktop.org specifications; the notifications one is based on the galago spec minus some "curiosities".

Now imagine if all the system tray icons were done similarly: not with XEmbed but over D-Bus. We wouldn't have to rewrite any part of the new system tray Plasmoid for that to work, we'd just add another SystemTray::Protocol to it and away it would go, happy as a clam. That is, in fact, precisely what we intend to do after KDE 4.2 is out.

This shows one of the strengths of Plasma that is born out of the purposeful design rules the entire team keeps in mind when we work on things: we write things to not be rewritten again in the future. We don't write really complicated stuff (that's how we can achieve such rapid growth in the number of components while not simultaneously exploding with instability), we just write things that are reasonably flexible. This prevents the "just tack on another room to the side of house" syndrome. We could have done something pretty similar with the D-Bus transition with the KDE3 system tray, but it would have been adding something to it that it wasn't written in mind for from the start. That way leads to head-meets-table-at-rapid-speed events, and having had enough of those already in my life, I try to help make sure we avoid more of them in the future.

What's really impressive is that the rest of the team Gets It(tm). As with many things in Plasma, the system tray was truly a team effort. Rob worked on the jobs integration, Dmitry worked on the notifications integration, Jason worked on the core design for the Plasmoid and took care of the X11 magic, I did the show/hide of hidden icons and lot of polishing work and Marco touched it with his usual graceful polishing wand here and there. I'm probably missing someone, too, as usual. =P

It is one of the bigger widgets, though, in terms of code. The Plasmoid itself is a little over 3,700 LOC and two DataEngines (reusable by others, of course =) were written for it: applicationjobs (336 LOC) and notifications (200 LOC). The freedesktop.org protocol implementation accounts for 1,105 lines of the widget. That's nearly twice the amount of code for the other three protocols combined (jobs, notifications and Plasmoids) and far, far more than twice as complex. The UI parts are are also pretty complex, though, given what it has to do and what it's meant to do in the future and currently weighs in at a hefty 1,294 lines. The core classes representing the concepts of Tasks and Protocols is the other 700 or so lines.

And there, in a nutshell, is more than you ever wanted to know about the new system tray Plasmoid.

Read More

.. and speaking of bugs

Speaking of bugs (in my last blog entry), we (the Plasma team) have a goal to have no more than 200 defect reports open for Plasma and its components when 4.2.0 hits. We're currently surfing at ~110,000 lines of code, with a ton of that being new in 4.2; that means a goal of approximately one report per 500 lines.

Update: I just realized I missed counting KRunner, libplasmaclock and libtaskmanager, which adds another 6,096 LOC to the total, bringing us close to the 120KLOC mark. If we added KRunner to it, we're at ~122KLOC; but that's a separate component when counting these bugs.

Another metric might be components: by my count we are shipping 100 plugins (I may have missed some, so it's at least 100), three libraries (libplasma in kdelibs; libtaskmanaer and libplasmaclock in workspace) and six apps (plasma desktop shell, plasma on screensaver, plasmapkg, the desktop theme customizer/creator, the data engine explorer and the plasmoid viewer). That's 109 discrete components meaning we're aiming for less than two reports per component, and some of those components are bigger than small.

We started at a dizzying 450+ reports about a week ago, but through careful triage and lots of commits we're already down to 294. There will be a flood of new reports with the betas that are about to come out and the bugs will get progressively more difficult to fix as we pick off the low-hanging fruit and get left with more NMBs (Nasty Monster Bugs).

The Plasma team seems to both value making things as high quality as we can given the various constraints we live within and enjoy destroying the beasties with a rather lovably mad passion. This makes me confident that we'll make our goal.

Now that we're into the feature freeze period, it's probably an idea for the KDE sub-projects to set themselves release goals. Whether it's bug counts, artwork finesse, performance benchmarks or whatever, goals can't hurt. If you do set such goals for your project, be sure to make them reasonable and clearly described to everyone on the team. This ensures that the goal will be shared and has a tangible end point that people can strive for. When the goal is met, everyone can enjoy the feeling of triumph. This is where team leadership is very useful, as an email to a list with a positive tone and a realistic set of metrics contained within can really help rev things up without burning people out in the process. =)

This is probably nothing new to most KDE (and coding) veterans, but I thought I'd mention it anyways. Happy hacking bug hunting ..

Read More

paddling upstream

Matt Rogers recently added UPSTREAM as a report resolution type on bugs.kde.org for us. I asked for this because a lot of issues in Plasma were the result of bugs elsewhere in the stack and I hated closing those reports as INVALID since they were not INVALID at all: they just weren't something we could do anything about in the Plasma code base.

Technically not all the bugs we close are really UPSTREAM, though. Some are DOWNSTREAM, namely the bugs caused by packaging foobars or poor backporting decision making and/or execution by OSVs (operating system vendors, aka "distributions" in the Linux realm). However, since we don't have DOWNSTREAM as an option we mark them all as UPSTREAM, noting where in the stack the problem really is in the comments section.

We've only had the UPSTREAM designation for a couple weeks now and already we've closed 19 reports in Plasma as such. That's probably about 10% of reports, which may sound high (and, well, it is) but it's actually a lot lower than it was.

First off, OSVs are actually getting better at packaging Plasma which is leading to fewer problems there. We're also making it easier on them by having fewer interesting Plasmoids in playground and keeping binary compatibility in libplasma while having a symbols check on plugin load (thanks to an upstream, actually; namely Dirk @ OpenSuse). I expect to see an uptick in this category, though, as we're already seeing reports coming in from packages being pushed out with half-baked backports.

Second contributing factor is that the graphics driver issues are actually getting sorted out bit by bit. The newest NVidia driver, for instance, actually works across the board with Plasma. Performance is great (even across multiple screens, apparently) and no artifacts to be seen. They aren't the only ones working successfully through issues, either, and so this area of UPSTREAM bugs is slowly but surefly declining.

Third, bugs in Qt are getting hammered out and fixed. Alexis Menard, who was a student of Kevin Ottens (explaining how he got involved with KDE in the first place =) and a Plasma hacker for the last year and a half or so is now working at Qt Software in Oslo and doing a great job of triaging issues Plasma reveals in QGraphicsView and elsewhere. So that source of UPSTREAM should also be diminishing in the coming months.

As much as it's fun to go "hey, that bug's not our fault! *CLOSE*" it really pains me to mark things as UPSTREAM because it means our software suffers due to bugs in other people's code that I don't work on and therefore have a limited ability to affect positive change in. Working around other people's bugs is sometimes possible .. but a matter of last resort, and completely off the table when it results in a worsened user experience.

For the last year we've really taken it in the proverbial ass over UPSTREAM issues, but it seems that the clouds are finally parting and the sun is shining through. 2009 may actually be a year in which the overwhelming majority of bugs filed against Plasma are actually our own screw ups. =)

Read More