Hi,
I was experimenting with additional knotholders for items carrying an LPE but I'm having problems. What I did was simply to add another case distinction to sp_item_knot_holder() in object-edit.cpp. It checks whether an object has an LPE applied to it, in which case it returns a different knotholder than the standard one.
The handling methods for the new knotholder are minimal (a 'set' method which does nothing and a 'get' method wich just returns a constant point) but Inkscape keeps crashing when handles corresponding to the "ordinary" knotholder are moved. I suspect that the new knotholder somehow interferes with the one that is created for paths in nodepath.cpp but I can't seem to find the exact cause of the problem. The backtraces don't look very helpful to me either since the crash happens in different places and I haven't yet found the common cause (see below for 2 sample backtraces; note that the line numbers may slightly vary due to my changes to the code).
I wonder if anyone has an idea what could be wrong. Really some kind of interference between the two knotholders? How do the knotholders for paths work anyway? Is object-edit.cpp the wrong place to alter them?
Thanks in advance, Max
Backtraces:
#0 0xb7376c77 in g_str_hash () from /usr/lib/libglib-2.0.so.0 #1 0xb73484db in g_hash_table_lookup () from /usr/lib/libglib-2.0.so.0 #2 0xb7341271 in g_quark_from_string () from /usr/lib/libglib-2.0.so.0 #3 0x087b783e in Inkscape::XML::SimpleNode::attribute (this=0x9ef1600, name=0x40240000 <Address 0x40240000 out of bounds>) at xml/simple-node.cpp:222 #4 0x081eae1d in update_repr_internal (np=0xaee6c00) at nodepath.cpp:578 #5 0x081ee47c in sp_nodepath_update_repr (np=0xaee6c00, annotation=0x884685c "Move nodes") at nodepath.cpp:613 #6 0x081eeb4b in node_ungrabbed (data=0xb2a1c40) at nodepath.cpp:3363 #7 0xb741265a in g_cclosure_marshal_VOID () from /usr/lib/libgobject-2.0.so.0 #8 0xb74056f9 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #9 0xb7419c3d in ?? () from /usr/lib/libgobject-2.0.so.0 #10 0x09a99b00 in ?? () #11 0x00000000 in ?? ()
#0 0x081a122c in sp_document_maybe_done (doc=0xb08eb40, key=0x0, event_type=111, event_description=@0xbfbff160) at document-undo.cpp:173 #1 0x081a14f0 in sp_document_done (doc=0xb08eb40, event_type=111, event_description=@0xbfbff190) at document-undo.cpp:125 #2 0x081ee4c4 in sp_nodepath_update_repr (np=0xb08eb48, annotation=0x884685c "Move nodes") at nodepath.cpp:617 #3 0x081eeb4b in node_ungrabbed (data=0xb7f8ae0) at nodepath.cpp:3363 #4 0xb73c865a in g_cclosure_marshal_VOID () from /usr/lib/libgobject-2.0.so.0 #5 0xb73bb6f9 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #6 0xb73cfc3d in ?? () from /usr/lib/libgobject-2.0.so.0 #7 0x0b974be8 in ?? () #8 0x00000000 in ?? ()
-----Original Message----- From: inkscape-devel-bounces@lists.sourceforge.net [mailto:inkscape-devel-bounces@lists.sourceforge.net] On Behalf Of Maximilian Albert Sent: woensdag 14 mei 2008 19:00 To: inkscape Subject: [Inkscape-devel] LPEs/paths and knotholders
Hi,
I was experimenting with additional knotholders for items carrying an LPE but I'm having problems. What I did was simply to add another case distinction to sp_item_knot_holder() in object-edit.cpp. It checks whether an object has an LPE applied to it, in which case it returns a different knotholder than the standard one.
The handling methods for the new knotholder are minimal (a 'set' method which does nothing and a 'get' method wich just returns a constant point) but Inkscape keeps crashing when handles corresponding to the "ordinary" knotholder are moved. I suspect that the new knotholder somehow interferes with the one that is created for paths in nodepath.cpp but I can't seem to find the exact cause of the problem. The backtraces don't look very helpful to me either since the crash happens in different places and I haven't yet found the common cause (see below for 2 sample backtraces; note that the line numbers may slightly vary due to my changes to the code).
I wonder if anyone has an idea what could be wrong. Really some kind of interference between the two knotholders? How do the knotholders for paths work anyway? Is object-edit.cpp the wrong place to alter them?
Hi Max,
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.
For as far as I remember: Shapeeditor either has a nodepath OR a knotholder. That's a basic assumption built into all code. It cannot have both, so perhaps things go wrong because now it adds both for a path?
When nodepath is a knotholder too, this problem will go away.
Cheers, Johan
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
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
Well, if you are looking for a basic design for nodepath, then don't worry, there is none. It is basically a collection of editing functions and supporting utilities.
It should not be a problem to C++ifiy context-free functions. Just consider them to be static methods initially. Then gradually convert them to contextual instance methods.
Just an idea..
bob
J.B.C.Engelen@...1578... wrote:
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).
J.B.C.Engelen@...1578... schrieb:
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?
Yes. I just (re)discovered the PointParam parameter type for LPEs and at first thought that it might provide what I need. But I found that it's only possible to alter either such a PointParam or the path itself (in node context) but not both at the same time. Is this correct? In this case I would still need to unify knotholders and nodepaths. Again, if anyone has suggestions how this should best be done, I'd be glad to hear them.
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.
That would be very interesting. Bulia, can you tell what work you already did, what remains to be done and how to proceed? (I'm CC-ing you in case you missed this conversation), Thanks!
Max
On Sun, May 18, 2008 at 12:42 PM, Maximilian Albert <Anhalter42@...173...> wrote:
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.
That would be very interesting. Bulia, can you tell what work you already did, what remains to be done and how to proceed? (I'm CC-ing you in case you missed this conversation), Thanks!
Right now ShapeEditor is a simple transparent container that just passes everything to a single knotholder or nodepath it contains. It's an isolation layer. I think it will be very easy to enable it to hold multiple knotholders and manage them simultaneously. The reason I didn't do this myself is because I'm more interested in multiple nodepaths, and this is much more difficult to do because it will need to e.g. handle multiple node selections and treat them as one. (Right now I tend to think that it will be actually easier to allow a single nodepath to hold multiple paths and have one node selection for all of them; but even if it is implemented this way, this does not make ShapeEditor unnecessary because it is still needed for treating multiple knotholders, or knotholders and one nodepath, as a whole.)
Let me know if you have any specific questions.
participants (4)
-
unknown＠example.com -
Bob Jamison -
bulia byak -
Maximilian Albert