Clone behavior is broken with style inheritance

[jshook]

Expected behavior:
Object A is cloned to another Object B (a clone).
The style of objects A and B by may be adjusted as the user wishes, without special handling. By default, the style of object (clone) B is "unset", meaning that it inherits from object A. Object A's style settings do NOT control whether object B will be able to specialize its style. If the user wishes to make any clone objects inherit style from their clone origin objects, they would simply "unset" the style on the clone objects, NOT the original object.

Observed behavior:
When I clone an object, and then try to set the style on the clone object (not inherited), the style is not allowed unless the origin object has its style set to "unset". While it appears to be documented this way in some places, it is documented differently in others. There appears to be a misunderstanding about how this is supposed to work. Please make it sane again.

Version:
Inkscape 0.47/Win32

[su_v (suv-lp)]

> While it appears to be documented this way in some places,
> it is documented differently in others.
Could you be more specific about this references?

the Inkscape manual correctly says:
«The style (color, fill pattern, etc.) of the clones can be changed independently but only if the style of the cloned object is Unset.»
<http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Clones.html>
«The fill type can be one of the following choices: (…)
- Unset (necessary for giving different attributes to cloned copies of an object).»
<http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Attributes-Fill-Stroke.html>

In my understanding, individual clones can only change their style if the original object (aka the cloned object) not the clone (aka cloned copy) itself has its styles 'unset'. AFAIK this hasn't changed in recent Inkscape versions.

[sas (sas-sas)]

Also, this is how cloning (the 'use' element) works in SVG, so it's natural that Inkscape does it this way too (it would be difficult for it to do otherwise).

See section 5.6 of the SVG 1.1 spec: http://www.w3.org/TR/SVG/struct.html#UseElement

[jshook (jshook)]

It may not have changed recently, but I have a vague memory of it
working the way I expected that last time I used it.
Granted, that may have been many version ago, and a vague memory.

When I had trouble with it the first time, i consulted:
http://wiki.inkscape.org/wiki/index.php/FAQ#I.27m_trying_to_make_a_colored_tiling_of_clones.2C_but_the_tiles_refuse_to_change_color.
and the Inkscape manual.
http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Clones.html

The first link is specific to tiling, but the cloned style behavior
shouldn't be special to that. It illustrated the behavior which I
verified, and was a bit confounded by.
The second link, I think I misread. The semantics of "cloned object"
are not explicit here. Perhaps "original object" and "clone" would be
better, since "cloned object" could refer to either. This ambiguity
may have misled others, too. As it is writen (perhaps based on other
sources), it could be interpreted either way.

I am taking basic principles of inheritance and applying them to
Inkscape semantics.
Here is an analogy. I'm not intending to harp or preach here, but to
provide a very clear example of why I find this confusing.

When you want to subtype in "OOP", you aren't prevented from doing so
unless the designer of the original type disallows it. This is even
frowned upon as it leads to artificial limitations on custom subtypes,
in general.
When you want to inherit from a base type (the original element) you
simply don't override the base type in the sub type (the cloned
element).
There are extremes on both sides of this, however. The standard spectrum:
A) declared, but undefined in the base type (abstract), only done with
specific design intentions, and at the cost of adding a layer of
abstraction for better or worse
B) standard behavior: declared, defined, and able to override in
subtypes. Inheritance is *automatic* if there is no overriding in the
subtype. This is what the semantics of "Unset" in Inkscape appear to
have been for. My reading of the "use" does not preclude this, and
the example actually shows it in action. Specifically, see example
"Use04". Notice that the style attribute is not "unset" on the "use"
referent "#MyPath".
C) declared, defined, and locked in the base type (final)

The current behavior seems to require the user to think about it in
the mode of A or C, but not the "rational" way of B. This forces the
user to qualify styles completely (as in all nodes, no default,
tedious) from the bottom up, or completely (as in rigid, inflexible)
from the top down. At the very least, the designer has to have a
separate "robot controls" set of objects, instead of having a
"primary" that is simply a part of the intended content.

After consulting http://www.w3.org/TR/SVG/struct.html#UseElement, I
don't believe my expectations are misplaced. The spec does include an
example in which the use of the "use" element includes overriding
style, which illustrates the principles above.
I hope to see this improved, and will help as best I can. I think
Inkscape is an awesome tool.

On Sun, Dec 6, 2009 at 4:02 PM, ~suv <email address hidden> wrote:
>> While it appears to be documented this way in some place...

[bbyak (buliabyak)]

> Notice that the style attribute is not "unset" on the "use"
referent "#MyPath".

Style attribute cannot be unset, only individual properties can. And in this example, the original has e.g. the fill unset, i.e. it is not specified for it. This is why setting blue fill on the use works.

I'm going to close this as invalid, please don't take this personal but it doesn't seem like you uncovered any problems here, Inkscape works according to the spec in this aspect.

[jshook (jshook)]

I understand now how the spec intends for this to work. I think it
verifies that override is not possible with "use".
Thanks for taking the time to sort it out.

On Mon, Dec 7, 2009 at 12:26 AM, bbyak <email address hidden> wrote:
>> Notice that the style attribute is not "unset" on the "use"
> referent "#MyPath".
>
> Style attribute cannot be unset, only individual properties can. And in
> this example, the original has e.g. the fill unset, i.e. it is not
> specified for it. This is why setting blue fill on the use works.
>
> I'm going to close this as invalid, please don't take this personal but
> it doesn't seem like you uncovered any problems here, Inkscape works
> according to the spec in this aspect.
>
> ** Changed in: inkscape
>       Status: New => Invalid
>
> --
> Clone behavior is broken with style inheritance
> https://bugs.launchpad.net/bugs/493318
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Inkscape: A Vector Drawing Tool: Invalid
>
> Bug description:
> Expected behavior:
> Object A is cloned to another Object B (a clone).
> The style of objects A and B by may be adjusted as the user wishes, without special handling. By default, the style of object (clone) B is "unset", meaning that it inherits from object A. Object A's style settings do NOT control whether object B will be able to specialize its style. If the user wishes to make any clone objects inherit style from their clone origin objects, they would simply "unset" the style on the clone objects, NOT the original object.
>
> Observed behavior:
> When I clone an object, and then try to set the style on the clone object (not inherited), the style is not allowed unless the origin object has its style set to "unset".  While it appears to be documented this way in some places, it is documented differently in others. There appears to be a misunderstanding about how this is supposed to work. Please make it sane again.
>
> Version:
> Inkscape 0.47/Win32
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/inkscape/+bug/493318/+subscribe
>