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
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).
On 4/30/05, rm <rm@...> wrote:
> i could use my own tag, but this would mess up other svg viewers
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=3D"my special group">...</svg:g>=20
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=3D"inkscape:offset" ... >
Then create a new corresponding SPGroup subclass.
Inkscape. Draw Freely.