I've already taken an ungodly number of pictures in my first day here as I play with my new toy: a Cannon EOS 400. I've never actually owned an SLR before, and there's much to learn, but I'm having fun with it. It's been great so far traveling with P.: we was awesome on the flight and airports and has been just great as we travel about the city here. Kevin and his better half, Virginie, have been great hosts thus far. Part of the wonder of working using cooperative methods is that it sets the stage and mood for friendships to bloom and blossom.
In a few days we head to Milan for Tokamak: Plasma Developer Sprint Mark I, where we will get to meet several of the Plasma folk and move the project even further ahead. I have come armed with a bevy of use cases that extend beyond the traditional desktop as well as a laundry list of more down to earth, immediate and pressing challenges to be met. I'm excited.
Which is in part why I felt like blogging today: I'm in a good mood. The last few weeks have been rather more difficult. A friend killed himself two weekends ago, I had some relationship maintenance to do with an ex that wasn't pleasant but necessary for our continued friendship, I've been working through some very hard decisions about what I want to do in the next year (move to Vancouver, so P can be near his mom again? become entrepeneurial again or remain a free software hippy?) ... so a lot has been on my mind. For me, sharing my thoughts and otherwise interacting with people beyond my own little head is a slightly stressful event. I enjoy it, but it takes a lot of energy to do. It's easier to just remain quiet and kick back. I love human contact, though; I'm one of those people who goes to fairs just to walk, unknown and ignored, through the crowds.
During the quiet, however, I have been up to my usual devices: new stuff in plasma continues to roll, like the Plasma::WebContent widget, as well a bug fixes. Lots of patches have come through and been reviewed (I missed review board more and more, maybe we should set one up on a proper KDE server so we don't have to live without it, ever?).
I've also been thinking about things such as the external interpretation of my position within KDE. A recent article referred to me as the "project lead" which isn't really true; I'm the project lead within Plasma and I certainly try and help with organization, setting vision, helping defray issues that bubble up within the community, spend a lot of time talking to others both publicly and privately about KDE and Free software, etc .. but KDE doesn't have a "lead developer". However, I understand why someone from the outside, searching for a name for what it is I do would default back to "lead developer". It doesn't make me feel very comfortable, however. I feel much more like an ambassador for the project, a representative of this much bigger thing. So I'm going to try and see if I can't edge the conversation in that direction in the future: Aaron Seigo, KDE Ambassador. I'm also very happy to see more ambassadors rising as well: I'm seeing more of Wade Olsen, Will Stephenson, Sebastian Kugler as well as others appearing on the radar here and there. Ian Monroe will be doing the ambassador dance at the LinuxFoundation Collab Summit this week, while more people are giving really compelling talks at various events about KDE. A distributed approach is much more reflective of KDE and much more robust.
On a selfish note, it also takes some pressure off of my own shoulders and lets me enjoy doing it a bit more. ;) Playing with a good team is much more enjoyable.
Unfortunately, doing the ambassadorial stuff (both inside and outside the project) is a lot less fun for most people than making pieces of art (be it in code, words, pictures, sound..). It would be great if those who are stepping up and out get the full support of those in and around the project: they are rare birds to be cherished. =)
Anyways, enough about all that ... The progress with the bug triage days, wiki and mailing list have been great. A big thanks to George Goldberg for blogging about it and helping make it become a reality.
I've also been watching with glee (yes, glee! =) as KDE4 technologies continue to whizz together; it's no secret that the real impact of the Pillars of KDE4 will be realized only as they are tapped by various applications. So when Digikam (which worked out of the box with no configuration with my camera.. huzzah!) moves to using Marble for their geolocation interface everyone wins; as Akonadi and Nepomuk circle each other closer and closer, everyone wins; as Okular uses Phonon to play media embedded in documents, everyone wins ... well, you get the picture.
Speaking of everyone winning, Rafael has started the process of taking the job viewer d-bus interface he developed during the KDE4 cycle and working it into a proposal for adoption as a freedesktop.org specification. What does the "job viewer d-bus interface" do? It lets long-lasting desktop "jobs" that contain progress information (burning a CD, indexing files, receiving or deleting mail, downloading a torrent, copying a file, etc) to communicate with a visualization service. So if this makes it's way to "freedesktop.org spec" and then implemented broadly, applications will be able to show their job progress in the desktop "native" user interface (e.g. kuiserver in KDE or mathusalem in GNOME). Neat.
Along the same vein, we have a DataEngine and Applet in playground right now that mostly implements the galago notification spec. It's in the org.freedesktop namespace, though it's not on freedesktop.org which is rather... odd and has gone through rather little collaborative development (not for wont of trying) so it's also a bit rough in places, but I think having a common visualization interface for notifications would also be useful. So .. we're trying to build that bridge a bit. I've submitted a laundry list of desired changes to the galago spec. So far I've received no feedback on them though I know the galago people have to have read it because it was sent in reply to a galago developer's email; if that situation doesn't rectify itself within a reasonable time frame, I might end up just forking the spec entirely, cleaning it up and submitting it for proper freedesktop.org approval (aka not just throwing it in the org.freedesktop namespace and calling it a day). I hope we can work together on it, however.
As Lubos noted, however, the galago spec is really not suited for general notification systems. It is however, as I noted in return, just fine for popup visualization, much like the job viewer is for jobs. Hopefully we'll eventually get a notification system spec up somewhere (knotify would be a great starting point: it's extremely robust, powerful and very well proven) as a compliment to the popup visualization spec. I don't expect that to happen soon (we're all very busy already with other things), but it is on the horizon.
Finally: I've discovered that honey with
(Noting how long this entry is .. I'll try and blog more regularly to keep the size of the postings to a more sensible size ;)
