My share of shower insights: power to the artists!

KDE4 has made revolutionary changes in UI architecture, there is no doubt about that. But I can't shake the feeling that, while you can certainly see big advantages this brings to applications, all those KDE4 pillars aren't leveraged nearly as much as could be, in principle, possible.

Take Plasma, for example. The decoupling of logic and presentation into engines and plasmoids is perhaps the most powerful single idea implemented there. But what I see as the greatest opportunity it creates is left untaken: the decoupling makes it possible, in principle, for the artists to design plasmoids entirely by themselves.

Indeed, the simplest Plasma applets do nothing that couldn't be trivially designed graphically: see my own RSIBreak plasmoid (a simplistic prototype yet, sorry) for example. Yet, we still have the situation that the presentation logic is written in a programming language; even if it isn't C++ but something more human-friendly, such as Ruby or Python (having said that, I have yet to see a single useful plasmoid written in one of those) it still leaves out many if not most of the people that could design them on the mercy of developers, who often have more interesting things to do than code trivial UI handling code.

Even the more complicated applets, see the clock for example (you can't talk about Plasma without mentioning the clocks, can you?), could be done entirely in a language designers already know (even if not directly)—SVG. SVG is expressive enough to do every operation that is currently done in C++ code of analog clock plasmoid. But how to program graphically what operations map to which inputs? Why, telling by showing, of course:

The problem with current architecture is that we cannot easily modify SVG tree programatically, so we end up with having to use two languages to describe the interface: SVG for the static parts and C++/whatever for the dynamic behaviour and coupling with the engine. But, IMHO, most plasmoids' presentation could be described just by a smart mapping from engine data to SVG properties.

So, what do we need? What is teh masterplan? Well, first we have to have a framework in place—that's the easy part. First of all, we need a widget that is able to draw an SVG tree that we can modify. Then we need to devise language to describe mapping of inputs to SVG transformation—I'm pretty sure that existing SVG infrastructure for animation is well adaptable to that task. After that, it's just a matter of wrapping the mutable SVG widget with another one that draws the graphic transformed according to the transformation given input data.

The harder part would be making the "tell by showing" interface for the artists—but even without that, this approach has a whole host of benefits. Making a new plasmoid (using an existing data engine) would be just a matter of drawing it and coupling it to the inputs using a description—not programming—language.

This would enable theme designers to alter widgets' look completely—they would no longer be constrained by whatever design the programmer had in mind while writing the code; so that, for example, one theme could show, say, CPU temperature as a bar, while another could use VU-like meters, all that without changing a single line of code—without any additional code at all, in fact!

I'll confess that I'm largely inspired in this idea by Bret Victor whose paper Magic Ink: Information Software and the Graphical Interface I have once read and which sits in my head since and transpires to my consciousness from time to time. You should really read it in its entirety—it's full of innovative, revolutionary ideas and I feel that, with KDE4, for the first time in the history of computer user interfaces, implementing those ideas is finally feasible.