J.B.C.Engelen@...1578... schrieb:
==> I don't know the exact problem that you are having. But 0aths do not use knotholders, they have nodepath. I think to start, you need to C++-ify Knotholder and make nodepath a subclass of it (and rectangles, 3d-boxes, the lot). This way it is more robust and you can't forget stuff as easily. It might be a lot of work though. <==
I temporarily found a way to solve my problem otherwise (I believe it was indeed the nodepath vs. knotholder problem you mentioned). But in the long run I think it would be good to be able to treat nodepaths and knotholders in a unified way.
So I tried to C++-ify knotholder, which was easier than I had thought. But then I got stuck trying to make nodepath a subclass of it because the two seem to work *very* differently internally. Thus I would be glad if someone more familiar with these internals could give me a few hints how this integration of nodepath into knotholder should work and how to best proceed.
As for my workaround for the above-mentioned difficulties in providing new knotholders for LPEs: What I'm doing now is check whether an LPE provides a knotholder of its own. If this is the case then this knotholder is returned in sp_item_knot_holder() in object-edit.cpp. Otherwise a nodepath is created as usual. The problem is that I would like to be able to edit the original path but additionally provide handles to modify the "new" path returned by the LPE. At present these two can't be mixed due to the nodepath <--> knotholder problem. So currently the new knotholder must access the original path and provide handles for it, too, which imitates the work that would otherwise be done by the nodepath and should thus be unnecessary.
Max