[Kst] Re: Plugin Interface

Barth Netterfield netterfield at astro.utoronto.ca
Tue Feb 17 20:54:46 CET 2004


I was looking at the fantastic collection of plugins which have developed...

One change to the interface which might be nice is to be able to mark some IO 
fields as optional.... 

for example, one may only want some of the many scalars from the stats plugin, 
or may only want slope, intercept, and the line in the line fit, etc.

From an GUI point of view, any fields you don't enter names for don't get 
created as scalars/vectors in the lists....

This could be a huge usability improvement.

cbn

On February 17, 2004 02:35 pm, Andrew Walker wrote:
> Hi George,
>
> I'm pretty happy with the interface as is now. My only complaint
> would be when returing a large number of scalars. To my mind it
> doesn't make sense to have the user enter a long list of scalar
> names, so I typically return a lot of scalar values in a single
> vector. This isn't ideal from the user's point of view, but
> neither is the alternative.
>
> Andrew
>
> ---------- Original Message ----------------------------------
> From: George Staikos <staikos at kde.org>
> Date:  Mon, 16 Feb 2004 17:46:48 -0500
>
> >   Barth and I discussed the idea of moving the plugin system to use
> > variable arguments as proposed by Jean Marc and Claude.  While it does
> > sound nice, there is one problem that we think might negate the value of
> > this.  Plugins [can] resize vectors, and they have to pass back the size
> > of the vector to Kst so it knows if it has been reallocated.  Kst tracks
> > the size of vectors, so it needs this information.  Plugins also need to
> > know the size of incoming vectors.  The solution that I can think of
> > would look like this:
> >
> >int myPlug(double *array1, int insize1, double *array2, int insize2,
> > double scalar1, double **output1, int *size1, double **output2, int
> > *size2, void **local);
> >
> >The size arguments above make this format almost as much of a pain as the
> > old interface.  Is there a better solution?  Is this solution enough
> > added value to justify breaking all existing plugins?
> >
> >   Andrew: What do you think of the interface right now, and what do you
> > think would be better?
> >
> >   In addition, do you think it would be useful to have "constructors" and
> >"destructors" for plugins?  For instance, there could be two symbols in
> >each .so that are used for this, say "create()" and "destroy()".  This
> > could also be specified in the XML file if you want different names.
> >
> >   What are your thoughts?
> >
> >--
> >George Staikos
> >KDE Developer				http://www.kde.org/
> >Staikos Computing Services Inc.		http://www.staikos.net/
>
> ____________________________________________________________
> Free 20 MB Bannerless Domain Hosting, 1000 MB Data Transfer
> 10 Personalized POP and Web E-mail Accounts, and more.
> Get It Now At www.doteasy.com
>
>
>
> _______________________________________________
> Kst mailing list
> Kst at kde.org
> https://mail.kde.org/mailman/listinfo/kst



More information about the Kst mailing list