[Ktechlab-devel] More on Document / Simulator interface

[Julian Bäume]

On Sunday 03 January 2010 06:08:43 Alan Grimes wrote:
> P Zoltan wrote:
> >   Here is some code, describing the interfaces between the simulator and
> > 
> > document:
> >   http://sourceforge.net/userapps/trac/zoltan_padrah/wiki/KtechlabDocumen
> >   tProposed
> >   
> >   We should discuss about it. There are some fixme-s and todo-s, too.
> 
> I don't understand what that source code is for. It looks somewhat dated
> in its design pattern, a number of things I've straightened up already
> in SVN.
>
> Furthermore, I'm becoming increasingly distressed by the move away from
> the Document family and tree of classes.
> 
> One of the things that makes ktechlab work so great is that everything
> is unified into a single class heirarchy. All documents, both text and
> graphical are instances of class Document. All graphical documents are
> instances of class ItemDocument, all documents that feature connectors
> between components are of class ICNdocument, etc...
This is not the intention of doing this. The recent API really has some design 
flaws. I just had a look into the header files for ItemDocument and 
ICNDocument. There is ItemView and ICNView, why do I see methods like:
QCanvasItem* ItemDocument::itemAtTop(const QPoint &pos) const
defined there? This is just one random example. The purpose of what we are 
doing here is to redefine the API needed for the View to get all necessary 
data from the simulator and update the Model (and inform the simulator) about 
interactive changes done by the user. What these classes should not do, is to 
interfere with the view or returning stuff, the view takes care of. This is, 
why we are working on that.

> The apparent rush to implement the functionality of the child classes
> without respect for the over-arching architecture of the application is
> bound to be a disaster!!! =(((
>
> It's great to extend this with project management and other good
> features, but the unifying class hierarchy is indispensible! =(
I don't want to loose the unified architecture. In the end everything will 
stay a Document. What I want to do is to remove responsibilities from these 
classes. Why should the Document care about which Items can be connected and 
which don't? Why should it care, where Items are painted in the Scene.

> I don't mind if we use someone else's Document class, but you'll need a
> VERY good argument that the alternative is better.
KDevPlatforms Document class just extends our Document classes and renders 
some functionality, we have now, obsolete, while other parts need to be 
modified, slightly. All in all, it should just be less code to be maintained 
by us.

I believe, you won't miss any functionality, after this process is finished.

> Another thing that needs to be understood is exactly what the simulator
> is, and what it does. In the not too distant past, I have done some
> massive overhauls to that class so there is no good excuse not to
> understand it!!! =|
>
> [...]
> 
> But the short story of it is that the simulator's only real job is to
> create a concept of time for all the other classes which exist within
> the simuation.
Thanks for that introduction, that made some things more clear to me.

> Also: I think I finally have a handle on why the super-critical
> nonlinear and Diode classes aren't working. While I wait for my contract
> to be renewed I might have a little (hopefully not too much!) time to
> attempt to implement my newfound solutions.
That sounds nice, please keep us posted.

bye then
julian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/ktechlab-devel/attachments/20100103/36346a83/attachment.sig>