RFC: scripting support changes

[Sebastian Sauer]

On Thursday 24 January 2008, Aaron J. Seigo wrote:
> 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.

What lead me to look more detailed at the hashboard-documentation and guess I 
understand now why it's done that way. Thanks for the hint :)

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

Just a kde4-session with the on QtScript backend. I assume that the 
QtRuby-plasma implementation would have the same problem but can't test it 
atm since it doesn't build against the current/4.1 sources :-/
My test was done a few months back (so, before 4.0.0) and oprofile showed that 
paint was the problem since it got called just very often and does need to do 
quit a lot of things on each of the calls.

Anyway, guess if the goal is to provide for !=webkit an own 'rendering engine' 
then that isn't of interest anyway except for those that like to do !=webkit 
backends (what the scriptingengine is about, or?).

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

bar's too? I just looked at them for the KMLDonkey plasma-applet and did note 
that there was no bar-like widget available. Anyway, if the goal is to use 
Qt4.4 QWidget's then we have it for sure.

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

ah, ok. So, the current on QtScript based impl (and those based on QtRuby) is 
just outdated then. Thanks for that orientation.

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

y. I don't mean to don't allow that but rather have this only there for the 
case nothing else is possible.
The problem here is, that the function just got called very often and that the 
scripting function does need to repaint _everything_ on each call.

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

I guess it is and imho you verified that !=webkit may need 
additional "backend-functionality" here though I understand that this has 
less priority. Anyway, I just did provide some feedback on what I did note on 
my try to deal with the current (applet-)API via scripting as asked :)

> 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)
> behind this call.

uhm. iirc that's exactly how the SK-plasma applet works atm (except that we 
don't use plasma desktop-files cause of backward-compatibility) but I assumed 
that it's not an option to suggest to just push SK as official !=webkit API 
here.

imho I mainly mixed here 2 cases;
1. our past mails that it's better to provide one (!=webkit) solution for 
alternates direct within plasma. So, whatever !=webkit solution shows up is 
able to use and provide the same interfaces to scripts and doesn't need to 
reinvent the wheel again and again and
2. that together with your "But that doesn't change the requirment to the 
script implementation can do what ever it wishes" above means, that it's 
maybe wise to talk about this as early as possible what my last mail tried to 
achieve by providing some feedback about my point of view where the problem 
is located and why I aborted the scriptengine (as in applet scripting API 
what is !=dataengine API) I wrote so far.

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

nah. I only talked about the visualization part since dataengine works quit 
well + it's the same way SK works anyway through there it's named sensors 
rather then dataengine's and meters rather then (visualisation-)widgets.

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

y, maybe not at this point (aka not before Qt 4.4 wqith it's alien widgets is 
used). But at least I did provide feedback about the problems I had with the 
applet scripting-API so far.
Thanks for taking the time to reply and pointing me indirect to the 
dashboard-documentation :)