[Ktechlab-devel] QT4 migration. (and misc.)

[Julian Bäume]

On Monday 22 September 2008 15:16:59 P Zoltan wrote:
> On Mon, 22 Sep 2008 04:34:32 +0200, Alan Grimes <agrimes at speakeasy.net>
>
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 489 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/ktechlab-devel/attachments/20080924/60e70917/attachment.sig>