On Fri, Jul 3, 2009 at 6:43 AM, jf barraud<jf.barraud@...400...> wrote:
-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!).
You're right, we need an easy UI way to unset any style property, not just fill/stroke.
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.
Well, the need to have differently behaving clones of the same original is not very frequent I guess, and to me it seems quite natural to use clones of clones for this. I think it really shows Inkscape power that this is possible at all :)
-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!!!
I have spent quite a time coding around issues like this and ensuring that clones transform intuitively, using compensations. However my calculations are limited to the simple case of naked clones. If you put a clone in a group and transform the group, or use clone of clone chains, this will still behave wrong. But it's not some unfixable problem. The code for compensations is there, we just need to make this code smarter and make it look farther around the clone to figure out the correct compensating transformation. Maybe it was just me, but I found this too difficult, so I limited myself to the simple case - someone more mathematically gifted can probably crack it easily. Give it a try.
-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.
Parent/child relationship is asymmetric by its very nature.
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.
Yes, but this will remove the smaller file size advantage - that clone will have to carry a complete copy of the source path in order to stay compatible with SVG.
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.
Maybe it's your typical use case, but not mine. 99% of the time I need simple clones without any changes in style, and it's very convenient that I can quickly Shift+D to the original and edit it on the spot. Hiding it somewhere will make it painful to use clones for me.
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.
This is what is called "symbols" in other programs. The main advantage to symbols in e.g. Flash is that you have a gallery from which you can drag them to the canvas. But to me, the inconvenience of accessing and editing the originals is much worse.
In summary, I think your proposal will make some workflows a little more convenient but others (and I think it's the majority) very inconvenient almost to the point of impossible. It can be implemented but only as an option, for those who really need it, not replacing the Clone command but as a new "Create symbol" command - and of course you would also need to code a nice gallery of your hidden symbols.
+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.
That sounds quote complicated to me, but probably doable.