RFC: scripting support changes

Sebastian Sauer mail at dipe.org
Thu Jan 24 02:53:03 CET 2008


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 
QtScript backend was needing >=30% CPU on my rather new+fast system last time 
I give it a try compared to SuperKaramba where 2 instances of the rather 
complex AIO-karamba takes here <5%.

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.
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.
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).
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.
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.

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).


More information about the Panel-devel mailing list