Re: clone behaviour

by jf barraud :: Rate this Message:

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 :)

One situation where you typically want to use clones is when you want to represent some data on a map: you draw a pictogram at each place, and use it's size to represent the associated value. Now if you wan to represent two related observations at once, you may want to use the color to represent the second quantity... this is one use case. There are dozens of other. You may want to use plenty of stars as your drawing background: you'll most probably draw a few "models", and clone them (rather than duplicate, just in case you decide to further edit the models). For more variety, you may want to use the smear tool to let the colors vary... etc, etc...

I have spent quite a time coding around issues like this and ensuring
that clones transform intuitively, using compensations.

Oh! thanks for the "naked" case then :-). You're right, it's something definitely doable. I'd say it's just a matter of multiplying the clone transform matrix by the inverse of the transform newly applied to the parent. The main question is should it be on the right or on the left. Because of the strange "right multiplication" convention, I'd bet we shoud left multiply by the inverse (?).

> -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.

Yes, that is the point: why should there be a paretn/child relation between an object and it's clone? it sounds more natural to consider them as twins!

> 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.

right.

> 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.

Yeah! That is precisely my point: I hate putting the parent in another layer! But I ran into troubles several times because I did not (mostly because of the transform issue --- if you don't realize immediately that the clones are transformed twice, you can do non reversible errors...--- which you convinced me can be fixed), or had to allow the color to be overriden (the black parent just has nothing to do in your drawing in general).

> 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.

I agree. That is why it should be editable "in place".

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.

If the clones become editable "in place", I don't see what becomes more complicated. In the "classical" use case of exact clones, the new behaviour would be transparent to the user. The only difference would be that you don't need to jump to the parent to edit the shape.

> +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.

Thanks for your reply and attention. The main issue about all this is maybe that many users are accustomed to the actual behavior...

jfb.

--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org

------------------------------------------------------------------------------

_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

« Return to Thread: clone behaviour