Usetting "Prevent sharing of gradient definitions" option does nothing

[AJ Ashton]

1. Uncheck the "Prevent sharing of gradient definitions" option in Inkscape Preferences -> Misc.
2. Copying & pasting an object with a gradient still creates a new gradient. Pasting style only still creates a new gradient.

Duplicating an object (ctrl-d) with a gradient style on the other hand does not create a new gradient whether the option is checked or not.

Tested with latest SVN build (Inkscape 0.46+devel r22321, built Sep 27 2009) on Arch Linux x86_64

[thorwil (t-w-)]

Happens with the build in Ubuntu 9.10, Inkscape 0.47pre4 r22446, built Oct 15 2009. too.

[su_v (suv-lp)]

Confirmed with Inkscape 0.46+devel r22547 on OS X 10.5.8

[su_v (suv-lp)]

Withdrawing my previous confirmation of this as a bug:
a) With the setting checked, editing a gradient (on-canvas or in the gradient editor dialog) always creates a new (forked) gradient definition and the changes apply to the currently selected object only.
b) Unchecking the preference setting allows to reuse gradients for several objects and to not fork a new gradient when editing the gradient of the currently selected object in the gradient editor: the changes (color, transparency, number of stops) apply to all objects that use the same gradient. Editing a gradient on-canvas still forks a new gradient.

The setting "Prevent sharing of gradient definitions" does not seem intended to influence copy&paste or duplicate operations (see the description in the tool tip of the preference setting). Maybe this report should be turned into a feature request to optionally allow reusing the id of gradients when pasting objects? AFAIK this has been disabled to prevent unwanted fill&stroke changes when pasting objects from other documents that might use the the same id for a different gradient definition.

[sas (sas-sas)]

> Maybe this report should be turned into a feature request to optionally allow reusing the id of gradients
> when pasting objects? AFAIK this has been disabled to prevent unwanted fill&stroke changes when
> pasting objects from other documents that might use the the same id for a different gradient definition.

That's basically right. What actually used to happen was that the duplicate gradient got pasted with a new ID, but the object(s) that used the gradient remained pointing to the old ID, so you ended up with a shared gradient (even if the pasted gradient was supposed to be different) plus an unused gradient.

I think the best way to deal with the build-up of duplicate gradients that sometimes occurs is to add an option to Vacuum Defs (which should probably be renamed to something like Clean Up Document) that would find duplicates and make all objects use the same one. This has already been suggested in bug 170214.

[Hans Dybkjær (hhns)]

I do a lot of diagramming of origami models. This is a sequence of drawings of single steps of folding paper. Whatever is visible of the same side of the paper, will be drawn using the same gradient. So I want all duplication and copy/paste to preserve the gradients.
Since two steps differ only slightly, the easiest way to draw is to duplicate the previous step which seems to preserve the gradient instead of wrongly creating a new gradient.
However, if the object to be duplicated is part of a group, the duplicated object stays part of the group. I don't know if that behaviour has any use, but it is certainly not my intention.
If I instead copy/paste, the new ("duplicated") object is severed from the group, exactly what I need. However, for some reason not only the object is copied, but also the gradients.
So:
1) Unchecking "Prevent sharing of gradient definitions" does not do what it says: copy/paste will still create new gradient definitions instead of sharing them.
2) The distinction between Copy/ctrl-alt-v and Duplicate is at best misleading; in my guess it would be better off to behave exactly the same.
3) I very much need a mode of copying/duplicating objects (or groups of objects) where gradients are preserved (and duplicates not staying part of the original's group). The suggestion of the above referred bug 170214 (to make it easy merge alike gradients) would be useful, but a) not match my most intensive use pattern, and b) not always be intended. I might name gradients intentionally (e.g. "gradient-front" and "gradient-back"), and these should not be merged even if they (probably temporarily) are defined alike. And when merging gradients like "gradient-front", "gradient-front-1" and "another-gradient-that-ended-up-having-the-same-values", I would like my name ("gradient-front") end up being the one used, and not the names of the other two, similar gradients.