First off, THANX, ZOLTAN!!!
I've been spending far too much time I don't really have on this today...
I did some messing around where I made the ECConnector and FPConnector
classes that I was mumbling about the past few days to see what would
happen, and I found that an issue arose where ICN document has a member
which refers to Connector. This, by itself, is just peachy..
Then it gets inherited by circuitICNdocument (which should use
ECConnector), and FlowICNDocument...
I'm not sure what A C++ programmer is supposed to do with that, overload
the member and the constructors?
Then I was looking at the compiler barf for:
bool CircuitICNDocument::joinConnectors( ECNode *node )
Its first line is:
// We don't want to destroy the node if it has a parent
if ( node->parentItem() ) return false;
This is basically asking: "If this is a pin node, then we shouldn't mess
with it".
Which points out that JunctionFlowNodes and Junction Nodes shouldn't
have parents, while pins, and input/output nodes should...
I greatly respect the amount of work that has been put into the
node-refactoring that I'd asked for. I'd really like some insight about
how to address this design decision.
--
FAKE candidates; RIGGED machines; Don't vote.
Remember, if there aren't any anti-war candidates, it's not an election.
Chemistry.com: A total rip-off.
Powers are not rights.
-------------------------------------------------------------------------
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
