From: <aur...@wa...> - 2003-04-22 15:09:06
|
Le mar 22/04/2003 à 16:27, arj...@he... a écrit : > > To Arjan : I see two possibilities here. 1) when DiaCanvasEdge/Node are > > ready (monthes from now), you include them... 2) you include them in > > their current state but they are marked EXPERIMENTAL and they will only > > help GraphTool work without too much pain. > > 3) Include them in your own source tree ;-). It's 1) really. Currently those classes barely build in my own tree, since after each 'make clean' && ./configure I have to manually add two includes to the autogenerated python/diacanvas.c Any idea why ? > > I'd like to see the code as soon as it's available. Providing an alternative > for the current line/element is a good thing. CanvasNode is a ripoff of CanvasElement, with only 1 central node, CanvasEdge is CanvasLine really with much less code (I had to cut all the hard work you put in to understand what to do next...), and just one segment. So... not very interesting. For the node, the ONE HANDLE solution may not be good enough. In fact, the RIGHT THING would be : - edges connect to the border of the shape - when objects are moved, constraints help the connexion point move accordingly : a) (X)<----------(Y) then we move Y around b) (Y)----------->(X), not (-)----------(->) where Y and X are hidden due to the Edge/Node's braindead stickyness So connection contraints ought to be set on shapes, not only on an object's bounding box. Maybe this is just a matter of putting in the right constraint. I'll have to do some basic planar maths... For the Edge, I would be pleased with a multishape one : - viewable as straight segment (makes sense in a lot of cases) - ...as a bezier too (nice to look at, helps implementing loops...) -... as a multipath (quite like the current Line class) and the ability to switch at runtime. So, well, I can send code right now but of little interest (to you). Thanks, Aurélien. |