Hi,
First of all I would like to clarify the current behavior. I tried to work with clones recently, and I must admit they seamed very weird and I preferred to use copies.
Why can't I modify the color of a clone if I can modify its opacity or blur ? On a user point of view, what's the difference between fill color and opacity ? (they both deal with style)
I tried to read http://www.w3.org/TR/SVG11/struct.html#UseElement , but didn't find exactly where this rule is mentioned. I would be pleased if someone could answer this question.
I also guess that Inkscape is implementing the right "svg:use" behavior.
To comment and add on the proposal of Jean-François, I would imagine 2 types of objects :
* "real clone" : there is no parent concept any more : Every instance has its own transformation but all share the same data (style, path...). You can edit any of them and when you edit one, you edit all of them at once.
* "child" : parameters of a child are the same than its parent except if a value is overloaded.
Example : create a child of a rectangle, change the color fo the parent rectangle, the child's color change. But if you specify a specific fill color to the child, then the color value is overloaded, it won't change anymore when the parent's color is changed.
What do you think ?
Steren
Hi,
Navigating through bug/wishlist reports, I found this old one that was declared invalid, but I'd like to discuss a little more.
It's about clones behaviour in general. The 'svg' specification is very limiting with this respect, but I think there are svg compilant ways to get more freedom.
What I dislike in inkscape/pure svg clones:
-color/style management: it's very difficult to have objects share shape but not color. The parent's color has to be set to 'undifined', hence looking black, which generally means you'll have to hide it (as for custom stroke width, dashes..., they require the svg editor!). Moreover, one might want to have some clones share the fill color but have custom stroke, and/or someother share the stroke color but not the fill.This is doable using intermediate clones, but definitely not handy.
-transform management: create an object A, create a clone A' of it, put A' in a group G. Now select A and G and rotate them. A' is rotated twice!!! This is definitely non intuitive, and means you'd better move the parent object to a specific layer and never use it directly in your drawing if you don't want to bump into pretty bad situations.
-more generally, making a difference between the parent and the clones will always induce unexpected or non intuitive effects. IMO, parent and clones should be prefectly symetric.
One naive way to improve this would be to have our own "inkscape:clone" objects of course, and let them behave exactly the way we want.
I'd like to suggest another intermediate option. I think svg clones are mainly disgned for "internal" use. My experience is that each time I had to use them, I indeed did end up putting the parent in a separate layer (at least away from the main drawing) and work with clones only. We could automate this process:
When an object is cloned, not only the clone is created, but the parent is also moved to a special hidden layer (or in the defs, why not?, or simply hidden) and replaced by another clone.
+ all visible instance of the "thing" can be manipulated, grouped, transformed, uniformly.
+ it makes it possible to let the clone inherit only some style properties of the parent: at creation time, the parent's style would be moved to an "inkscape:default_clone_style" attribute, and the style itself would be set to undefined. Inkscape would compare clone's style to the "default_clone_style" to detect user modified properties, and maintain all style changes accordingly.
+finally, it would be so nice to be able, whenever the user attempts to node-edit a clone, hide the clone itself, replace it by a temporary copy of the parent, and transfer the modifications to the parent.Of course, there are issues: in particular, the parent may appear as a reference anywhere else in the document. Changing it's style to undifined might have unexpected results. One solution would be to use an intermediate object: an inkscape special object that would be a linked copy of the parent, but have the style attribute set to undefined, and have the clones point to this linked copy.
Ok, this might sound too complex. This can be declined in softer versions: for instance, instead of making this automatic and transparent to the user, we could at least offer the possibility
*at least offer the user the possibility to automatically move the parent to a separate layer
*when the user attempts to set the style of a clone when it does not make sens, suggest either setting the style of the parent or setting the parent's style to undefined and transfer the actual style to all existing clones.
What do you think?
Cheers, jfb.
------------------------------------------------------------------------------
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...1794...s.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel