[Kst] Plugin updates
netterfield at astro.utoronto.ca
Thu Jul 8 01:55:23 CEST 2004
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.
> 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
> 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.
More information about the Kst