More WACkiness

An example WAC app running in Plasma

After Marco had added initial support for WAC apps to Plasma, at open-slx, we spent a few cycles on taking this to a next level. WAC apps are apps written in HTML5 which are shipped as packaged websites with everything needed included in the package. On top of the normal webbrowser APIs, WAC apps can access a set of API calls that allow access to various aspects of the underlying system, device and network information, contacts, hardware such as camera, accelerometer, location sensors, etc.).

Most of the hard work is already done by the excellent webkit. The parts needed in Plasma and KDE are support for loading the package format, and allowing access to certain system APIs. Marco has written an AppletScript Plugin, which basically wraps the WAC format into a Plasmoid so it can be loaded into any Plasma Shell (Plasma Desktop, Netbook, Active, MediaCenter, etc).

Implementing the WAC-specified APIs turns out to be quite a bit of work. I have started on the DeviceStatus API, and on my laptop, HTML5/WAC apps are now able to access system information such as software versions and battery status. The complete WAC API is quite big, so right now we only support a small subset. The basics are done, and with growing support in this API, we’re able to run more and more apps on Plasma devices.

Plasma asking the user for permission to run a certain app

In the screencast, you see how WAC apps are running inside Plasma Desktop. One interesting thing I’m explaining is the permission model, so I’d like to go a bit more into details about this. WAC apps have the concept of so-called features. The app can check which features are available on a given platform, and then provide or remove features. Plasma’s equivalent to this concept are extensions, which maps a bit, but not too differently. I’ve added a translation mechanism between those two, so what the app is now asking for is access to specific Plasma extensions, very much like our JavaScript Plasmoids.

Everything is running inside a sandbox (in our case a webkit container inside Plasma), so it is quite easy to restrict everything beyond the browser’s DOM API. When working on the permission model, I reflectd about how the user actually handles these permissions. Many people seem to complain that even if the app announces which APIs it wants to access, the user still does not really have a choice beyond all-or-nothing, so most people end up blindly OK’ing whatever the app wants. The code for WAC in Plasma is set up in a way that we can allow access only to certain bits of the API, disallow access or — and that’s the catch — fake access. Fake access means that we tell the app that we support certain APIs, but we will only deliver empty or bogus data, so the app still works, but our address book is not in jeopardy of being sent to some blackhat in a far away country.

Watch on YouTube

14 thoughts on “More WACkiness

  1. Interesting work. I think that “Autorization required” and “App requires authorization” windows should be merged for simplicity and less clicking.

    What other applets aside from WAC and Plasmoids are going to be supported in KDE Workspace 5.0?

    1. Possibly, but we don’t know if it will fit — we don’t know the size of the WAC app at that point.

    2. +1 for merging the auth dialogs, just having the “App required authorization” dialog with all icons seams much cleaner to me. (perhaps that can be expanded in a “details..” box)

  2. I’m not sure, but seems yet another google gadget?

    But that remind me about plasma’s windowed mode, so it might can make it way to “Real App” to Plasma Active.

  3. I dont understand much about this… but couldn´t you just reuse the WAC-specified API code from TIZEN ( instead of create a new implementation?

  4. @saulo,
    You’d think so.

    The Tizen source is at , organized by packages. It’s hard to figure out where anything is. If this is the device API , it seems to be a wrapper with a lot of Tizen-specific glue that calls into a vconf layer, e.g.
    vconf_notify_key_changed(VCONFKEY_SYSMAN_BATTERY_CAPACITY, battery_changed_inside_cb, NULL);
    and that C code doesn’t match the actual WAC spec.

    (It’s interesting that the Tizen source still includes the Meego ivi “in-vehicle infotainment” code. Its torturous GTK/Qt/Efl Maemo/Meego/whatever history must impose a lot of legacy.)

    It does seem crazy that every new phone and tablet device saying the “Write HTML5 apps” mantra (BBX, Tizen, webOS are all based on Linux or workalikes and Webkit) is reinventing all this stuff. Maybe the Mer project can unify the implementations, but a volunteer effort trailing behind the carnage of Nokia decisions seems very understaffed for such a big job.

  5. Skier,

    So can I expect that this WAC implementation in Plasma will be more portable? Where can I found this code?

    I understand that “hard work is already done by the excellent webkit” but I am looking code that can be used across diferent linux environments for loading the package format and access system APIs.


    1. The code is in a Git repository, you can find in my scratch area: git clone git://

Comments are closed.