The World Wide Web Consortium is looking into the feasibility of standardizing desktop widgets. They have done a survey on the widget frameworks available in the market. The frameworks they have surveyed are Konfabulator, Windows Sidebar, Google Desktop Gadgets, Opera Widgets, Mac OSX Dashboard, Web-Runtime by Nokia, and Joost Widgets.

The survey was performed in the first quarter of 2008 and frameworks were chosen because of their perceived prevalence in the market place. Since KDE 4 was only just released and not available as a stable option for any distribution, W3C cannot be blamed for leaving out Plasma.

"The purpose of this document is to provide a holistic overview of the widget space" is what the survey says. It compares the different offerings and tries to unify the nomenclature for the different gadgets/widgets/plasmoids.

In addition to this document, W3C has published a document that "lists the design goals and requirements that a specification would need to address in order to standardize various aspects of widgets." So W3C is trying to see if they can pen down a standard that captures the features of the current products. If they can achieve this goal, it will be easier for developers to write widgets.

This document is a nice documentation and comparison of the frameworks that are out there now. There is a table that lists the media capabilities of the different frameworks. It would be interesting to see how Plasma stacks up.

The W3C might consider including Plasma properties in their documentation if the Plasma developers contacted them. Even without adding Plasma explicitly, such an emerging standard would help Plasma developers in supporting all the different widget formats out there.

The document also describes the differences from Java Applets. The authors claim that programming in Java is daunting and that using HTML, CSS and JavaScript is much easier. That is a controversial statement considering that all programs implement HTML, CSS and JavaScript differently whilst all Java implementations (with the same version number) are the same.

After a day's work at the Plasma sprint, there's already quite a lot of news
to report. After a lot of trawling through log files, I was able to fix the
problem that was preventing the Plasma binding plugin from loading. In the end
it was something simple (as usual) namely that the method that allows the
plugin to load was not being compiled into the module since it was missing
from the generated .pri file. Once this was fixed, it was simply a matter of
changing the name of the extension we load from 'qt.plasma' to
'org.kde.plasma' to match a fix in the generator and we had a successfully
loading set of bindings.

Lots of thanks are due to Kent Hansen of Troll Tech
for this - not only did he write the binding generator and the type system for
the Qt bindings, he also fixed up the one for plasma. Oh, and if that wasn't
enough he's even figured out the bug that has been preventing the generated
code from having anti-aliasing enabled.

In order to test that these bindings worked properly, I wanted to create a
small demo that exercised the script engine code, the Qt bindings and the
plasma bindings in the same plasmoid. My initial attempt worked ok, but didn't
look very good (though it had the advantage of requiring only a tiny amount of
code). Instead, I'll show a slightly more complex example that looks prettier.

Obviously, you can't see the animation in the screenshot, but this shows four
squares spinning around a common axis at different speeds and changing
colour. Ok, it's not the best piece of graphic design you've ever seen but it
does illustrate that the crucial facilities are in place.

In addition to the coding, we also spent some time today going over the
results Seele obtained from her interviews with some of the developers. We
were looking at the user populations we are currently supporting well, but
more importantly at those that we could potentially encourage to adopt KDE and
Plasma to consider how we can improve the facilities we offer for them
too. Before anyone gets hot under the collar, this doesn't mean ripping out
functionality to 'dumb down' the interface, in fact a lot of the suggestions
were more about how we can improve the interface consistency.

Following this discussion we did some more coding and also broke down into
smaller groups so we could continue to plan for our inevitable world
domination.

As some of you may have seen, Kent has released the QtScript binding generator on Troll Tech labs. I've been playing with the code for a bit, and as with KJSEmbed one of the first tests was to make sure you could use it to write a simple web browser. Kent recently added support for QUiLoader to the bindings and as a result, I can use the QWebView designer plugin to make things simple. The result is a basic web browser in less than 10 lines of javascript:

var loader = new QUiLoader(null);
var file = new QFile("browser.ui");
file.open(QIODevice.OpenMode(QIODevice.ReadOnly, QIODevice.Text));

var web = loader.load(file,null);
web.show();

QCoreApplication.exec();

There's also a very simple designer ui file that just contains the web view and a layout. Here's the obligatory screenshot:

In 4.0 plasma had support for writing applets using Qt's built in javascript interpreter QtScript, but the facilities have been fairly limited. In KDE 3.x KJSEmbed gave us reasonably complete bindings to the Qt and KDE api's, allowing us to write applications such as a web browser in 10 lines of javascript. I'm glad to say that some plans that were discussed at the KDE conference in Glasgow are now a reality and Kent has released a qtscript binding generator based on the one used for QtJambi. The result is that we will very soon have good access to the Qt API from qtscript.

I've been playing with the output of the generator for a couple of weeks now and while it still has a lot of rough edges, it's definitely a solid foundation. Even better from my point of view as a KDE developer, the Jambi generator was designed from the start to allow you to use it to write bindings for Qt based code that is not part of the main Qt API. Using it to build bindings to the plasma APIs and in future the kdelibs API is definitely feasible.

With the great intro provided about Plasma Packages to get Apple's Dashboard Widgets running, it follows a screenshot that shows SuperKaramba - yes, it works with legacy *.skz files.

btw, SuperKaramba example that uses KHTML to display content

Kross, the scripting framework, is one of the pillars new with KDE4. While the project started already a while back in 2004 it enveloped over the time to a rather big codebase. During the KDE4-process one of the main-goals was to decrease the codebase what can be even more difficult then writting new code.

One of the big things about KDE 4 at an app level was moving from KControl to System Settings. The major complaint about KDE (from non-KDE users) is that it is too configurable, where 'too' generally means they can't find the thing they want to configure. System Settings is the product of usability-led design, and kcontrol was dropped some months ago, but it seems very little has happened since it was ported to KDE 4. So rather than just give myself an ulcer about it, I've decided to take System Settings in hand and make it good. I started by fixing a couple of little bugs but as the size of the task became apparent I decided to organise System Settings' development and maintenance first. So spent today doing this. I've started a project on TechBase to:

Here's a quick example of why it's nice to have a script interpreter embedded in Qt: Plasma's KRunner has a calculator which used code borrowed from the KDE 3.x minicli. The old code started up the bc command line calculator then displayed the result - not exactly an efficient way to do things. I've just committed a change that makes it use QtScript and the code is trivial:

QString CalculatorRunner::calculate( const QString& term )
{
    QScriptEngine eng;
    QScriptValue result = eng.evaluate( term );
    return result.toString();
}

This replaces 23 lines of code and is quite a bit more powerful. Nice!

I've made some decent progress in the scripting support for plasma today with the addition of the ability to access QPainter, QTimer and QFont from scripts. I've also improved a few other bits of the code. The result is that I've now been able to reimplement a functioning version of the plasma analog clock applet in Javascript. There's obviously more to be done, but I think this shows that things are progressing pretty well and along the right lines. The clock looks just like the C++ one (except I turned on the standard background so it can be distinguished as being the js one).

SuperKaramba as Plasma Applet running 4 instances of the Aero AIO theme.

Screenshot;