RFC: scripting support changes

[Aaron J. Seigo]

On Wednesday 23 January 2008, Sebastian Sauer wrote:
> I know that I did promise to don't reply on that topic anymore, but maybe
> it's wise to break that promise now ;)
>
> Aaron J. Seigo wrote:
> > attached is a patch that implements a number of changes to ScriptEngine.
> > i'm posting it for comments here.
>
> +    virtual void paintInterface(QPainter* painter,
> +            const QStyleOptionGraphicsItem* option,
> +            const QRect &contentsRect);
>
> imho this shows a fundamental design-problem and is the reason why the

not at all. paintInterface is simply the interface between libplasma and the 
scripting support. the script implementation can do what ever it wishes 
behind this call.

> QtScript backend was needing >=30% CPU on my rather new+fast system last

30% cpu .. what were you running exactly? it would be good to track down where 
the issues are, but that means knowing what you were running.

> The reason is, that SK is very clever in trying to prevent to call a
> script(-function). So, rather then forward each paint-request to a script
> imho the much better way would be to do it like SK does;

> 1. A script does setup the elements it likes to display (SVG, buttons,
> widgets, bars, etc.) only once at a init-function while still allowing
> somehow to change elements on request also at a later stage. SK is here
> even such clever that it's possible to write complex dynamic karamba's by
> just using that single init-call while all other dynamic things are already
> defined there and therefore there is no future interaction with the
> scripting-backend(s) needed at all.

this is also completely possible. if i create a plasmoid that uses the 
standard widgets and what not (labels, buttons, etc), i don't need to do 
*anything* in my script w/regards to painting.

with Plasma::Icon supporting svg soures now, we even have a out-of-script 
method for placing an svg at a certain point in your plasmoid.

> 2. If there is the need to update parts like e.g. change an image if a
> button got clicked, then only do this if the button got clicked.

no difference here either.

> 3. If there is a need to e.g. update a bar/statusprogress/whatever then
> allow to define intervals in which this is done (e.g. once per second).

this is also the same, perhaps taken even further thanks to the 
engine/visualization split.

> 4. provide elements that are optimized for scripting what means, that a
> script should be able to define e.g. what happens if a buttonimage got
> pressed (e.g. something like a one-time; if btn1-area is pressed, change
> svg1 to svg2). While for buttons this may not really an issue it's imho
> essential for progress-/statusbar like widgets which are updated on a
> regular basis. 

we provide standardized versions of these widgets in libplasma already. the 
script does not need to paint them at all. if there are specific methods 
missing in the standard widgets that scripters would like to see, we can 
certainly add on to them.

> 5. paint is one of the most expensive operations that could 
> be passed on to a script and imho this shouldn't be forwarded to a script
> at all. Even caching the painted device a defined time would still result
> in overhead.

not being able to paint from a widget as at least an option is too limiting. 
one should not be required to do painting in the script, but honestly: for 
the number of times this method gets called, and the fact that all painting 
happens in the C++ libs ... neutering the support like this would be unwise.

> All in all, I guess it wouldn't be wise to provide the same Plasma C++
> interfaces as script-interfaces through I agree that this sounds sucking
> and is additional work++ (though for DataEngine iirc this is already done).

this statement is not really accurate.

a) you're confusing the ScriptEngine API with the API that gets presented to 
the script itself. the two are not meant to be 1:1. doing it this way allows 
us flexibility in how we do scripting support by not having any assumptions 
in libplasma about this. hell, you could probably port superkaramba to this 
system and provide .desktop files with X-Plasma-Language=superkaramba in them 
and it would Just Work(tm)

b) the engine/visualization split was done specifically for this reason, the 
number of widgets we have in libplasma such as meters, etc are also there for 
the same reason. you pick a widget, you connect it to a data source, voila, 
done. no painting necessary.

perhaps this just isn't clear enough when looking at the various APIs, but i 
really don't think the issue you are concerned about is either real or valid.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080124/17bce9cf/attachment.pgp