loading random widgets

one of the main things i worked on today was support for loading widgets plasma doesn't know about at build time. this is to allow us to load various sorts of widgets that aren't appropriate or possible to stick into libplasma itself.

all widgets are, at their most basic level, housed within a Plasma::Applet. libplasma itself provides support for native Plasma widgets, aka "Plasmoids". a Plasmoid is a collection of scripts, images, configuration, UI and widget specific data files that are bundled up together into a package.

the package itself is defined by a PackageStructure which informs a Plasma::Package what should be and what could be within a given Package.

Package provides the ability to install the package locally, query the packages, fetch a given resource from them, etc. Package is how we are able to list non-c++ widgest in the Add Widgets dialog, among other things. now, Package is nothing like the packages that software applications come in for your operating system (e.g. rpm, deb, pkg, tar.gz, etc....). they are both simpler and more about accessing resources rather than managing installation (though Package does that) and calculating dependencies.

this system is all well and good for Plasmoids, but what about other packages ... like MacOS Dashboard widgets? or any other widget of this style, for that matter. the widgets have their own structures; while Package can handle this it does need a way to get at the package structure. so Package can read the structure of a package from a config file. unfortunately, this isn't enough: some widget package formats are just stupid and have no predefined structure whatsoever which makes dealing with them far more annoying and code-laborious than necessary. yes, MacOS widgets are in that category, and as such can't easily be codified in a config file without adding some flexibility that would amount to a description language of sorts.

so rather than subject myself (and those who would use this) to that sort of pain, Plasma::PackageStructure can now also be provided as a C++ plugin, giving us all the flexibility we could every hope for, need and want.

the end result is that when a widget (regardless of type) is accessed (installed, listed, opened, etc) it looks like any other widget to libplasma based applications.

behind the scenes when the Package is loaded, Applet looks to see what PackageStructure it uses. if none is defined, we assume it's a native Plasmoid. if there is one then we look for a plugin and if that doesn't work out then we try for an installed config file description. assuming that goes well, we now have the PackageStructure, which directs Package, which provides a standard interface to Applet, which makes all widgets look the same to libplasma.

neat.

the last bit of work i have to do here is to add Package install pre-processing for widget archives (most of them are just zip files) so that when the user installs a new widget we can create the proper metadata that Package needs and deal with whatever compression system the widget uses. this is the easy bit, though, compared to getting the above working. once it is done we'll have the full round-trip from the Add Widgets dialog (via Get New Widgets) to disk to applet listing to desktop/panel/etc placement.

over the weekend Zack got WebKit based widgets working, both "native" plasma ones as well as MacOS widgets. the native plasma widgets have access to things like DataEngines from javascript embedded within the webpage. this is a little different from the qscript plasmoids where the javascript is stand-alone and is the widget for all intents and purposes; with the webkit based widget the webpage is the widget and javascript to manipulate it lives inside the webpage itself.

the Dashboard stuff basically came along for free. it was neat to watch the hello world, clocks and Chuck Norris MacOS widgets load up and work without any prodding. we will need to provide some additional javascript API that some dashboard widgets assume to exist, and we'll likely never be able to satisfy the macos bundles bridge that is available on MacOS due to how tied into the platform that is but thankfully few widgets seem to use those.

there are patches upstreamed for WebKit that are required for this to work, so until they hit qt-copy the code will remain in playground. we also ran into more of the same WoC (widgets on canvas) bugs with the web applet support that we had already run into with the general WoC porting of libplasma. gotta love living on the edge of development ... constantly. ;)

and the screencast will have to wait to tomorrow, as p. is back and fast asleep in bed. i don't want to wake him; in fact, i should probably head to bed soonish myself as i have to get up at 07:00 to get him off to school.