Maximilian Albert:
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.
Nodepath is a big beast: almost 5k lines of code :S I am familiar with bits of it, but at the moment have not a clear idea how to convert it to knotholder (or convert knotholder to nodepath-y code).
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.
You mean handles to modify LPE parameters?
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.
Bulia has done some work towards being able to edit multiple knotholders and nodepaths at the same time (ShapeEditor code). Maybe if you get that working, it solves your problem.
Johan
-----Original Message----- From: inkscape-devel-bounces@lists.sourceforge.net [mailto:inkscape-devel-bounces@lists.sourceforge.net] On Behalf Of Maximilian Albert Sent: zaterdag 17 mei 2008 19:59 To: Engelen, J.B.C. (Johan) Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] LPEs/paths and knotholders
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
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel