[Ktechlab-devel] New guy <--

[P Zoltan]

On Fri, 07 Nov 2008 01:59:32 +0100, Alan Grimes <agrimes at speakeasy.net>  
wrote:

>
> here's the biggest bug I'm seeing on my machine...
> I have this simulation of my father's Harman Kardon 430 (from 1974)...
> The amp works (even though it doesn't seem to for the first few
> minutes... the real amp takes about 30 seconds for the input
> differential amp to un-clamp... =\
> the problem is when I go to save it and load it, the entire circuit is
> messed up. 2/3rds of the connectors are gone, there are a lot of
> dangling junctions.... Undo/redo creates a similar effect. The problem
> must be in the document heirarchy, It's all based on QT's DOM/XML engine.

  I'm having the same problem. Something is messed-up with se save-load  
(and the undo-redo?) classes. I didn't want to touch those in refactoring,  
because there are chanses of breaking the file structure -- that would be  
really annoying.
  Anyway, the save-load should be changed, because:
- it's not extensible; there is no file-format versioning support.
- it's hard to mantain: the load-save mechanism contains some "data"  
classes, which must be in sync with the internal data strctures.
(- the generated XML sucks, imho :P)
  My opinion is that the code responsible for loading and saving existing  
file format should be separated in some classes; the objects (connectors,  
nodes, ...) should be able to load and save their states in some text; the  
versioning can be done by creating converters between the actual format  
and the (possibly older) other version; the conversion between document  
format should not be done in the components.
  The loading of a circuit could be something like this:
- enumerat the existing known file format versions
- open the file, get the version info
- choose the appropriate parser for that version
- that parser knows the file structure; for each contained object, calls  
the corresponding object's interface/constructor, for instance:
   var = new SomeComponent(XML_description_string);
  Opinions?

  I also found the following problems:
- an infinite loop in LogicProbeData::findPos(). When the 'time' parameter  
is out of the range of the probe, the program gets stuck with top ==  
bottom +1 == 1; The question is how to fix it in an 'elegant' way?
- in a circuit I managed to make the digital clock to _stop_ after a few  
cycles. I don't know why (yet?).

  Zoltan