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