Hi,
Navigating through bug/wishlist reports, I found this old onehttps://bugs.launchpad.net/inkscape/+bug/171993that 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.
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
On Fri, Jul 3, 2009 at 12:43 PM, jf barraud <jf.barraud@...400...> wrote:
Hi,
Navigating through bug/wishlist reports, I found this old onehttps://bugs.launchpad.net/inkscape/+bug/171993that 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Fri, Jul 3, 2009 at 8:26 AM, Steren<steren.giannini@...400...> wrote:
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)
The difference is that opacity and blur are cumulative. You can apply more opacity and more blur on top of old opacity and blur, using groups for example. Color, however, is not cumulative. You can only replace the old color with the new one in the object itself (groups won't help you here), and this is something that a clone only allows you to do when it has NO old color, i.e. has the color unset.
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.
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
On Fri, Jul 3, 2009 at 6:31 PM, jf barraud<jf.barraud@...400...> wrote:
One more question:
Give it a try.
Where should I look at in the code?
see sp_use_move_compensate
participants (3)
-
bulia byak -
jf barraud -
Steren