On Monday 22 September 2008 15:16:59 P Zoltan wrote: > On Mon, 22 Sep 2008 04:34:32 +0200, Alan Grimes <[EMAIL PROTECTED]> > > wrote: > > Today I tried moving from the custom Canvas.h header to the standard > > qcanvas.h header. This caused a lot of undesirable behavior changes, > > namely the "infinite plane" workspace concept stopped working -- > > circuits were cut off at coords 0,0; And the code wasn't able to update > > the wires when new connections were made or parts were moved. > > > > What in god's name did David do to Qcanvas and can it be ported back > > into the standard tree so that we're not maintaining a ton of > > trolltech's code along with our own? > > > > Someone mentioned that he was working on a QT4 port, how is that going? > > Julian Bäume is working on it. > > Supposing that the canvas-related code works, don't bother fixing it. It > should be simpy redesigned and rewritten in the qt4 porting process.
You are right, for now the best way to go is to leave all GUI-related code as it is. If you break something, let me know, I'll help fixing it in trunk. At the moment I'm working on DocumentManager and ProjectManager classes to remove all GUI code from it. I want to create a light-wight project with an CircuitICNDocument to use it as the data for a model to visualize it in a Plasmaoid (or QGraphicsView, what is basically the same -- I'm going to test, what fits best). I'm currently working on an own branch that doesn't compile, yet, so I didn't put it into svn. I hope I can finish this very soon then I will show and explain it to you. > I want to commit the fixes related to sdcc & compiling; should I commit > it anyway? :P Why not? ;D Just try to make sure you don't mess up everything. IMHO, it's ok to have some bugs and not working stuff in trunk, especially in a redesign phase and if at least 2 persons work heavily on it. > There's still no wiki in the project -- I think Jason it too busy. A > project leader who can really get involved in the project is really needed. I just asked Lawrence, if it would be save to use the actual wiki without the possibility of loosing any data. (I guess you already read..) If so, we could use this list and the wiki to coordinate our work a little bit. > Next I want to move some code in the Node hierarchy "down" to the level > corresponding to it, and split the Connector class between the flowcode > and the electronic part. This should let remove quite a few dynamic_casts. > Or should I concentrate to something else? I think, that's a nice idea. During my work now on the *Manager classes, I menioned lots of dependencies between lots of classes that really shouldn't depend on each other. To have a clean-up here would be a great step forward. bye then julian
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________ Ktechlab-devel mailing list Ktechlab-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
