pre-tokamak

Tomorrow I travel to Randa here in Switzerland as Tokamak 3 is set to start on Saturday. It seems several of us will be meeting on the trains in various places so we will arrive in small bursts.

Last weekend I wen to the opera in Bregenz where they have a massive outdoor stage. It's the one that appeared in the recent James Bond movie. They performed Aida but on a scale I'd never seen before: two full sized construction cranes were part of the set. Add in dozens of people, a handful of boats of various sizes, some truly huge set pieces and a bit of pyrotechnics and that's what they call an opera house. ;) It was a rather amazing evening.

Over the week I also attended the first wedding I've been to in many years (I generally try and avoid them), spent a bit of time in the countryside here (which is gorgeous) and tried to continue expanding my German (with moderate success).

Most importantly, though, I had time to hack on some things, and not just on the island of bugs and improvements I've been marooned on for the last couple months either. I got to do real, bone fide, new features! WOohooo! :) Yes, there was the usual bug fixing and and what not and the never ending slew of phone calls and other such stuff to attend to .. but that didn't stop me from working on a rather interesting issue (at least to me): how best to roll out Plasma desktop shell based systems into larger deployments. This mostly centers around configuration issues.

Plasma's configuration data is not scattered over numerous files like it was in KDE 3 and this brings a number of advantages with it. It does, however, make the files a bit more complex. The rather handy kwriteconfig and kreadconfig are also pretty useless with them. Worst of all, however, is that kconfig_update, which is how changes are made to user's configuration files between upgrades if/when they change, simply doesn't work well with Plasma. Or KWin, krunner or any other application that starts really early in the desktop launch sequence. The reason is that when the kconfig_update scripts are run, plasma-desktop is probably already running and so it's modifying configuration data that's already been read and processed and it's non-trivial for plasma-desktop to go back and try and change it's configuration based on those changes while keeping changes it may well have made in the meantime as well.

There's also the issue of default layouts. Some of the distributions have wanted to have different layouts depending on the screen resolution and similar things.

Looking at all the issues it occurred to me that one way to satisfy them would be to offer a runtime scripting option. Since we're using ECMA Script all over the place already, can guarantee it's availability on a system (it comes with Qt) and is easily controllable, it seemed like a fairly natural choice for this.

I needed a nice way to test and debug what I was working on, so I added a small "interactive console" window to plasma-desktop that can be called up via D-Bus. With that in front of me, I realized that this was something that other people may find useful as well. I also wrote up a small runner so you can open the console from KRunner and even load scripts from disk into the console (though you still have to press the "Run Script" button, for safety's sake).

Currently one can lock the desktop, query for screen geometry, enumerate activities and panels, add new activites and panels, remove activities and panels and set various parameters on them (associated screen, geometry, hiding mode, etc.). Enumerating, adding, removing and configuring widgets is next. The full list of the currently implemented API can be seen here.

I'm particularly happy with how the API hides the distinction between views and containments and other such details. While these are great from the software architecture point of view, they lead to confusion for sys admin types it turns out.

So what does it all look like right now?

Of course, scripts for initial layout or system updates won't run through the interactive console window but be loaded from disk and run at start up. What I will need to know (at least once I've finished the widget support) is what other sorts of things people will need and example scripts demonstrating those things.