[Kst] extragear/graphics/kst/devel-docs

[Barth Netterfield]

Agreed.  See my other note on schedule/time distribution issues.

cbn

On December 9, 2005 10:38 am, Ted Kisner wrote:
> It seems to me (and this is just my opinion) that Kst2DPlot is a classic
> case of code where (important and essential) features were added at random
> without an overall design goal.
>
> Personally, I think we should do as little as possible to these files until
> 1.2 is released- even if it means reducing release criterion.  Then we
> should just scrap it and do a wholesale refactoring of Kst2DPlot.  Note I'm
> not suggesting getting rid of features:
>
> 1.  Make a list of all the features we can imagine kst ever supporting in
> terms of display.  Obviously we can't predict everything, but I think we
> can see 2-3 years into the future.
>
> 2.  Come up with a *detailed* design document where we completely specify
> all the objects to implement the funtionality we want.  Personally, I like
> to design things down to the level of specifying exactly the member
> variables, and the API of all member functions.  Most problems should
> become apparent at this point.  At this stage we should be able to
> visualize how all the display elements interact.  If we can't "see" how all
> the pieces fit/work together, then our design is not complete.  Off the top
> of my head, I can think of several objects that Kst2DPlot could be broken
> down into:
>
> a) 2Dplot becomes a container object that coordinates the things below
> b) renderer object
> c) axis interpretation object (time, others in the future)
> d) mouse handling object
>
> 3.  There is no point to write any code until our design is complete.  In
> fact it is worse than pointless as it means we have to backpedal later.  If
> the design is complete, then we can just copy/paste any relevant
> implementation code from the current Kst2DPlot and fill in any gaps with
> new code.
>
> Anyway, I'll try to help out whatever path we go down, but I think that
> everyone's time could be used more efficiently if we had a new detailed
> design.  I would say that coming up with a good design is 90% of the work.
> The other 10% is some easy coding and performance tuning.
>
> Less coding, more design.
>
> my $0.02,
>
> -Ted
>
> _______________________________________________
> Kst mailing list
> Kst at kde.org
> https://mail.kde.org/mailman/listinfo/kst