[Kst] 0.99 Plans

[George Staikos]

On Thursday 15 July 2004 13:42, Barth Netterfield wrote:
> Except for some bugs, 0.98 is looking pretty good.  I wanted to start a
> discussion on our plans for the near future.  Here is what I propose:

   Most of which are fixed now, right?

> 0.99 will be a (mostly?) feature complete curve plotting system, and
> should be considered almost like an RC for 1.0.  Plank-HFI and
> BLAST will both be needing it soon (as in already).

   I agree (to all points :)).

> Feature Policy: Any features we want to add before 1.0 (September) need
> to be added now.  BUT: If you are going to add something semi-big, discuss
> your plan on the list before you start into it, so we don't end up
> having to make drastic changes later.

    I was thinking about this policy earlier this week too.  We definitely 
have to do this if we want to see stability at some point.  Now, do we want 
to branch CVS into "stable" and "head"?

> Certain areas should not be hacked without first bouncing it off of the
> section's maintainer (discussion on the list is the best):  For section
> maintainers, I propose
>   -Updates and class structures, lists, globals, threads: George

   Seems reasonable to me.  I guess this implicitly includes packaging, build 
system, release coordination, etc too.  "release dude" :)

>   -Filters, Fits, Elog, Events: Andrew
>   -Dialogs: Barth

   And plotting algorithm?

>   -New Features: The List
> If someone bounces something, !respond!.  If no one responds, mods are
> fair game.  When it doubt, bounce the idea, or explain what you did when
> you submit and be prepared for a reversion or fixes if there are issues.

   Yes we really need to make sure that new features, especially those that 
require design changes, get discussed on the list in order to avoid rewriting 
code.

> Date: ASAP.  No later than Aug 15.  This would leave 2 weeks for
> features, and 2 weeks polishing.

    Ok, I'm basically unavailable for 2-3 weeks as of Aug 19.  That gives 4 
days of slip.

> -Filter sets	(George to (re)write the class; UI TBD)

   class design depends on our "philosophy" here so I won't touch it until we 
have a plan written out.

> o create a database system for constants
> 	 (The current list of constants is useful rarely, but not
> 	 never: one needs to be able to turn them off, or add new ones)

   Yes, I was going to hook this into a KDE so we might be able to share this 
with other apps too.  I think it could be useful in many places (KCalc, 
KSpread, KStars, to name a few....)

> o vector defaults should be keyed to $PWD and stored as a map
>   (This needs to be thought about first...)

   Yes we have lots of problems here.

> - Kst Settings reportedly don't work (can someone explain?)

   Colours are almost in place, but does the update timer work again?  If so, 
we can make this more specific now.

> - locking is missing in places - especially dialogs (plugin, etc) (Can
> 	  George verify this?)

   George can verify this is broken.

> - Deleting a window doesn't properly delete plots, leading to orphaned
> objects.

   I think it does properly delete them.  The problem is that the reference 
counting is not quite in "sync".  This one needs much more investigation.

> - invalid memory accesses on closing the data wizard - Qt bug?

   I've spent hours on this one today and it seems to be related to the 
embedded file dialog changes.  I'm getting tired of chasing this one and I 
think we should consider not messing with the layout and just using a .ui 
file.

> - flicker was reintroduced (see layout mode for an example)

   Still no response on this one.  I know that the commit that triggered it 
happened on either Tuesday or Wednesday though.

> o the common implemented functionality for data dialogs may need a rethink
> - it's impossible to override behaviour of functions (Please Explain)  

  We had discussed making a common base class with a Designer plugin....

> o deleting a piolib database crashes kst (George - on hold until piolib
> works) - More bugs are at bugs.kde.

   I think I should be able to tackle this one again, though I may have fixed 
it already as a side effect of some other fixes.

> o The kdeextragear build system makes 3.1 compat hard/problem prone.

   I can build a new system for kdeextragear if you think it's worth it.  I 
tried to fight this change but was overruled.

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