plasma, excerpt from an email

Introducing someone to the behind-the-scenes life of Plasma is something I do fairly regularly these days. I'm starting to actually get good at it, and now that we essentially have the core branding direction for KDE4 settled in (allowing me to work on plasma.kde.org without doubts lingering in my head), this is the kind of stuff that needs to end up in the technical areas of the website over the next couple months.

Today I gave someone the "five cent" tour via an email of Plasma concepts, covering the most important high level concepts to get them oriented enough to start exploring. After writing it, I thought I'd share it with you on my blog because I'm not sure how much of all of this is really clear and apparent to others. Given that I've read such absurdities as "Plasma is just MacOS Dashboard done poorly" in the last couple weeks, I'm going to guess that it isn't overly apparent to everyone. ;-P

Without further rambling, here's an excerpt from that email:

I should probably save you a few minutes of head scratching and give you a quick list of terms that ret flect the technical design of Plasma:

In libplasma we have:

* Corona: the base canvas where all things "live"
* Applet: the base class for all Plasma widgets
* Containment: a means to collect widgets into sets; Containments are not nested.
* DataEngine: a simplified and abstract API to data sets; this makes it trivial to write widgets that can access all sorts of data ranging from windowing information to device information to online services such as twitter.
* Service: a simplified and abstract API for services, be they local or remote. it provides the "write" side to DataEngine's "read"
* ScriptEngines: the glue layer between Applet, DataEngine, etc and scripting languages as well as third party frameworks such as E17's Edje or Google Gadgets.
* Svg: simplified access to themed Svg based graphics

.. and much more, but those provide the basic plumbing

we then have a constellation of plugins:

* Plasmoids: Applet based widgets
* Containments: specializations of Containment for various use cases (object based desktop, traditional icon based desktop, panels, screen saver overlays, etc)
* Runners: search query providers
* Wallpapers: background painters
* DataEngines: data providers (may also provide a (set of) Service(s))
* Services: service providers
* ScriptEngines: glue layer implementations (HTML/CSS, JavaScript, Ruby, Python, Google Gadgets, Edje, MacOS Dashboard)

we bring all these pieces together in "shells", which are standalone applications which create a Corona, define a default setup of Containments and widgets and handle the high level user interaction (e.g. wallpaper configuration). these include:

* Desktop: what you see when you log into a KDE 4 desktop
* Screensaver: provides widgets-on-the-screensaver
* Plasmoidviewer: a widget-in-a-window shell; very simple, designed mostly for testing widgets
* MID: the start of a shell design with mobile internet devices in mind

this design allows us to separate the infrastructure (libplasma) from the components (the plugins) and allow us to remix them in many various ways.

the fact that applications so very different from a desktop shell, such as Amarok2, can use this same libplasma based system demonstrates the flexibility.