I'm not feeling very well today; been having a bit of a hard time sleeping the last few nights and now I think I know why: my stomach was churning most of the day up until mid-afternoon. Feeling better now, but it seems I was probably fighting off some sort of bug. I don't tend to get really ill, I just get dragged down when I catch something. Anyways .. not very exciting nor what you probably care to read about. ;) It did mean that I spent most of the day being unproductive coding-wise; instead I soaked in the bath a bit and thought about various things. Here are some ramblings from that down time thinking.

Part of the 4.2 roadmap for Plasma is already taking shape in my head. Yesterday while talking with Chani and J.P. on irc, I realized something that is pretty obvious in retrospect (hindsight, 20/20, yadda yadda): containments have become the place to do both functionality customization (layouting, toolboxing, applet addition/removal controls ..) as well as background painting. These things are pretty orthogonal, however, and what you really want to do is mix and match between these two sets of functionalities as a developer.

There will be some odd ducklings that do everything themself: a MacOS X style dock, for instance, would want to control both the background painting as well as the layouting and applet selection. Fair enough.

But many will want to have a given style of functionality, but use the same background painting that exists elsewhere. Or vice versa.

So in 4.2 I'm going to explore adding some add-on functionality for containments: backgrounds and context menus. The latter was already planned, but the backgrounds as separate add-ons is a new idea driven by the understanding that to avoid lots of duplicated code we really need to have a way to share background painting.

This won't affect the "any applet can be a containment" situation at all, nor will it force containments to use these new add on categories. The containmnet will remain in full control, this will just provide a painless way to access work done by others.

Additionally, I'll need to go back and do some KConfig hacking again for 4.2. In particular, besides doing the API review for KConfigBackend so that we can confidently export that interface for 3rd party use in plugins, I need to make KConfigSkeleton aware of KConfigBase so that we can use KConfigGroup with it. Plasma uses KConfigGroup extensively in its config system, but KConfigSkeleton is unaware of it. This is due to KConfigSkeleton coming about before KConfigBase was really interesting or useful to write against; it was more a "behind the scenes class" versus the useful base class it is now. The problem for Plasma here is that this means we can't use KConfigSkeleton really anywhere, which sucks since it's a very convenient way to both define and document configuration systems. It also makes driving the configuration user interface simple (e.g. one line of code). We already have support for plasmoids from packages (e.g. scripted plasmoids) to have code-less configurations, but it doesn't actually work when it comes time to save the config due to this issue. It's too late for 4.1, so this gets moved to 4.2.

(edit: i completely forgot the following in the first run at this.. doh!)

4.2 will also be when we go for concrete binary compat, move libplasma into a libs module (perhaps even kdelibs?) and either split out the Package classes into KNewStuff2 or make KNewStuff2 use libplasma.

At least we'll have a happy Plasma for 4.1.