Computer :(


Progress in GSoC plasmaland

#posts , kde , kontact , planetfedora , planetkde , plasma , soc2010

Google Summer of Code doesn't kick off for a few more days, but that hasn't stopped Siddharth Sharma and I from working on the KPart which our summer of code projects are based around, and any other KDE application can take advantage of.


zomg, it's allliiiiiive

As you can see, I'm still using stock, and sometimes hackish (KTodoList, I'm looking at you!) applets, but those will all be rewritten in due time with actual Kontact applets. These are there to just take up space.

As it is right now, there is no real API for applications to control what applets get placed in the containment by default. You can specify a default layout in a plasma-$app-appletsrc style file which will be loaded by default if no other config is found. However, we're going to be taking this one or two ways:

1 ECMAscript!

Or as it is more widely known, javascript, is supported in plasma-desktop, allowing you to do some really cool things. Aaron Seigo pointed us towards this, and its a path that at some point I think would be beneficial to go down. Either an application could provide a default-applets.js, which would be auto-loaded by the part, if no config file is found, or some sort of extension to KParts::ReadWritePart which allows us to load arbitrary JS.

The Javascript doohickies are nice, but dependencies may end up being a big issue with these sorts of things. Only time will tell. There are, of course, other options…

2 Other options!

How'd you like that segue? Pretty snazzy. Wow, it's late, I'm being a dork…

Siddharth and Aleix Pol of KDevelop fame have an interesting idea for how to implement a plasma-based dashboard… Basically, instead of letting the KPart handle widget launching and hiding, there should be a small API to add/Remove widgets to the containment. At first I was against such an idea, as I didn't see how it could be sanely done, but it has a few nice upshots: The applets can be handled by the existing plugin infrastructure. For example, KDevelop has a boatload of existing plugins. Instead of having each plugin code also need to output a Plasma::Applet .so file which can be loaded by the KPart, there would be a function which would return an Applet\* or QWidget\* which we could then pass to the kpart. Siddharth will be manning that helm, and I can't wait to see what comes of it.

3 Segue again

In the beginning of writing the KPart I took code from other shells all willy-nilly not really thinking about what I was using. As it turns out, this was bad and led to much wailing and gnashing of teeth when I discovered that (not surprisingly) kdebase-workspace is not a valid runtime dependency for applications. It also turns out that there is a lot of nice stuff in kdebase-workspace/libs, including the WidgetBrowser class, which is the browser we are currently using in the desktop and other shells. Since this KPart will be existing in kdebase-runtime or something, we kinda can't use it. Which leads me to writing a KCM that acts as an Applet Browser!


Of course, this is mostly broken right now, and consumes me when I'm not busy playing with all the wicked awesome stuff in trunk \*stares at Activities\*

More some other time! Stuff is trucking along for SoC 2010!! Hopefully next time I write, I will have something to show for Kontact integration… Hopefully after the Akonadi meeting, KDEPIM builds again ;) You guys rock.