[Kst] kdeextragear-2/kst

[George Staikos]

On Sunday 18 May 2003 16:05, C. Barth Netterfield wrote:
> On Thursday 15 May 2003 10:45 pm, George Staikos wrote:
> > +Move the graphing engine into a separate library
>
> Lets talk - but I will think about it.  Right now, KstPlot assumes we have
> KstCurves to plot....  KstCurves have KstVectors....   etc...
>
> > +- use signals instead of asking KstDoc to do everything
>
> Are you talking about doc->update() calling everyone elses ->update()?  If

   That's definitely one case.

> so, this should be easy to do, but does it actually make things easier to
> understand?  In particular, will it help us with dependancies? (hmm... it
> just might...)

   Yes it should be easy.  I think it does make it easier to work with.  As 
you add new things to kst, you can just plugin them into the signal instead 
of having to edit kstdoc each time.

> > +- cleanup inheritence of curves/vectors/etc
>
> Yes in general, but what do you mean in particular?

  I think we can find some commonality between these things and factor it into 
a common base class.  I bet we could remove as much as a hundred lines of 
code from KST like this.

> > +- make naming schemes consistent
>
> Yes.

  Do you want to continue with the existing scheme (and document it for 
developers), or would you prefer to adopt the Qt/KDE scheme?

> > +- add more accessor methods
>
> What do you mean in particular

  There are lots of places (especially in my plugin code right now) where 
member variables are directly accessed.  I think it's a good idea to add 
methods to access these variables instead.  They're free if they're inlined, 
and they make it easier to change the code in the future..

> > +- cleanup main()
>
> I've tried, but it has resisted me in the past. It is just dealing with the
> command line options, and that tends to be pretty messy with a 'rich' set
> of command line options like we have.

  I was thinking about making a class to hold this stuff if possible.  This is 
more of a long-term goal, nothing immediately pressing.  It works as it is.

> > +- cleanup kstdoc and kstapp to make things more modular
>
> I have had a little queasyness about the structure here, but what exactly
> do you mean?

   This goes together with the signals idea above.  Basically there is an app 
here that has lots of "modules" which are hardcoded.  it would be nice to 
make them more self contained and let them just "plug" into the document or 
app as needed.  This would pull more code out of the monolithic portions of 
the app and move them into the respective modules.  A base class could be 
created to hold common parts if it is suitable.  These modules could even 
plug their own actions into the gui I think.


-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/