hi, looking at the code, the mapping of the xml node types to GTypes seems a bit inflexible and assumes there's a one to one relationship. i was thinking of using a specialized SPGroup to implement a feature, but when the group operation is invoked from the UI it only adds the svg:g xml node; a listener callback is invoked and an SPGroup is created. i could use my own tag, but this would mess up other svg viewers unnecessarily (the feature i want just has to do with how the group is handled during interaction not with its display). ideally, i'd want to use something like <svg:g inkscape:variant="my special group">...</svg:g> so i'd have to use the element's attributes as a secondary key to cause it to create MySpecialSPGroup with modified behaviour. the alternative would be to use a different tag or add the new behaviour to the normal SPGroup (which seems bad from a design perspective). any thoughts?
regards, rob
---- Robert Melby uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!org!arcsin!rm
On 4/30/05, rm <rm@...800...> wrote:
i could use my own tag, but this would mess up other svg viewers
unnecessarily
No, this is out of the question. Our SVG must display the same everywhere.
(the feature i want just has to do with how the group is handled during interaction not with its display). ideally, i'd want to use something like <svg:g inkscape:variant="my special group">...</svg:g>
Yes, except that the correct attribute is sodipodi:type. That's how our offsets and many shapes are done, all using svg:path element. Register a new value for sodipodi:type in sp-object-repr.cpp. Use the inkscape: prefix for the value, as is done in
<path sodipodi:type="inkscape:offset" ... >
Then create a new corresponding SPGroup subclass.
participants (2)
-
bulia byak
-
rm