Nodes have precedence over gradients in node tool

Bug #921529 reported by LucaDC
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Inkscape
Confirmed
Wishlist
Unassigned

Bug Description

This is more a request than a bug report.
When in node tool, there is an option to edit gradients as well.
This is very convenient for when you need to edit a shape and its gradient at the same time.
Unfortunately, when gradients control points are placed over a node, that node cant' be accessed anymore without first moving the gradient. Disabling gradient editing is the only way to get rid of this annoyance but you also loose the functionality.

Suggestions for when a gradient control point is placed over a node:
 - always move them together (convenient if you realy want this but annoying in all other cases);
 - give precedence to the node in node tool and to gradient's control point in gradient tool (I think it's what expected when using each tool);
 - let select and move both whith drag-select (so the first point can be achieved when needed, and also in cases where the control point is not over a node but you want to move it together with a bunch of nodes).

Thanks.

su_v (suv-lp)
tags: added: gradient node-editing ui
Changed in inkscape:
importance: Undecided → Wishlist
status: New → Confirmed
Revision history for this message
su_v (suv-lp) wrote :

<off-topic>
Note: IMHO this is a far more general UI issue. The same conflicts can occur with pattern handles and path effect knots (both types are always stacked on top of the path nodes), but for them there are no workarounds
 a) to disable the special knots rendered on top of the path nodes in the node tool context, as well as
 b) a special tool to edit the knots only
which exist for gradients.
</off-topic>

Revision history for this message
Krzysztof Kosinski (tweenk) wrote :

I think this could be solved by simply adding toggle buttons for the gradient and pattern editors. On the other hand, we already have too many buttons on the tool controls bar for the node tool.

Revision history for this message
ScislaC (scislac) wrote :

What about one button which handles both?

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

> this could be solved by simply adding toggle buttons for the gradient and pattern editors

What about the path effect handles? The existing toggle (to edit effect parameter paths) does not include knots e.g. used by the new Powerstroke path effect, or by the "Hatches (rough)" and "Knot" LPE - those are always present in the node tool context.

Maybe there could be a generic toggle in the node tool? e.g.:
- off (default): path nodes on top
- on: special nodes on top

Revision history for this message
David Mathog (mathog) wrote :

My preference regarding the gradient handles being visible during path node editing would be to not have them there. The current situation seems like poor UI design to me since it acts like the gradient tool is partially active. (The handles are visible, but the rest of the gradient toolbar is not.)

I really don't see the utility of the current situation since if either of the hidden path nodes is selected (by dragging a box around it), and then its position is adjusted with the keyboard arrow keys, the gradient ends do not move with it. And there is no problem getting the gradient handle back on top of those path nodes using the gradient tool - just set: "snap nodes, paths, and handles" and "snap cusp nodes, incl. rect corners", then move the handle nearby and it will snap on.

Revision history for this message
ScislaC (scislac) wrote :

David: This is a use case issue. As someone who primarily does design and illustration, having them available is a great convenience. When tweaking the appearance of something, it's handy to not have to switch tools. If your preference is to not have them there, double-click on the Node Tool button (in the Toolbox), and uncheck the preference for "Enable gradient editing".

Revision history for this message
David Mathog (mathog) wrote :

Why is "Enable gradient editing" the default setting?

Revision history for this message
ScislaC (scislac) wrote :

Likely because the feature is a convenience for a greater portion of the userbase than those who feel inconvenienced by it... and the feature was added by a designer if I recall correctly.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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