PackageStructures

Today I tackled two things which I wasn't really looking forward to doing: fixing up the keyboard state applet (which probably should be renamed the input device state widget :) and getting rid of the custom Plasma::Package in the Image wallpaper.

The input device state widget (IDSW?) is an accessibility tool that shows what keyboard modifiers are pressed, what mouse buttons are doing what and lets you set those states directly by clicking/selecting the different buttons. This was originally written for KDE3's kicker and then was ported to be a Plasma widget.

Sort of.

It was done in the most minimal way possible, really. It still uses QPushButtons wrapped in proxy widgets for the canvas, PNGs for the images and generally reminds me of Athena widgets style wise. :) It's been sitting in kdereview for months even since it was ported; I haven't moved it out of kdereview because of its horrific shape, and nobody has stepped up to fix it. That means it has fallen to me, and once I started working on it I began to understand why nobody had touched it. Oi vey.

Currently the patch is -367 +366 lines, so the change isn't that much and I have a bunch more work left to do on it. Probably another half day of hacking, actually. Currently it uses Plasma::Svg, Plasma::IconWidget and no proxied widgets. It could still be a lot better, but once I've got it working 100% properly again it should be a lot easier to get it there. I'll probably also break out the handful of classes into their own files while I'm at it ... working on a file that's nearly 1000 lines long with half a dozen classes in it is more annoying than it really needs to be. :)

While I'm still working on the IDSW, I did manage to finish up the Wallpaper PackageStructure thing. Now all the Wallpaper plugins can share the one packaging system. While doing this work I noticed that the role of PackageStructure isn't obvious to people and that PackageStructure had a couple of small annoyances itself. So I fixed the annoyances in libplasma and then implemented everything that was in the custom Package classes as a PackageStructure.

What the heck does that all mean?

Well, a Plasma::Package just represents a way to get at a file structure on disk in a generic way: you can ask for file paths, entry lists, etc. by semantic name. So with wallpapers you can ask for the "preferred" entry, and that will get you the path to the "best" wallpaper image for the screen resolution, or you can ask for all the "images" and it will return all the known image files in that package .. wherever they might be.

A Plasma::PackageStructure is the "driver" and tells a Plasma::Package exactly what "preferred" or "images" means. The structure can alter the contents when the path changes, allowing for dynamic package layouts as well as provide user readable text for use in user interfaces for packaging purposes.

Plasma::PackageStructure is designed to be subclassed, and it's been used for all sorts of things in Plasma already: wallpapers, Plasmoids written in various languages, MacOS dashboard widgets, SuperKaramba widgets, Google Gadgets .... Plasma::Package on the other hand is not designed to be subclassed; instead it is designed to take a Plasma::PackageStructure and use that to figure out what's going on. So if you ever feel the need to subclass Plasma::Package, you're probably doing something wrong and you should come find me on #plasma or plasma-devel at kde.org for some pointers. :)

In the case of the Wallpapers, the package picks the wallpaper file to use based on whether it's a wallpaper package (bundle of papers at different resolutions) or a single file and what the Wallpaper plugin is doing at that moment.

To get a usable Package, a Wallpaper just does: Plasma::Package(pathToWallpaper, Plasma::Wallpaper::packageStructure(wallpaper));

At that point you can then ask for "preferred" and get your answer. It's pretty cool how the PackageStructure concept has made it possible to use the simple Package API all over the place (so you just need to learn one API) even though they map to such wildly different things on disk. Yes, boys and girls, writing code can be lots of fun. :)

Anyways, that was my exciting day. I can tell that feature freezes are upon us when my days fill up with such "fun" tasks. ;)