How much functionality should bindings expose to plasmoid developers?


It should be possible for anyone to develop plasmoids. Therefore script bindings should not expose too much API, instead concentrating on offering basic functionality in an as easy as possible manner.

Original Text

Aaron Seigo

this is a fundamental misunderstanding of how Plasmoid scripting should really happen.

the goal is NOT to provide a complete set of bindings for scripts to go crazy with. why? because that would make it nearly impossible for *average* people to write things. hell, we may as well ask them to go off and learn a "real" language at that point.

no, the goal is provide a very well contained and *small* API that is not a 1:1 mapping to all the power and glory that is Qt and C++ and the rest of the world, but a simplified API. ever wonder why i spent so much time doing DataEngine which is simply a shim between plasma components and *real* data models? yeah, because *real* data models are too varied and too complex; they would require tons of bindings all over the place and tons of explanation to the plasmoid writer.

instead we have one little set of api (essentially 2 functions, from a script's perspective) that opens the whole world of data to them.

while your perspective is correct from a general language bindings perspective, one needs to start thinking in terms of consumer development environment (not programmer developer environment) and the general goals of plasma to get this right in the context of plasma.


panel-devel archive (2008-02)

Who is the target audience for scripting in plasma?


Plasma needs to cater to experienced widget designers as well as people, who like tinkering with their environment. To facilitate both of these groups, plasma should expose more than one scripting API per language.

Read Aaron's detailed description from which the text below is quoted.

Original Text

Aaron Seigo

With Plasma scripting, I see three audiences: libplasma, ninjas and myspacers. [...]

libplasma itself needs to have a way to work with the scripting that isn't an afterthought or some transparent magical loading of scripts. The scripting interface needs to be purposeful, manageable, integrated with other parts of libplasma and possible to be made safe. [...]

Ninjas are people who are awesome at what they do. [...] there are likely to be few widget making ninjas out there, relative to the size of the audience. Fortunately, they make awesome stuff that most of the user audience will want to pick up on.

By opening up Plasma to other widget systems such as SuperKaramba and MacOS Dashboard we widen our ninja audience. This is one reason having "libplasma" as an audience is so important.

However, we want Plasma Ninjas too. [...] they need a powerful API. I think they also will probably want a design studio [...] we want to give these ninjas the ability to do much of what you could in C++, only faster, slicker and with fewer stupid details.

myspacers. That's my pet term for the kind of people who glom onto sites that let you easily modify an interface with a little bit of work. They looooove tinkering but their skill level is pretty low. They also tend not to create things very often that many other people would want to use. However, there are a lot of them.

What do the myspacers need? A stupidly simple API, and certainly a point and clicky designy thingy. Making a simple clicky designy thingy (a toy level design studio) requires a really simple API; [...]

The value in the myspacer crowd is that they make products popular. [...]

To optimize a widget system for one group will cut out the other one due to skill differences; either you'll get something too complex for the myspacers or too limiting and toy-like for the ninjas. Or worse, the API will cater to a group somewhere in the middle and instead of maximizing the audience the API will guarantee a minimizing. [...]

I don't know if there is just one solution per say, but here's mine: we're going to have two different kinds of APIs. One for ninjas. One for myspacers. Plasma's design allows for that, even using the same programming language for both since we differentiate based on target API not implementation language.


aseigo's blog

This page was last edited on 2 May 2008, at 08:24. Content is available under Creative Commons License SA 4.0 unless otherwise noted.