Aaron, Sandro, moofang, Shantanu and Diego have been hacking up a Plasma storm lately on the Javascript bindings for Plasma and the Plasmate builder tool. Since good code is running code, and running code is a lot easier when somebody else builds it and packages it, I've updated the Plasmate packages in KDE:KDE4:Playground to 0.1alpha2 and have updated the javascript bindings in our KDE SC 4.4.1 packages to include Aaron's latest errata - no need to update yourselves.

So it's even easier to take part in the Plasma Javascript Jam Session competition now.

And while you're at it, how about completing the loop by using our kde-obs-generator to package your plasmoids and make them available on kde-look.org, so others can start to download and improve them directly in Plasmate? Free Software virtuous circle FTW!

I noticed yesterday that at the kde-apps.org page for WMIface, a tool that allowed scripting the window manager used by KDE3 from command line, a comment appeared asking about a version for KDE4. It felt like a good idea to do something as simple as this in the evening as a relaxation, so, after quite some time playing with C++ templates and so on (since I'm a lazy developer and therefore I went with doing some extra work that would save me from doing work), I have to disappoint you. There is no version specifically for KDE4. In order to reduce the dependencies I made it depend on just QtCore and X11 libs, with those few important classes from kdeui copied into the project. No KDE dependency whatsoever. This provides the CLI tool with startup time decent enough for direct usage, and makes it usable on every system, KDE, GNOME, Xfce, whatever.

PS: The possibility of the much more powerful scripting in KWin itself is still there for anybody interested enough to do it.
PPS: Anybody who ignores the kdeui classes for window management and uses this user scripting tool from an application will be tarred, feathered and publicly laughed at. You've been warned.
PPPS: Every decent system, that is - anything that has QtCore and a reasonably wm-spec-compatible window manager.

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

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:

• pool all the design documentation there is on SystemSettings
• track the state of the main app
• track the states of all the modules
• decide what to do about the missing modules

This last point is important. I count 63 distinct modules in KControl in KDE 3.5.8 on openSUSE 10.3 but there are only 30 present in some form in KDE 4's System Settings. I saw somewhere that System Settings was intended to be the 'basic' config and that advanced users should user KControl, but that is no longer possible in KDE 4. So we need to find some homes for those other modules. It has already been decided that some of them should only appear in the relevant apps (all the web browsing config stays in Konqueror), but a lot of them are only visible using kcmshell4 --list.

I also went through the (few) bug reports vs KDE4 System Settings, closed a bunch that were obviously fixed, and set the right versions on the rest. Please use bugs.kde.org for KDE 4 bugs!

As well as sorting out the shell, though, another challenge we face is getting the actual config modules sorted out and well ported to KDE 4. I realised this when creating components for system settings for each KCModule. The list of default owners for bugs on these components reads like a Who's Who of KDE Past - a lot of big names there but most of whom have left active development. This is the biggest part of the job and it's more than one person can handle. But fortunately KCModule work is a relatively easy way to start KDE 4 coding. The scope is well defined and the architecture is relatively simple. So, if you would like to find a way into KDE development, consider helping making System Settings as cool as it promises to be.

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!

The other evening I was looking to play around with QScript. I have done a handful of JavaScript and know that there are a number of very interesting features that the language possesses. I have also been looking to hack on a Genetic Algorithm project. Putting the two together I made a Genetic Algorithm example written in JavaScript. It was quite a lot of fun to make and is quite a small amount of code in the end. I included an example that tries to find the shortest path between a set of points (the travelling salesman problem). You are free to type in any problem you want and it will attempt to solve it with the genetic algorithm. After it runs it will generate a graph showing the progress as its gets a better and better solution (using the canvas tag, sorry it doesn't work in Konq 3.x). And it will paint the final solution that it finds to the problem. Although it ended up being a little website rather then a Qt app it was fun learning more JavaScript and more about GA's. If you are interested in learning about GA's I have a number of links including some to Google books at the bottom.

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.

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

one of the main widgets we will have on raptor is the sliderview. it's a very customizable view unlike on kickoff, where it slides left and right, Raptor Slider View is meant to be 100% compatible with Plasma API and not be some widget of it's own. it's very similar to what u would see on a slide show but multiple slides per view. arrangement can differ based on user perf, It will support Stack like view and Grid view just like it was proposed on Appeal Project first by Aaron . the view can be skinned using SVG. at the moment i'm working with pinheiro (Amazing Oxygen Artist) and Nookie (good old Buddy) on the skin elements soon we will get the skin perfect and done. I uploaded a mpeg to ruphy's upload server so if can't compile it. see it here http://upload.ruphy.org/slideicons.mpeg. next step is to float it on plasma and add the True Transparency support to the menu view launcher. that should happen in few days from now.

Well, I'm back from Glasgow and have now almost recovered. The conference was great, and I'd like to thank all the organising team for their efforts. For me things were quite productive, with some nice steps forward in my QtScript code (my bindings are now dynamically loaded plugins for example) and lots of useful discussions about topics from improving the library facilities for scripts. I also managed to make a start on a plasma applet container that lets you write applets in Javascript.

Isn't it nice to be able to blog again

EDIT: I forgot to say, my slides and the video of my talk are online now if anyone wants to see them.

read more