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
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________ Ktechlab-devel mailing list Ktechlab-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
