Closed zindlerb closed 8 years ago
Good point!
I think the ideal solution would be a version of your idea 3. In particular, it would be nice to know where in the element tree is a "rendering context" and where in the tree is a "anchor-collection context", and to prevent dragging renderable elements to anchor-collection contexts or dragging anchors to rendering contexts. I can think of a few complications in making this determination:
Group
s can be in rendering or anchor contexts. (See how collectAnchors
descends through Group
s in the definition of Graphic.Path
.)Path
s should be able to take anchors. Circle
and Text
are secretly Path
s, but they override the rendering code which cares about anchor descendants. So really, you shouldn't be able to give them children at all.But these aren't huge problems, and I still think this version of idea 3 would be ideal.
(Your idea 1 isn't great, since dragging anchors within a path serves the useful function of reordering the points on the path. Your idea 2 is interesting, but I agree that it might be confusing to present anchors as independent graphical elements.)
What do you think? If you are interested in taking this on, I would be happy to help however I can.
I agree. I can do a pr for this. I'll message you if I have any questions 👍
I made a pr for this here https://github.com/cdglabs/apparatus/pull/56. Let me know if this looks like a reasonable approach. Thanks!
When you drag an Anchor in the outline into a spot where it will render it throws an exception ("Not implemented") because the Graphic.Anchor does not implement the render or hitDetect methods.
I see 3 ways to resolve this:
I'd be willing to do a pr for this. Let me know if any of these sound good.