[Kst] Plugin updates

[Barth Netterfield]

On July 7, 2004 06:28 pm, George Staikos wrote:
>   Clearly there is a problem where plugin updates are called far too often
> right now, causing high CPU usage.  However, I think we have to be careful
> about how conservative we are in updates.  If we only update when input
> vectors have updated, then plugins can't use any external sources of
> information.  They may also have updated, and if we don't call update, then 
> the plugin remains stale.  Any thoughts on how this should work?  

The system we have has assumed that updates only happen in response to new 
data source data, or to dialog induced vector changes.  Let' stick with that 
for now (effectively saying plugins are not a source for real time updates).

When we want to add the ability for plugins to generate new internally 
motovated data, we could add a method by which we can ask them if they want 
to trigger an update.  Virtually all plugins would always reply 'no'.  The 
ones that want to trigger can say 'oui'.

IIRC, any new data generates a full update of everyone.  This would happen 
here too.  Ie, we query all of the data sources and all of the plugins to see 
if they want to generate an update.  If 1 or more do, then everyone gets 
updated, as now.

ie, 
> 3) ask the plugin if it wants to be updated
> 	problem: breaks out of the plugin definition as we try to conform to it

Real problem.... Can we add optional methods?  

> 	problem: insufficient - it won't know if a scalar or vector has been
> updated so we need to combine this with 1) or 2) at least

Not a problem I think.  Currently, vectors and scalars only change if i) a 
data source changes or ii) there is user input from a dialog.  Now we will 
add iii) a plugin generates is own internally motivated changes.  A change 
motivated by a change in an input will have already have generated a full 
update anyway.

> It's not an easy problem.  I was wondering, what if we actually add another
> layer in here?

Ack.  No more layers..... (emotional response from a C coder at heart)

> ---------------------------
> XML+C plugin|
> -----------------
> Kst Data Plugin
> 	C++ + desktop file
> ---------------------------
>
> This greatly simplifies things internally I think.  

under some definitiions of 'simplify' :-)

> We would provide an API 
> and tools for plugin authors to write wrappers for their XML+C plugin which
> can do all the hard things we try [but fail] to do now.