[K3d-development] CVS release notes 11/29

[Timothy M. S. <ts...@k-...>]

* Lots of work with sigc++ and undo/redo.  This probably won't fix 
anything in particular (yet), but ideally you shouldn't notice any new 
problems, either :)

To give y'all some background: most of what's going on within K-3D 
design-wise is very solid, and very mature.  The two major areas of 
instability are the event system, and undo/redo.

The event system is a generic implementation of observer design pattern. 
  It works OK, but is inefficient, type-unsafe, and (especially) does 
nothing to ameliorate the fundamental problem of observer design 
pattern, which is proper cleanup when either subject or observer objects 
are destroyed.  sigc++ solves all of these issues brilliantly - so 
switching over has eliminated a couple of known-crashes already, and 
will undoubtedly eliminate many more hard-to-duplicate problems, as well.

In most respects undo/redo is where it needs to be - the one design 
problem is that, for every modification the user makes, there's an 
initial state, zero-or-more intermediate states, and an end-state.  You 
want the undo/redo system to record the initial and end states and skip 
the intermediate stuff.  Keeping track of which states are intermediate 
and which aren't is a little tricky, and the current design requires 
inhumanly-perfect coding to work.  Since software is written by humans, 
this doesn't happen too often.  The good news is that I have a nifty, 
clean replacement for this part of the design, which is what I'm putting 
in place a step-at-a-time.  Interestingly, the replacement also uses 
sigc++, so we owe the sigc++ folks a *big* debt of gratitude.

Bottom line: plan on seeing lots of changes with minor-to-moderate 
improvement up front, then big improvements in stability once the bulk 
of the code has been upgraded.

* Began adding tutorials to the regression test suite, since they cover 
a *lot* of ground.

* Embedded the software version in Doxygen, to keep y'rs truly straight.

* Changed the version to "0.2.0.0" - I'll be incrementing the last 
number as I go, and calling it a "build" number.  I realize that this is 
suboptimal, since 0.2 implies a level of stability that we don't really 
have yet, but we can't go back and we need *something* to keep everyone 
in sync as we move forward.

Cheers,
Tim