On Fri, January 23, 2009 1:01 pm, Gregor Mückl wrote: > Hi! Hi! Thanks for taking the time to reply!
> I don't think that a more elegant method can exist. You need to express a > vector between the positions of the two nodes of an edge and to do that > you > need the coordinates of both in a common frame of reference. And as far as > I > can see, you already calculate the position in the simplest frame of > reference > for your problem: the common parent for all your nodes, the untransformed > coordinate system of the GraphicsView. I truely doubt that there is a > better > way. Ok. That was my thinking. I just wanted to make sure I wasn't overlooking something obvious. > I've been having the same issue in the graph editor in Moonlight|3D and I > remember that I felt like doing something quite inelegant at that point. > :) :-) > I'm thinking about a new feature for QGraphicsLineItem: set line end > points in > coordinate systems of other nodes. The item would then remember and > monitor > the other node for transformations and update itself so that the end point > stays at the same position relative to that node (in other words, at the > same > coordinates in that node's coordinate system). Maybe this stretching > between > nodes that arises from this feature could be generalized somehow, so any > graphics items could exploit it in similar ways. That sounds very interesting! And now that you've mentioned QGraphicsLineItem, it looks like I should probably be using this as the parent class for my "Edge" type. It looks like it has a better bounding rectangle implementation... How would I go about making QGraphicsLineItem's bounding rectangle implementation deal with the extra area that can extend outside of the line's bounding rectangle when an arrowhead is present on the end of the line? This is where remedial trig assistance would be useful. ;-) > I think this is the right way. I'm using QGraphicsLineItems and only > update > the positions of the line endpoints, but I have to assume that this calls > update() internally. As far as I remember, multiple calls to update() > within > Qt are not particularly bad because the redraw is lazy and multiple > update() > calls cause just one combined redraw. That also makes sense. Thanks for validating the approach! Michael _______________________________________________ Qt-jambi-interest mailing list [email protected] http://lists.trolltech.com/mailman/listinfo/qt-jambi-interest
