gradient editing spams duplicates

Bug #583080 reported by HonoredMule
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Inkscape
Confirmed
Undecided
Unassigned

Bug Description

Selecting different objects sometimes causes the Fill and Stroke dialog to forget that a gradient has been applied (cannot determine exact steps to reproduce, but it may involve grouping or reloading files). When this happens, a gradient button has to be clicked again to enable the Edit button, which upon clicking then duplicates the previously selected gradient, and opens an edit dialog for the newly applied instance.

Dragging inner gradient markers also implicitly duplicates the selected gradient instance. In even a medium-sized project, it takes no time for the gradient selection dropdown to be cluttered with hundreds of nearly-identical gradients with non-descriptive names, most of which were entirely unnecessary and unexpected. In many cases, the result is unintended and undesired inconsistency. In my opinion, this is worse and makes the document much harder to manage than the alternative of possibly unintended impact on other objects sharing the original gradient.

Expected behavior:
Fill and Stroke dialog should always remember what has already been applied to an object, but regardless of this hard-to-track implementation bug, the gradient selection and editing behavior should be more consistent.
 - Choosing a gradient type in Fill and Stroke should select the last-used gradient instead of a dummy new one that will disappear if selection is altered (with exception for when there are currently no gradients at all).
 - Clicking the edit button should never take any action other than to edit the currently selected gradient (often objects were selected or assigned a pre-existing gradient just to get an edit window for that gradient).
 - Editing gradients, whether on canvas, through the Edit window, or some other means, should never assume a new unique instance is desired. If anything, there should only be a first-time warning on editing a gradient applied to more than one object.

Related opportunities for UI improvement:
Accessing the gradient editor should not require use of an object with a gradient applied. The gradient editing window should allow selecting the gradient being edited, and should be reachable by some other direct path. The prominence of such a task should also not require using the XML editor.

The Fill and Stroke dialog should also have a "New..." button for starting a gradient from scratch, rather than relying on undesirable side effects to get a fresh start.

Creating gradients should prompt for a descriptive name prefilled with the non-descriptive default, to make larger projects more bearable to maintain.

Duplicating an existing gradient (at least for those with a descriptive name) should either trigger a prompt for a new one or automatically derive one based on the name of the original (i.e. mySpecialGradient2).

Creating new gradients by duplication could automatically keep the original and its duplicates grouped in the XML. This could then be used for two-stage gradient selection (group then actual gradient), make large numbers of gradients easier to manage, and make gradient relationships more clear. More advanced intentions can tweak this organizational pattern by directly using the XML editor.

Tags: gradient ui
Revision history for this message
HonoredMule (honoredmule) wrote :

Almost forgot--using Inkscape 0.46 on Windows. Though no mention of gradient editing or Fill and Stroke behavior was made in the changelog, I'll be trying out 0.47 shortly.

Revision history for this message
su_v (suv-lp) wrote :

- lost gradients:
I haven't seen the Fill&Gradient dialog forget "what has already been applied to an object", at least not in Inkscape 0.47. Maybe you applied the gradient the object and later selected a group containing the object but not the object itself. Please remember to check the messages and fill&stroke settings in the status line below the canvas to verify you have actually selected the intended object.

- implicit gradient duplication:
Uncheck the setting 'Inkscape Preferences > Misc > [ ] Prevent sharing of gradient definitions' to avoid automatic forking of gradients when editing gradient stops on-canvas and duplicating or copy&pasting objects with a gradient fill or stroke.

Revision history for this message
su_v (suv-lp) wrote :

Correction: The setting "Prevent sharing of gradient definitions" does not influence copy&paste or duplicate operations.
See also "No more ID clashes on import and paste" (New in 0.47):
<http://wiki.inkscape.org/wiki/index.php/Release_notes/0.47#Notable_bug_fixes>
Bug #165936 “ID clash when copying/importing gradients across documents”
Bug #168626 “Importing multiple SVGs mixes up colors (XML ID clash?)”

Other reports related to managing gradients:
Bug #170214 “merge identical patterns/gradients/markers”
Bug #437926 “Usetting "Prevent sharing of gradient definitions" option does nothing”
Bug #510077 “Copy/Paste to the same document should behave as Duplicate”
Bug #516108 “Tool to re-map and delete a gradient”

Revision history for this message
HonoredMule (honoredmule) wrote :

I found the memory problem. Fill and Stroke switches to saying no color has been applied when vertices or other various handles/markers within an object are selected.

Revision history for this message
su_v (suv-lp) wrote :

> Fill and Stroke switches to saying no color (…) when vertices or other various handles/markers (…) are selected.

Not reproduced with Inkscape 0.46 and 0.47 - can you attach a sample SVG with steps to reproduce?

Revision history for this message
HonoredMule (honoredmule) wrote :

I can supply an SVG if really needed, but nothing complex is required--just a single simple object. Now that I've figured it out, I can reproduce consistently:

Start a fresh new document.
Create an object (say, a box) and convert it to path.
Open Fill and Stroke, select gradient to apply to the path.
Switch to the node selection tool.
Select a vertex (Fn'S still shows gradient).
Select one of the control markers for the gradient by clicking on it (Fn'S switches to solid color).
Select at least one vertex again, either by clicking with or without modifier keys or drag-selecting (Fn'S stays on solid color).
- Alternatively/After, deselect the control marker by shift-clicking on it (Fn'S still stays on solid color).
Gradient status is only restored in Fill and Stroke if directly clicking the object, forcing vertex selection to be lost, or moving the selected vertices.

I didn't even realize until trying to reproduce this behavior that the solid color selection allowed me to edit a gradient "in-line." Most of the time when that was up, I was dealing with a vertex selection, not color markers. I can see the value in that, but I'd rather keep access to gradient selection and other controls--especially since clicking color markers other than the anchor and endpoint(s) brings risk of accidentally moving them.

I think this bug:
https://bugs.launchpad.net/inkscape/+bug/321840
is really on the right track for improving this and related behavioral gotchas/inconsistencies.

Revision history for this message
su_v (suv-lp) wrote :

Thank you for the detailed description:
I can confirm that when one of the gradient stops is selected (when working with the node tool), selecting a node of the path doesn't deselect the gradient stop and therefore the fill&stroke panel doesn't update to the object fill/stroke paint. You have to click the gradient itself (not one of the stops) to deselect the active gradient stop which immediately restores the fill/stroke paint attributes of the current object in the fill&stroke dialog.

In the development version (0.47+devel) the selection of path nodes doesn't get lost anymore when deselecting the gradient.

OTOH in the preferences you can disable gradient editing for each tool if you don't like to reuse the fill&stroke dialog for editing the gradient on-canvas.

(Reproduced with 0.46, 0.47 and 0.47+devel on OS X 10.5.8)

su_v (suv-lp)
tags: removed: consistency fill stroke
Revision history for this message
Beluga (buovjaga) wrote :

Still repro.

Arch Linux 64-bit, KDE Plasma 5
Inkscape 0.92pre1 15054 (GTK3)

jazzynico (jazzynico)
Changed in inkscape:
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.