why i cook rather than eat

I ate something today that really did not agree with me. Or maybe it was a combination of things. I find that unless I prepare everything myself, eating is such a gamble like that. It's not just that one never really knows the quality of the kitchen that produces the meal, it's also that when I'm the cook I tend to be a lot more conscious of what foods I combine. When I scrounge/scavenge/eat out I tend to be less discriminatory over the combinations and end up doing silly things like eating jalapeno rich nachos for lunch, and then having a bowl of (vegan) hot and sour soup a few ours later. I think that was the combination that did me in. Ugh. So it's probably my fault.

On to more interesting things .. we've received a good number of SoC proposals already for Plasma. More important than the number of proposals, however, is the quality of them. I was impressed with the increased quality of proposals last year, but if the Plasma proposals are anything to go by ... this year is going to rock even harder.

Coinciding (though not strictly related) with this, a new wave of Plasma hackers have started to arrived on our shores. The best part of that happening is that new comers always sharp edges to catch themselves on that we haven't addressed or even noticed sometimes. API documentation inevitably improves and we get a very good idea of what needs to be adjusted or added.

I've also been watching toma's blog with great interest the last few days. With the recent round of Akonadi hacking, I'm looking forward to hopefully be able to do a couple of things: move to a KDE4 mail client full time and implement integration between calendars that appear in Plasma and events accessible via Akonadi.

Which reminds me: I was recently contacted by a fellow who has been researching timeline widgets for a couple of years now as part of his work at the university he's at in Germany. He's about to publish the culmination of his work to date in April. I've seen some demos of his work, and it's already very impressive. I think it has implications outside of just Plasma (to state the bleeding obvious ;). What's quite exciting is that we've discussed working together to bring his code into relevant areas of KDE, which shouldn't be too hard as he uses Qt4 already. =) After his presentation in April, the plan is that he will release his code under an open source license and we can go from there. I'm sure I'll blabber on more about it then. (Note: I haven't mentioned his name or other possibly identifying information, because I didn't get his permission to do so before writing this ... )

I've also been back and forth with another fellow who's been doing research (again, with practical results) in creating a way to rather powerfully define, discover and compose services in rich client applications in rather elegant ways. An outstanding problem has been the "Now that we have the API exported via DCOP/D-Bus, where do we go from here?" question. There have been bits of answers, such as standardizing interfaces via freedesktop.org or in interface classes hosted in kdelibs. But that only goes so far and still leaves a lot of the consumer-side work up to the developer to do by hand. This work provides a bridge between the IPC (e.g. D-Bus) and the consumer; in a way, one might consider it to be bringing some of the web service concepts to the rich client. I've encouraged the author (who's permission to blab his name, etc. I didn't get before writing this either ;) to submit a presentation paper for Akademy, so hopefully that will work out.

It's really enjoyable to work with people doing practical research in areas of my own personal/professional interests. One of the things I came to regret about entering the "IT industry" in the era I did was the lack of collaboration and meeting of minds. I remember reading in my youth about the great collaborations (and rivalaries ;) in science, art and philosophy in history and thinking, "I want to experience that!"

But shortly after getting into the industry, I found that the opportunities for collaboration diminished in direct proportion to the proprietization of technology. I started out in a very open environment, and probably got a bit spoiled there. It wasn't until free software seeped into my life years later that I re-discovered that open environment. Score another one for freedom.

On a more practical level: it will be interesting to see how many of these research concepts actually pan out and in which ways ...

Pimp Our Plasma!

The Plasma Theme Contest has been announced! The Plasma team is on the look for cool, crazy and beautiful SVG themes for Plasma applications.

There are already a number of them available on KDE Look and recently JP added Hot New Stuff support to the theme setter dialog making it easy to grab new themes, but we'd like to supply a few of the hottest mods out there with 4.1 while also encouraging people to experiment with new ideas.

I'm so happy about this because not everyone likes the same look (aesthetic differences abound) and I'm no artist (so I don't even try). This leaves me feeling rather disempowered in the face of "Plasma looks ugly" comments. I can't argue that it doesn't because it's largely differences in aesthetic tastes, and I can't do much to fix it because I'm not an artist. AAAAAAAAAH! You have no idea how not being able to fix something annoys me, particularly when I (and the rest of the team, too) have spent so much time and effort making things highly flexible in this area. I mean, you can even make Chuck Norris grimmace in a pink boa border. Making Chuck Norris a little less macho: now that takes some powerful software. ;)

So it is that I'm very excited about what will come of this contest.

There is a Plasma theme creation tutorial up on TechBase to help you get started and KDE Look is providing the hosting for entrants. There's also some slightly more terse and technical information on the Plasma wiki about Plasma themes.

Already this has had impact on the themes in Plasma: we're adding the ability to optionally define different SVG data for different compass directions, so that panels on different screen edges can have different light sources or whatever (it's optional because not all styles are benefited from such fine grain tuning); Riccardo has been working on a theme previewer application so it's easy to see your theme in action without restarting plasma or using plasmoidviewer a million times over; it has me thinking again about the packager application =)

So if you're an artist and you'd like to make Plasma a bit prettier, don't delay, get started today on that kick ass new Plasma Theme Contest entry.

joining the rest of civilization

After several years of absolute resistance to the whole idea, I broke down and got a cell phone the other day. It's actually a crackberry, er, a BlackBerry. The reasons for that route were multiple: I love the big colour screen, the keyboard is nice (though I also like the turn-the-phone-sideways-and-slide-out ones), it's geared towards email which doesn't set my teeth on edge like phone calls do, it has an interesting trackball based interface with the "perl" and it's unlocked so I can pick up SIM cards when I travel and have a local number during my stay.

This neatly solves part of the "giving my number to people, which results in them calling me" problem since a lot of the time it'll be a temporary number. Excellent.

And really, that's my whole issue with these devices: people disconnect from their surroundings and instead chit-chat with friends or business associates constantly. Constant dislocation of attention undermines direct human interaction and contributes, in my opinion, to the erosion of local community and society.

So it was my little quiet personal protest against the whole thing to not have one. It did give me many opportunities to share my thoughts on the matter since people would, upon finding I had no mobile phone, usually ask the magic question: "Why?" (Sometimes I got the impression they thought I was lieing to them and just didn't want them to have my number, as if that was easier to believe than me not having a phone. Heh..)

There was also the "I hate not being able to go places where people can't get in touch with me." thing. People have repeatedly pointed out to me that I can turned of a mobile phone or even leave it behind at times. While I know that, it still bugs me, and I've also had the "but I called you! Why didn't you call me back!" conversations before which are completely avoided by not being reachable at all.

Anyways... now I'll have to play the "no you can't have my number" game to protect my solitude. Which could probably be fun in and of itself, in some ways ...

So.. BlackBerrys... Linux... not great friends. I did find the Barry Project which is hosted by a Canadian company and which does actually work, I've discovered. Unfortunately for me the OpenSync support in KDE3 requires OpenSync 0.3 or better and OpenSUSE 10.3 comes with a 0.2 version it seems. I did find 0.3 packages in the OpenSUSE software barn (as I like to call it ;) so maybe I'll install it from there. Hooray for on-click install from a web browser.

Once that's figured out, I can experiment with syncing to this device from KDE4 apps.

I was going to write a DataEngine + Plasmoid for my new crackberry, which would give me a perfect testbed for plasmoid resource affinity (aka "hiding and showing user specified plasmoids when resources, e.g. devices, go away or become available"). However, the code in libbarry is ... frightening. It works, so kudos to them and all the people who put time into reverse engineering it, but the documentation for the user API is slight and the code itself is .. well .. I'll probably let it sit on my disk for a few more weeks so I can forget what I thought while looking through it for the first time so I can approach it with a clear mind.

moments of headslapping beauty

I picked up a the book "Beautiful Code" recently and have been reading bits of it when I'm in the right mood. It's certainly a "mood book" for me because without the right frame of mind, i find that it's easy to miss some of the deep truths contained in its pages. The premise of the book is that they had a couple dozen well known computer scientists and software developers write a chapter each about a specific algorithm or algorithmic concept with the idea of high beauty in mind.

There have been a few moments while reading that I've literally put my hand to my head and asked, "Why didn't I understand that already?!" Beautiful things are often like that: obvious once you can perceive them. Because of that beautiful things are often easy to discount: we tend to forget the things of greatest value and beauty because they are so obvious that we stop paying attention to them.

Things like the process by which food is made (nuclear energy production in the sun, hits our planet, a whole bunch of amazingly cool chemical reactions store that energy in these really complex machines that we call "living plants" that we can then eat because our bodies have found a way to release, and even re-store then re-release, said energy .. ATP is so cool!) because we are always eating it.

There are three things I try and do now and again to counteract this "jading through aging" effect, though I often forget to keep up the practice:

• Listen to others with deeper understanding talk about these things, as they'll give us new "ah-ha!" moments


• Explain something I take for granted to someone who doesn't: the difficulty of doing that, and the feedback from the other person help remind me just how crazy cool things are


• Experience things differently; e.g. for food: eat an entire meal with just fingers and no utensils, even if its messy.. in fact, better if it's messy. Touching the food lets me experience it with more information than I usually do when using a fork and knife. This seems to help.

Anyways.. this wasn't meant to be a blog posting about "how Aaron tries to keep in mind the wonder of life's mysteries" but about that book on beautiful code. So ... one of those "ah-ha!" moments for me was when reading Jon Bentleys' chapter called "The Most Beautiful Code I Never Wrote". In it he performs an interesting, lucid and very intuitive analysis of the quicksort algorithm by starting with a very straightforward impmlementation of it and then paring it down further and further to arrive finally at a description of its runtime that also provides the answer to that question.

Very nicely done.

But it was the "A Bonus Analysis" section tucked right near the end of the chapter that blew me away. Jon quoted Goethe: "architecture is frozen music". I love that quote. =) Then he rephreased it for software: 'In exactly that sense, I assert that "data structures are frozen algorithms."'. Wow. I'd never thought about it that way ... the idea is so fundamental, simple and beautiful.

Then he goes on to show with one diagram and a couple hundred words how a binary search tree is actually the quicksort algorithm using an ideal partitioning method.

How the hell did I never see this before? It simultaneously made me feel very humbled (a kind way of saying, "I felt rather stupid" ;) and filled with the awe of its beauty: it's a wonderful idea that data structures are actually algorithms (which we've probably already seen before) in a "frozen" representation. It's not that we construct them, traverse them, modify them, etc using algorithms: they are the algorithms, just as architecture is music. One wouldn't literally use quicksort to traverse or create a binary tree, but it's also obvious that the same number and the same set of comparisons are made in both a quicksort and in creating a binary tree. They are the same thing described in different ways (structure versus action).

Ok, maybe this was already glaringly obvious to everyone else (it's so obvious now that I write this that I feel slightly silly gushing about it so ;) but it was a nice little "ah-ha!" moment for me. It brought back a recollection of that feeling of new enlightenment that was easier to achieve as a child, when everything is new and therefore beautiful.

I'll leave with two more quotes from the end of that chapter:

Refering to the examples Jon had written in the chapter, none of which he'd compiled, quite purposefully, even those some where decades old, he said: "I hope that the deep beauty I find in them will be unmarred by superficial blemishes." Amen!

And finally ... "Beauty has many sources." =)

Multiscreen X

So it's 2008 and one would think that by now we'd have the whole mult-screen thing figured out in the F/OSS world, right? Hook up a couple of monitors to your machine and go .. right? In a word: meh. In two: you wish.

There are various fundamental issues that include the likes of xrandr failures, driver shortcomings, etc. But there are also some pretty amazingly basic stuff we just haven't gotten to yet.

Just the other week I finally came to fully understand why there are problems with panels on multiple screens: strut reservation is not designed for multiple screens.

Let me back up here a bit and explain what "struts" are: when a panel sits on the edge of a screen it may not want windows to overlap it. So it publishes it's geometry so that the window manager can keep windows out of its way and treat that area of the screen with a bit of extra respect.

Struts used to be very simple: N pixels reserved on the four respective edges of the screen. Now with extended struts we have the ability to note where those reservations begin and end. A panel can, for instance, publish that it wishes to reserve 32 pixels at the bottom of the screen starting 50 pixels from the left and continuing on for 400 pixels.

However, struts are treated as if the desktop space is one big rectangle that includes all screens. That means there is no way to reserve space on the right edge of a screen that sits to the left of another screen. To the strut definition, there is no screen edge there. Sure, the X11 API provides means to know that there is a screen edge there, but the strut mechanism ignores it completely.

I'm about to go fix a bug related to this in plasma, but it will still be hamstrung by this built in limitation.

So we have the old NETWM struts and the newer NETWM extended struts, but still no real multi-screen support. I suppose we need NETWM "complete" struts? =) This seems like a really interesting project to take on, perhaps as part of a Summer of Code project.

Coming up with an extension to the "extended" struts that takes multiscreen systems into consideration and writing a practical implementation of in a window manager (e.g. KWin) would help seal off one more pain point and it would benefit not just KDE but all F/OSS workspace projects (the NET WM stuff is a shared spec hosted at freedesktop.org).

magazine articles

Today I went for a morning walk. It's one of those wonderful little luxuries that comes with the beginning of Spring weather for me: enough warmth not to wonder what the hell I'm doing outside, enough daylight to tease out a smile. I popped by Beano's to grab a coffee then popped into the news and magazine store around the corner with my cup o' joe in hand.

I picked up two magazines to bring home: one is a boring business magazine (ok, I don't find it boring, but I'm pretty sure most people reading this blog would ;) and the other is Linux Magazine. On the cover is Tux the penguin with a superman cape and a KDE logo in a shield on his chest. The title: The Next-Generation Desktop: A Hard Look At KDE4.

I had to buy it, right? =)

I got home, sat down with my coffee and a cranberry muffin and opened the magainze to page 34 to read Joe Brockmeier's article. After reading it I smiled and fired up blogger to write this. In his article, Joe hit the following points that we've really been trying hard to both achieve in our software as well as our messaging:

• KDE 4.0 is a development / technical preview release. 4.1 is where rubber hits road for more work-a-day users. Joe notes that he can already get a full day's work done, but still...


• The roadmap for 4.1 (and beyond) was clearly enunciated


• The interface is very beautiful (huzzah Oxygen and huzzah application devs for streamlining the interfaces)


• KDE is about applications too, not "just" a desktop shell (and Joe hits on several of the cool new features; hard to do in just 3 pages of space)


• KDE is about portability: it may be a Linux focussed magazine, but the Windows and MacOS efforts got their own sub-heading and 3 paragraphs of copy to go with it.

Joe's conclusion boils down to this: there's work left to do, but it already shines in many places and is set to surpass all comers as long asthe KDE contributors keep up the pace.

Joe really enunciated all the points we've been trying to get out there: portability, roadmap, goals, etc. So we're obviously communicating clearly enough for the likes of Joe to understand it, and thanks to people like Joe who can reach a broad audience with skilled and clear writing even more people will be able to understand what we've accomplished and where we are going from here. Cool.

While at the magazine store I also glanced through PC Mag because they had an article comparing Vista, XP, MacOS and Ubuntu (remember the days when "Linux == Red Hat"? *sigh*) in an "OS shoot out". Usually such articles are really difficult to get right (how many good writers actually have enough data and experience on all those systems?) and there were points I'd quibble with (you can read it for yourself here if you wish), but what really got me was this:

Ubuntu did great when it came to Linux's (and F/OSS in general's) strenths: cost and security. It also did pretty good on application availability and installation, but fell on its face when it came to networking, hardware support and ... interface.

Networking lost points due to a combination of hardware and user interface issues. So we can put the dead last placing down to hardware support and user interface both coming up really short. The article was actually pretty positive about Linux in general, but they didn't pull punches either. It's really frustrating to watch F/OSS get panned (and come in dead last) because of the same two old issues: user interface and hardware support. (At the same time: it's awesome to see Linux be compared to the competition in a mainstream magazine.)

So what can we do about this?

Hardware support is difficult, but that takes care of itself as volume ramps up and more commercially successful client side hardware products using Linux emerge. The UMPC movement is probably helping quite a bit a here, actually. As more vendors perceive a market for their hardware, the number of drivers and their quality will generally increase.

Unfortunately, it's hard to ramp up volume when the interface is deemed inferior. Which brings me back to the Joe's article in Linux Magazine: he was able to recognize even in the 4.0 incarnation that what we are doing is not just keeping on the same line of reason and trajectory but making decisions and writing code to that will enable us to address this deficiency.

We are nearly a dozen years into this whole "F/OSS desktop" thing now and it's no secret that we're serious about being the best by, you know, actually being the best. That's not easy nor does it happen over night ... but the path is cleared and we're marching on towards the light.

In five years time I don't want to read about the F/OSS user interface coming in last compared to Microsoft and Apple. I don't think any of us do, to be honest. Many of us believe that it's precisely the kind of hard work (and at times, daring) that is going into the various aspects of KDE4 (and I'm thinking of a lot more than just plasma here) that is required for that to happen.

friday

Ah, Friday: such a perfect title for a blog entry: accurate (it is Friday, after all) but utterly useless (it says nothing about that which I may or may not write about). It's also a song title, as Ice Cube might be inclined to say: "You know it ain't no stoppin all tha doggs I'm droppin". Yeah.

Since I get asked from time to time what the aim for Plasma at our next grand stop on the release roadway (4.1 in July-ish) is, I decided to see what Google might say. Turns out Google's slipping: it's the second link for the query "Plasma 4.1 roadmap" that would take you where you want to go.

The content on that page is particular verbose, but that's just how we roll sometime. Some people are trying to help with that foible of mine by collecting content from plasma developer's blogs and the email list to erect a skeleton for The Tao of Plasma which we'll then flesh out with full sentences, capital letters and all that jazz. ;)

Back to the roadmap stuff, among other things this week I've gotten closer to closing out two of my 4.1 items: a QtWebKit based canvas widget and containment configuration issues.

The webkit widget is neat because it means without any indirect widget rendering (e.g. via QGraphicsProxyWidget) Plasma can display web content right on the canvas. This is a faster, lower overhead path to complex web content on the desktop. For handhelds it's even more appealing: why ship a whole web browser when you can just slop html right on the canvas? Ok, granted web content is more than just a web widget, but QtWebKit gets us a long ways to that end. I have the Plasma and MacOS web based widgets already working with this new webkit-driven QGraphicsViewItem, so life seems peachy. I have a little more events propagation work to do before checking it into trunk/.

The containment configuration stuff has really been a whole lot of seemingly unrelated things working up to the big bang: new canvas placement strategies for both panels and non-panels (e.g. desktop containments), more containment subclass flexibility with things such as layout choices, screen vs canvas abstraction improvements, runtime adding and removing of views as containments appear and disappear, etc.

Both Binner and Chani have also be helping out with this particular set of changes with various patches, some of which have served as target points. A good example was Binner's add/remove panels patch which should have worked as he wrote it if one assumed the libplasma API worked as expecte. Of course, it didn't: some things had only been stubbed in, some things were marked with FIXME:'s in the code and other things hadn't been updated to reflect new understandings. Once his patch worked, then I knew my work on that part was done. ;)

That's one of my favourite ways of working, actually: start with code that uses the API that should work but doesn't, get things to the point where they are working. The game is to do it without hacks, without API ugglification and with as few new lines of code as possible.

The last bits left on the containment front are making menus sharable (to increase code re-use and consistency), the ability to swap containments on the fly and the ability to create new ones that isn't a hack. Then we're done and not only will multiple panel heaven be back, but we'll be able to play with multiple desktop containments. Neat.

Panel hiding and greater content control (DependsOn: panel toolbox) are then left and I can start to ignore panels altogether ;)

Once WoC is behind us, then I can start working on the two new plasmoids I want to bring to KDE 4.1: the welcome plasmoid and the timeline.

I'm also really looking forward to the Plasma sprint in April in Milan. It's going to rock. Unfortunately, it's also during P's birthday. The bugfix? Bring him with me. We're going a few days earlier to Toulouse to hang out and enjoy life with Kevin "ervin" Ottens before heading to Milan (and finally Frankfurt for a KDE e.V. board meeting). It'll be P's first trip out of North America and he's really excited. The first 5 days or so will be pure enjoyment for us, the next four will be his introduction to what his dad does when he goes away (hang out with other crazy hackers, see interesting cities, eat out a lot) and the final two will be a nice exercise in patience. ;)

click, drag ... eject! (oh, and logout)

These days you can run KDE apps natively on MacOS .. but that's not what I'm thinking about here. No, I'm thinking about a less recent Mac-related curio, circa 198x: my hand gently grasping the Mac-tethered mouse (cue the chuck-a-wa music here ;) and dragging the disc icon to the trash to eject it. Ooh yeah. Or when things went wrong, the slightly less romantic jabbing at the drive with a straightened paperclip to operate the manual eject mechanism.

While I many not get to relive the paper clip experience, we can do something for my drag-eject nostalgia! A few days back Marco Martin committed a change to the trash plasmoid he's written so that you can drag drives and discs from the Places view in Dolphin, the file open/save dialog, the Computer tab in kickoff, etc to the trash/recyle bin. Once dropped, the volume will be unmounted and, if applicable, the media is ejected.

It uses Solid, of course, to accomplish this: 7 lines of code plus 9 #include'd headers. (More headers than lines of code ... interesting.)

But I swear it's like stepping back to a time of fond childhood memories for me. Click .. drag .. eject! Yay! I may yet wear out the DVD drive on my laptop. ;)

Anyways, it tickled me so much that I just had to blog about it...

Also, since it's apparently all the rage to discuss how one can log out of KDE4, I figured I'd add to the mystery (?) and beauty (?!) of it all. KRunner (or, more accurately, the Sessions runner) understands the following commands: switch user, new session, logout, log out, restart, shutdown and lock. I'm sure you can guess what each one does.

plasma on mobile devices

Mobile/UMPC stuff is on my mind today for a few reasons: Summer of Code candidates have shown up on the panel-devel mailing list proposing to work on mobile projects (huzzah!); I was contacted by two different vendors today about getting Plasma on their devices; I had that recurring dream again where I'm stuck inside an Apple Newton ... crying. ;)

I noted in the Containments blog entry yesterday that Plasma is designed to be rather flexible in it's presentation. One of the (several) reasons for this has been to allow Plasma to travel to devices that aren't laptops or desktop computers: televisions, media center devices, ultra-mobile PCs (UMPCs such as the EEE PC, Classmate, OLPC, etc) and even plain mobile devices... without requiring one to start totally from scratch.

Where are we right now with Plasma on mobile devices? Well, first the good news: it works. ;) Here is a video of Plasma running on an OpenMoko handheld from back in December of '07. Getting it compiled and on the phone was the work of Marijn Kruisselbrink.

It's pretty impressive given that it was pre-4.0 code running on a mere 266Mhz of FPU-less ARM processor with 128MB of RAM and no hardware graphics acceleration. This is anything but a powerful setup by today's standards; newer OpenMoko devices are rather more muscled and things like the OLPC (let alone the EEE PC) blow it away in terms of performance.

And that's where the not-so-good news starts: from a bare start it takes ~40s to load up. Some of that is going to be library loading, but a lot of it is going to be plasma itself. Once it's up, though, it's not too bad. So what can we do about the load time?

In the video you can see how the exact same widgets and Containments we ship as part of the KDE4 desktop workspace are being used. Code reuse and ubiquity! =) This makes the performance rather impressive given that it uses all the plugins that were built for full sized, modern machines. The wallpaper file it loads is not small, the Animator is not designed for small devices and none of the utility dialogs are designed to be used in that small of a space (or at least not those fonts). It's a sort of worst case scenario, really. The toolbox works nicely there, though. ;)

So one obvious avenue of improvement is to write a Containment that is designed for the phone, e.g. something with a lot simpler wallpaper management and skipping the desktop icon loading code entirely. By whittling away at the DefaultDesktop containment one could get to something much smaller code-wise and that executes far fewer instructions during startup.

At the very least one could provide a wallpaper that matches the screen resolution, even if you kept the DefaultDesktop containment as-is.

Mod'ing the Containment alone would probably shave most of the ~9s it took to show the desktop containment in that screencast, meaning in theory we'd be down to the low 30's. Admitedly still not great.

Since it's a phone, we could probably get rid of the traditional desktop panel as well. Or at the very least create one that doesn't render a complex SVG and load the default set of desktop-appropriate applets. The panel appeared to take another 3-4s to load, so if we dropped it entirely in favour of a single Containment (aping more traditional phone interfaces) we could erase that too.

Other tricks would include an SVG theme for the phone that was simpler (and so faster to load). We don't have an on-disk pixmap cache for Plasma::Theme either, which would allow us to skip the whole SVG-rendering-storm-on-load thing as well by providing a populated cache.

Cutting back on the number and nature of default applets would also probably help somewhat, e.g. not using the rather complex kickoff launcher UI.

These are all things that occur to me off the top of my head before we even get to the work of actually profiling and improving libplasma itself. It may even make sense to whittle away at the plasma binary itself which probably has a number of desktop appropriate things that we don't care about (like the dashboard); it's only 914 lines of code, but there's likely to be some savings even there to be had.

So there is a lot of low hanging fruit out there, and most of it doesn't even involved touching core plasma code at all but rather coming up with device appropriate plugins and artwork. One exception would be the SVG pixmap cache, which would likely be done using KPixmapCache and involve touching the Plasma::Svg::Private::findInCache method.

Making things potentially even a bit easier: Sebastian Sauer commited a small patch (around a dozen lines or so) that makes it possible to load scripted Containments. So my "in theory scriptec Containments are possible, but probably needs a bit of patching to work" comment from yesterday is now ancient history. ;) This would allow one to implement things like new Containments in ECMA Script, which would be run using the built-in QScript interpreter. While obviously not as fast as C++ virtually all the execution time would be in the C++ libraries, and you could edit the code right on the phone (so no need to cross-compile, etc). Bonus points for not worry about crashes while working on these things. Given that the Tiger script example is four lines of ECMA Script, one could imaging a ECMA Script containment being about that size as well ... even with the desktop toolbox retained. We're talking about some serious development time savings here.

With the webkit ScriptEngine, one could even use HTML+JavaScript to render various screen presentations on the phone ... hmm.. haven't I heard about something like that somewhere already? ;)

So I'm happy to see that our work thus far translates to even rather modest (by today's standards) systems with acceptable results: For one, it works, even with no tweaking to the default desktop targeted plugin suite it works albeit with rough edges. I can only imagine what it will be like once we get some more people actively working on optimizing plasma for these kinds of devices, and I really hope we get at least one of the plasma-on-mobile SoC projects going =)

today's surreal moment

I was driving home from dropping P. off at school. The air outside was crisp (-5C) but it was warm inside the car and I was just a few blocks away from home. The radio was keeping me company and the song "Alive" by Edwin was playing as I pulled up to a pedestrian crosswalk in an intersection.

As I'm waiting to make my turn through the crosswalk, Edwin sings out Ain't it good to be alive and this woman walks out into the street: 30-something, blond hair, three-quarters length dress jacket, a tall coffee in her hand steaming away ... my turn signal is clicking on-off, on-off as she walks in front of my car.

And then she just collapses .. crumples over like a switch had been turned off inside her.

Straight down she went onto the pavement in a heap, her coffee hitting the ground and spraying everywhere. It was thick and white with cream (a cappuccino?). She lay face down in the coffee puddle explosion, not moving.

Ain't it good to breathe the air, Another spin around the sun...

One of her legs was twitching very slightly, but otherwise not a sign of life. The turn signal continues to click inside the car as traffic stopped so as not to run her over. People got out of their cars and ran over to help her. Thankfully there were people with some medical knowledge who started to checked her over. Calls were placed to 9-1-1, the paramedics were on their way.

On this spec of light in the universe, A little peace of love in everyone

She didn't move at all the whole time. I thought, "I hope it was 'just' a seizure and not something even more serious. Like a heart attack, a stroke, ..." Since there were other more capable people already on the scene, I moved my car out of the way as soon as it was safe to and continued on home.

Aint it good to be alive, To feel the sun strong against your face

Yes it is good to be alive. Fragile as we are, we never really know how long we have left. Right now, it's time for me to go find someone I haven't said "Hi" to or hugged in a while and fix that.

the power of Containments

In Plasma all the "top level" groupings of widgets are Containments. Desktops are containments, panels are Containments ... everything that holds a group of desktop widgets is a Containment. In addition to being the atom of grouping, Containments are responsible for the presentation of things beneath widgets (e.g. wallpapers) and around widgets (e.g. context menus, toolboxes). All the Containments live in the scene, which is called Corona in the code.

Containments themselves are plugins; in fact, they are a specialization of Plasma::Applet and come with all the same flexibility plus a little bit extra. (I suppose that means that in theory you could have a superkaramba theme or a Mac Dashboard widget as your desktop or panel ... it would require some minor patching in corona.cpp around line 400 to work in practice, however.)

Right now there are four Containments that I'm aware of available for the Plasma workspace: DefaultDesktop, Panel, Null and AnalogClock (of course ;). I believe the Amarok guys have also written a Containment specifically for Amarok's needs. To give you an idea of the complexity involved, Panel is 329 lines of code (including the header) and DefaultDesktop is 2,213 lines (though that also currently includes wallpaper Package support, threaded wallpaper rendering and all the legacy Desktop directory loading code). With scripting, you could do this without C++ even (though right now we lack some useful/necessary bindings to the Containment class to make this practical ... not a huge amount of work though).

The runtime definition for a Containment (such as your desktop area on a given physical screen) is stored in the configuration file looking something like this:


[Containments][1]
formfactor=0
geometry=0,0,1280,800
location=0
locked=false
plugin=desktop
screen=0


The Containment plugin that is loaded is defined by the plugin= entry. Change that entry and you change the containment. The widgets inside stay the same, only the Containment changes ... (to protect the innocent?)

Changing the screen= entry alters which physical screen, if any, a containment is associated with. This is where this feature overlaps with the zooming: zooming out is how one gets an overview of all available containments (modulo panels) to switch between them or just interact with widgets that on other Containments (including moving them between Containments). This has all been there since 4.0.

(By the by, if you have been looking for a longer explanation of the zooming concept, here's a blog from last July where I wrote such a thing.)

Plasma has been designed with this idea of switching Containments as a very basic and rather central concept. Those following closely will have noticed that I've mentioned this idea more than once in various screencasts and blogs in the last year or two.

However, it seems that the full implications of this particular feature set is being missed, because when, in passing, I noted what this means in relation to something like the toolbox (remember, that's the containment's job) on panel-devel people were ... surprised. I was surprised they were surprised. I thought I was stating the bleeding obvious, but apparently I wasn't. So, lots of surprised people all around. To join in the party of surprised people, here it is:

If you want a different feature set, select a different Containment.

So if you want no toolbox, a completely different neat/crazy background concept, something that incorporates a different widget layout schema, or $WHATEVER ... you just need to find a containment that provides that. This is similar to how instead of having one clock applet with a bazillion configuration options and widgets, we instead have clock visualizations that share most of their code with each other and you select between the different clock faces when choosing a clock to stare at.

The inspiration for this approach was watching the various Kicker PanelExtension classes and feeling the pain of just how limited they were in what they were allowed to do. Because of that, people creating things like the Mac dock would fork bits of kicker, write their own panel system from scratch, do it in Superkaramba, etc. That seemed really unfortunate. People want radically different ways of dealing with panels, and I figured they'd want the same with their desktops, media centers and mobile devices. So why not make that part of the interface a plugin that's as flexible as any desktop widget itself is?

Now let's reflect on the idea that I'm not keen on making the desktop toolbox configurable: maybe it starts to make sense to you that it's an unnecessary complication because the whole Containment is a plugin. The toolbox has a point and purpose, it's improving nicely as we go and, yes, I personally think it will become something rather compelling .. but at the end of the day it's just part of another plugin loaded at runtime. The only hardcoded bit is that it's the default plugin to load in lieu of other configuration directives.

(If you're wondering if other Containments can take advantage of the toolbox if they wish, yes they can. The Containment class provides access to it for any Containment plugin that so wishes to use it.)

Currently, Containment switching and creation is "hidden" in the appletsrc config file. We will be making UI for it, hopefully for 4.1. It's been pending completion of the DefaultDesktop config dialog which we will then genericize into a general Containment config. To the user this will appear pretty much like any other wallpaper setting dialog, only with a hell of a lot more punch as it will give access to more than just wallpaper changes when you hit that "Ok" button.

toolbox roundup

Here are the pain points I've culled thus far on the desktop toolbox:

• My corners are already occupied (Possible solution: user moves the toolbox)


• It disturbs the feng shui of my wallpaper (Research: less intrusive default appearance ... improved themability?)


• I don't have a use for it (Deferred: revisit when zooming is complete)

Past pain points that have been fixed include:

• It "spasms" if you mouse over it the wrong way


• Innactive state is too bright


• It animates out when not intentionally triggered (e.g. when closing a maximized window)


• It shrinks when I zoom out


• When I zoom out on the second screen, the toolbox is no longer visible, leaving me without a way to get back

If I'm missing pain points for the toolbox, put them in the comments section here and I'll add them to the list.

I really need a tool for managing this. Something collaborative, a bit more structured than a wiki but as easy to use. Bugzilla is way too clunky and defect reporting oriented (not to mention that as a user, I dread being confronted with a bugzilla report form =/). Something like review-board, but for enumerating feature sets, recording pain- and plus-points, gathering votes on them, noting possible avenues of research, recording cures for the pain points as they happens ... Right now I'm keeping lists pretty much manually and as a user I would have no idea where to effectively drop my pain point.

In university? Looking for something awesome this summer?

Google's summer of code (SoC, for those in the know) is upon us, and KDE has already started the process of putting together ideas. Over the last week or so I've puttered around on various ideas for SoC projects relating to plasma and krunner. We have project mentors already lined up, so don't hesitate: start writing your project proposals today!

And don't let my lack of imagination tie you down! ;) If you come up with something original that is interesting and imaginative, that's extra points in my book.

Also, the Akademy 2008 call for presentations has gone out. We've already received submissions (I'm on the program committee, so I get to see them), therefore I'm expecting a bit of a deluge. Last year we had more than we could handle, and we're off to a good start already this year ....

It's interesting to be part of a community and project where the challenge is not growth, but keeping up with it. All I can say is: Don't stop holding our feet to that fire of progress! =)

superkaramba++

So I finish out the Plasma::Package support and blog about it. At the end of that, I email Sebastian saying I'd like to get Superkaramba supported in the same way as Mac OS Dashboard widgets, especially since Superkaramba is a lot more "native" to KDE in the first place. My email is sent off to ask what the mimetype for Superkaramba packages are. But before he reads my email, Sebastian has already gone crazy on the ScriptEngine front and done all the work. I see his efforts pour through on the commit list. The result is equal footing for Superkaramba in a very visible manner, as you can see here:



So now as a user you can load your favourite SK widgets, and as an SK developer you can continue to utilize your knowledge of SK theme creation. Even better, you can use things like Plasma DataEngines in your 4.x SK themes, and now we can load them from files in a nice user-friendly manner. (Sebastian also covered off some UI details in the dialog before I could get to them!)

I love it when a plan comes together. =)

fixing versus working around problems

At times people will come to me, or the Plasma project in general, with a request to work around a problem. One such request we've gotten a few times recently is to be able to turn off the desktop toolbox. The immediate question I have is, "Why?" and my immediate response to a request to do such a thing without an explanation of the pain points is, "No."

Here's why: usually if the pain points are identified they can be addressed. Personally, I'd rather fix things than simply work around them. Why? Well, besides resulting in a better product in the long run (which should be enough on its own) this prevent the accumulation of configuration options and code paths that exist only to work around problems. That's a bit like putting corks on the end of all the forks in the house because poking yourself in the eye with one hurts. Instead of corking your forks, maybe you should be asking yourself, "Why do I keep poking myself in the eye with them?" If you can answer that question, maybe you'll find a fix that doesn't render the forks in the house more cumbersome to use.

There is an annoying reality to be dealt with, however: not all fixes will happen immediately.

This fact leads sometimes to the suggestion that a short term solution should be thrown in for the interim. The problem with this idea is that these "short term" solutions way too often become long term bodges. Worse is when the problem actually gets fixed, but we can't remove that "temporary" solution because someone has decided they really, really need it (often they don't, they've just gotten used to it being there... change == bad, after all).

Even worse, when it's a work-around what usually ends up happening is that we stop getting feedback and testing from those who felt that particular pain in the first place. The two-fold downside here is that (a) Plasma developers don't know when the issue is actually fixed (or not) and (b) those users end up getting shorted when their pain point is addressed because they probably will stick with the work-around out of inertia. Why bother writing software in the first place if it doesn't get used, right?

So when coming to us with a paint point, instead of proposing a solution (e.g. "Let me turn off the toolbox") explain what the pain points are.

Karol Szwed described (one of?) his paint points with the toolbox as "Whenever I close a maximized window, it animates. That's visually distracting and annoying for me." Now that is feedback I can work with, and I fixed that issue today. Turns out it was a pretty trivial thing to fix actually (we now check to see if the hover event that was triggered happened from crossing the threshold area of the toolbox; this prevents spontaneous hovers that happen in the main target area of the box from triggering activity, which is what happens in the window close case).

I'm interested now to hear from Karol if he finds the toolbox OK or even just better now. Hopefully the answer will be "yes", but maybe it'll be "not yet satisfying, though this is better". If that's the case, then we'll get on to the next set of pain points.

Only once we have arrived at a set of non-resolvable pain points is it a valid proposal to start working around them. And yes, I recognize that there are non-resolvable pain points, even if due only to people's differences in personal tastes. That is when we start bringing in the options; and if we can we try and come up with a passive configuration mechanism.

We're not there yet with the desktop toolbox, though. The next set of fixes is allowing the position of it to be changed (e.g. different corners, edge middles, ...). This requires making the painting code more generic (it assumes the top left corner; that stupidity is the fault of my own lazyness combined with time pressure pre-4.0... not overly hard to fix, though). Once that's done, then we'll see what pain points remain.

It's surprising how often by just chipping away at paint point after pain point, a feature at some point "suddenly" becomes not only palatable but has perceived value.

Under the category of "dealing with Aaron 'The Psycho' Seigo" (that's my wrestling stage name): it's also great if you don't try to cleverly convince me that your proposed solution addresses a real problem through fanciful argumentation. It may be a personal foible of mine (probably is) but if you try and BS me, I'm more apt to just ignore you. Nobody's perfect.

So, for instance, some individuals claimed that the toolbox interfered with their ability to close windows. This is obviously untrue since it lives beneath all windows. Instead of searching for additional reasons I should care (e.g. by construing a "usability problem" that isn't your pain point, and this case is just plain bogus), simply describe the symptoms of the problem much like Karol did. Your "job" isn't to convince me, it's to explain the problem. I'll believe you have a problem if you just say what it is. Then I'll try and come up with a solution (often with requests for further feedback from you on it). No exercising of your extreme cleverness is required.

This is really a lot like the doctor and patient relationship: as a patient your job is to accurately describe the symptoms. If you start trying to offer diagnoses you're going to at best be wasting the doctor's time and at worst throw the doctor onto the wrong track as he might interpret your self-diagnosis as an explanation of the symptoms. Even if you're a doctor, you're probably still best served by explaining the symptoms (though you'll probably do a much better job of that than your average patient): the diagnostician's specialties may be different from yours and their subjectivity is invaluable.

Of course, we are still left with the issue of "not all outstanding issues will be fixed immediately". The question I have to ask myself is if it is better to write software that will still be useful in 10 years time or if I'd rather smooth over (often rather minor) inconveniences today. I personally don't want to do a rewrite of the desktop shell again. Ever. So while I do bow to pragmatism whenever plausible, I'm also trying to prioritize the future so that we don't end up with another kicker, which is to say: a great app that just can't be budged further, resulting in the loss of so much of the effort that went into it.

Given how far we're getting between 4.0 and 4.1 (not to mention the backporting we've done), it seems we're going fast enough that we can afford to lean a bit more towards "future benefits" than if the project was moving at a slower pace.

Plasma Packages

Here's another of the topics I was going to show in the screencast: Packages. The test case was getting Apple's Dashboard Widgets to work out of the box. The rules were that we couldn't adjust any of the Plasma infrastructure at all .. it has to all work with Packages and ScriptEngines. This meant changing and improving a few things in those parts of Plasma but the result was .. well, let's take a look:

In the Add Widgets dialog the Install New Widgets button is now a menu, letting you choose between downloading from the Internet using GetHotNewStuff and DXS (where what you are about to see is even more automated) or opening a widget from a file. Our test case was the Hello World widget example from Apple.

When you select the "Open From File" entry you get this:

It's an assistant dialog that lists all known packages. It doesn't list all known applet types because to the user it shouldn't matter whether a widget is implemented in Python, Ruby, ECMA Script, XTHML+JavaScript or what-not. If they behave the same and load the same then to the user they are the same. The difference here is the package type: Apple's widgets are different from Plasma's native widgets in how they are packed up and they appear to the user as different.

I'd like to eventually automate this by trying to get plasma to figure out what kind of package it is automatically. Unfortunately right now we don't have mimetype detection for different kinds of widgets and I just haven't done enough research with all the possible package types before me to do this. This is something I want to look into for 4.2 (unless someone beats me to it, of course).

Anyways, the way we get this listing is Plasma queries for all known widget types. Every widget type advertises what "language" it is; for Mac Dashboard support the language is "dashboard". Every widget type may also advertise what sort of package structure it uses. Here's the .desktop file contents for Mac Dashboard:

[Desktop Entry]
Encoding=UTF-8
Name=Dashboard
Comment=MacOS X dashboard widget
Type=Service
ServiceTypes=Plasma/ScriptEngine
Icon=internet-web-browser

X-KDE-Library=plasma_appletscriptengine_dashboard
X-KDE-PluginInfo-Author=Zack Rusin
X-KDE-PluginInfo-Email=zackr@kde.org
X-KDE-PluginInfo-Name=dashboard
X-KDE-PluginInfo-Version=pre0.1
X-KDE-PluginInfo-Website=http://plasma.kde.org/
X-KDE-PluginInfo-Category=Applet
X-KDE-PluginInfo-Depends=
X-KDE-PluginInfo-License=BSD
X-KDE-PluginInfo-EnabledByDefault=true
X-Plasma-ComponentTypes=Applet
X-Plasma-Language=dashboard
X-Plasma-PackageFormat=dashboard

Currently Plasma has package structures for wallpapers, Plasma themes and widgets. New ones can be added at runtime, however. If the package structure is static, which is to say the files are always in the same place in the package, you can do this with a simple rc file. The PackageStructure class can read and write these files as well. If the package is not static, then you can instead provide a C++ plugin that manages this. Also, if the package requires special installation routines the same C++ plugin can provide that. Both are true in the case of the Mac Dashboard widget support.

So when a Mac Dashboard widget is opened up, Plasma looks at the X-Plasma-PackageFormat entry and goes off in search of the dashboard package format. It finds it here:

[Desktop Entry]
Encoding=UTF-8
Name=Dashboard Widget
Comment=MacOS dashboard widget
Type=Service
ServiceTypes=Plasma/PackageStructure

X-KDE-Library=plasma_packagestructure_dashboard
X-KDE-PluginInfo-Author=Zack Rusin
X-KDE-PluginInfo-Email=zackr@kde.org
X-KDE-PluginInfo-Name=dashboard
X-KDE-PluginInfo-Version=pre0.1
X-KDE-PluginInfo-Website=http://plasma.kde.org/
X-KDE-PluginInfo-Category=Applet
X-KDE-PluginInfo-Depends=
X-KDE-PluginInfo-License=BSD
X-KDE-PluginInfo-EnabledByDefault=true
X-Plasma-PackageFileFilter=*
X-Plasma-PackageFileMimetypes=application/zip

Mimetypes and filters for the file selection are defined, as is the library and plugin name by which to load it. At this point Plasma can now call the install method which looks like this in the dashboard package structure plugin:

bool Bundle::installPackage(const QString &archivePath,
                            const QString &packageRoot)
{
    QFile f(archivePath);
    f.open(QIODevice::ReadOnly);
    m_data = f.readAll();
    f.close();
    open();

    if (m_isValid) {
        m_tempDir->setAutoRemove(false);
        QString pluginName = "dashboard_" + m_bundleId;
        //kDebug() << "valid, so going to move it in to" << pluginName;
        KIO::CopyJob* job = KIO::move(m_tempDir->name(), packageRoot + pluginName,
                                      KIO::HideProgressInfo);
        m_isValid = job->exec();

        if (m_isValid) {
            //kDebug() << "still so good ... registering";
            Plasma::PackageMetadata data;
            data.setName(m_name);
            data.setDescription(m_description);
            data.setPluginName(pluginName);
            data.setImplementationLanguage("dashboard");
            Plasma::Package::registerPackage(data, m_iconLocation);
        }
    }

    if (!m_isValid) {
        // make sure we clean up after ourselves afterwards on failure
        m_tempDir->setAutoRemove(true);
    }

    return m_isValid;
}

What's happening in the code above is that Bundle opens the file at archivePath and makes sure it does indeed have the needed contents. It then copies it to packagRoot and registers the widget. Reigstration is accomplished by creating a PackageMetadata object, setting the relevant fields and passing it to Package::registerPackage, optionally along with the path to an icon for it. This creates an entry in the ksycoca database using a .desktop file that looks exactly like a native Plasma widget, except that this one is marked as being in the "dashboard" language.

This process all happens fairly well instantly and the result is that the widget appears in the widget listing alongside all the others:

The user sees no real difference. Places on the canvas we get:

As with native Plasmoids you can rotate it, resize it, drag it around to wherever you want, etc. Corona, Containment and even Applet are all blithely unaware anything different is going on. Zack was downloading various widgets from apple.com and trying them out and they tended to Just Work(tm).

(There are some issues currently with QtWebkit and these widgets (such as the white background and incorrect starting size), but Zack has pushed fixes for those upstream and those should be trickling down soon.)

Remember, however, that this is not specific to Mac Dashboard widgets. We can do this for any widget type we want. Indeed, Zack went ahead and did up a "native" webkit based widget for Plasma. As with Mac Dashboard widgets you do it all in HTML and use JavaScript within the webpage itself to manipulate it. Unlike Mac Dashboard, you can access Plasma goodies ... like DataEngines. So from embedded JavaScript you can fetch data from an engine and display it on your web based widget. Langauge type is "webkit". Nice.

(In fact, the Package stuff isn't specific to widgets at all. We could apply this to all sorts of after-market application add-ons.)

If you would like to add other types of widgets, I'd be happy and interested to both help you out and get resulting code into svn. Google Gadgets, Yahoo widgets, Windows Vista widgets, Opera Widgets ... they are all game. While they won't have all the features of the native Plasma widgets or cover the same kinds of topics, it would be great to be able to give people access to the whole world of widgets on their desktop.

Be Free to use the widgets you want, we have no agendas to push here.

kickoff improvements

So, this one of the topics I was going to screencast about before being hit over the head with the lameness of media in the free software world was progress on the new application launcher interface (ALI, floats like a menu but stings like a bee). While I figure out what's up with recordmydesktop, I figured I'd just blog about it instead. (BTW, hats off to Phonon, jack and the few other projects that are helping us Getting Media Right(tm) for the long run; I know things often get worse before they get better, so we should be getting really good any time now ;)

So, kickoff ... well, a picture is worth a 1000 of words, so they say. (But then if that was true you'd think they'd state that fact in a picture rather than use words and therefore save time and verbage while making their point more clearly. ;)

There's a lot going on in that shot, and here those things are point by point:

• There's the username, host and branding at the top of the menu. This was contributed by Stephan Binner from the OpenSUSE team and probably looks familiar to most OpenSUSE users. The logo (which is a temporary graphic to be replaced with something less lame ;) is clickable and will take you to a website. All of this is configurable so that our downstreams don't have to do any source code hacking or screwing with icon themes. In fact, in 4.1 Plasma themes will support a logos.svg file that contains various bits of branding in it so that downstreams can provide one file and get their branding sprinkled tastefully around. The defaults will remain KDE themed, of course. The upside of recognizing this behaviour of downstreams and working with it is that we can take it into consideration, do a better job of making it easy and work decently upstream and make it easier for downstreams to work with KDE in this way. If you're a downstream and have some workspace branding thoughts, don't hesitate to contact us on the panel-devel@kde.org mailing list.



• The grey box in the top right is awaiting artwork, but it works already: when you click and drag you can freely resize the menu. This was also submitted by Binner.



• No more HUGE BOLD fonts for headings. They are calmer now.



• The selection indicator is now a rounded rect. It has a gradient to pull the eye gently towards the text (the meaninful bit), while tying the icon and other bits associated with the text together. It doesn't get in the way of the icon or other graphical accoutrement that may appear. The icon of the selected item also grows. There was long discussion *ahem* about how to do this. I really dug my heels in and refused to budge until we had a solution that wasn't a compromise one way or the other and once people got over the fact that I wasn't going to be cool with a quick "fix" that simply introduced other problems, we really started getting somewhere. The result was a real team effort. I think we're getting there with this new graphical treatment, though I'm sure there's more to go even yet.



• The current tab is blended with the content visually for better visual association. The cute little animation of the icon raising is still there of course. =)



• Sub-texts (the little grey bits under the main text in an entry) are still shown on mouse hover only ... with two exceptions: If there are multiple items in the category with the same name we now paint the subtext always; this way if you have 2 "Terminal" applications, you can tell at a glance which is which without mousing over them. The other exception is for lists such as the Recent Documents list where you always want the subtext to see the full path of the document in question. This approach preserves the clean look of minimal text on screen at once while painting that extra text when it is actually of immediate need.



• You can't see this one in the screenshot, but it paints properly when reverse now so those using the desktop with a RTL language can be happier.



• Something else you can't see in the screenshot is the headers on the Applications page are now in breadcrumb style on one line using the same font style as all other headings. Eventually I want to make these clickable for really fast navigation.



• You can right click to swap between Kickoff and the traditional menu now; they are still separate plasmoids but this just makes it easier to swap between them. Neat.



• Lots of pixel twiddling has gone on: better spacing; consistent sizes of items in the lists, even on the applications page; text and icons never touch anymore; all left/right edges of items line up at all times; small indentation before the subtext. It's been fun as numerous people have piled on and fixed these little things. People paying attention to pixels like that excites me. You might think I'm easily excited, but it's the pixels that make the differences.

There is more to do: making the breadcrumb trail clickable on the apps page, changing the position of the tabs depend on where on the screen the menu appears (Will Stephenson has a patch drafted to do this; it's almost there), hooking up the search with Runners, showing the menu right on the desktop when kickoff is placed there (possible now that we have WoC), etc. But it's already approaching something that I think people will like a lot more, i think.

And yes, there are other options available that you can replace this particular ALI with. That's what plasma is all about after all.

multimedia: it's time to get serious

i am tired of the state of multimedia in the free software world.

phonon has eased so many of my multimedia pains while using kde4 apps (such as re-routing audio to my usb headset) that i'm getting sightly spoiled. i imagine it's what windows and mac people have felt like .. well .. for a long, long time. and that in itself is just sad that we've waited this long.

for the last two days (on and off) i've been trying to put together a screencast. in the past i've used recordmydesktop with the qt-recordMyDesktop front end. now, no love. recordmydesktop sometimes works. if there is anything touching the soundcard it just refuses to work. the rest of the time, it sometimes works. randomly. i've now done half a dozen records that didn't come out (no audio or just nothingness). and so for right now, i'm done. no screencast, i'm sorry. blame media on linux. i've done my bit, and it's let me down. were i a normal human being i'd be off back to proprietary software.

this is pathetic and alarming.

it doesn't end there, though. i've played with the various sound recording apps: audacity, jokosher, etc.. they all fail badly in one way or an other. it's not the UI (ok, those are pretty crap too, tbh) but rather the utter lack of sensible media hardware interaction.

we clamour over our ability to play media, probably because that was a long and hard road, too. but now we're at the point where we need to be able to record media ... and you know what? it's really, really bad right now.

a few years back we were way behind with display technology (think x.org) and we're eventually catching up with that (i have a blog i'm working on that topic, actually). today we're at the same sort of point of suckage when it comes to media play and capture. we must fix this or else go down in flames.