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;

last several months have been a hard run, having exams one after the other, but I was able to commit several line now and then for raptor project, this is just one widget that we will use with raptor

http://upload.ruphy.org/slideicons.mpeg