On Sun, 06 Mar 2005 23:19:26 +0100, Jakub Steiner <jimmac@...653...> wrote:

My question is exactly the other way around. If node editing tool is for editing a shape, why have it define a gradient?

In Sodipodi, you had to switch to node edit after having created a rectangle if you wanted to round corners. The rect tool could create a rect but not edit it. That was obviously crazy. I fixed that.

Then we added on-canvas editing of pattern fills. It shows up whenever you have the shape handles or nodes (i.e. in node tool and all shape tools). This turned out to be quite convenient (at least for me).

Now with gradients, I just followed the general trend, which is this: Each tool _creates_ objects of its type and allows for precise numerical control of them, but simple on-canvas _editing_ should be available everywhere for all objects. I think this is a good idea overall, though obviously in some cases it may lead to too much stuff on canvas. I don't think however that gradients are one of these cases.

Does anyone else have an opinion?

sure about other artists, but I have a workflow where I first worry about the shape and later on worry about the shading. I have no need to be doing both at the same time.

I often adjust shape and fill at the same time, and not having to switch tools is convenient for me.

...

What about this: when no gradient handles are selected (all are white), it works as now. When a handle is selected (blue), the list will show (and let you change) the gradient definition for that handle's gradient.

I fear this behavior isn't exactly obvious.

Seeing that something is selected (blue) and assuming that the "Change" controls affect the selected thing is much more obvious IMHO than having some obscure "mode switch" in the toolbar.

What does showing both fill and stroke gradients at the same time give you?

It gives consistency and simplicity, above all. I select an object and I see _all_ of its gradients without having to think about modes and such.

The only thing obvious to me is locking the vector of both gradients to be precisely the same.

Yes, this is an advantage too.

Yet this is hardly an advantage even if it wasn't limited for both having the same gradient applied (which is truly useless).

It's not _thus_ limited. You can assign the different definitions to the gradients first and merge them after that. Even simpler, you can easily shift-drag one of the merged handles away, apply a different gradient to it, then merge it back. Then you will still be able to drag the merged gradients together, even though they will now have different gradient definitions. So it's not even a limitation, just a minor inconvenience.

I'm not saying there isn't any. I just don't see it and I'm asking for a use scenario.

You said yourself (below) that merging gradients from different objects is useful. Now imagine that one of the objects is a fillless stroke and the other is a strokeless fill. I want to form a "virtual object" out of them by merging their gradient handles. With your proposal ("modes") this would be impossible - not just inconvenient but impossible.

I understand you have all this coded and you are motivated to justify this design. In the end I will accept whatever there is, since I hardly have any choice, but I strongly believe separating the two will lead to a better interface that gives feedback on what's happening.

I think it will just add a redundant control which will make the whole system less obvious and less discoverable by novices. I don't see what is the additional feedback that it will give you which my system would not give.

Snapping within multiple objects is useful for having a multiple object form a "virtual" object. You may want to draw a car body structure and keep the dashers separate. So the objects share the same shading.

I don't see the need for having a precise snapping of stroke/fill gradients if the gradient is supposed to be the same. In the end it just gives the same result as having the object have no stroke.

1) Gradient definition does not have to be the same (see above)

2) Even if it's not useful for the same object's fill and stroke (I'm not sure why you think so, but OK), I think you can easily imagine wanting to form a "virtual object" from some objects without fill and others without stroke.

...

Can you explain why would you need to switch a gradient from linear to radial, preserving the handle positions? This seems far-fetched to me. Why is this any better than simply drawing a new radial gradient for the same objects instead?

See yourself adding the "New:" label? The interface doesn't speak on its own, you had to describe its behavior because clicking on the button doesn't give immediate feedback. You are right that in most cases I continue to redesign the gradient placement, but the interface gave me an immediate feedback on my actions as opposed to the current design.

Even if I add a button to switch the selected gradient between linear and radial, this would be a separate button from the one which governs the newly created gradient. (Or are you proposing to always create linear and then, if needed, switch it to radial? That would be quite cumbersome.) And since the usefullness of the radial/linear switch for _existing_ gradients is not obvious to me, I think leaving only the control for _newly created_ gradients makes sense and reduces clutter.

The fact that the "New:" part applies to newly created gradients is explained in the tooltips. Besides, this is consistent with the shape tools which, too, display "New:" when no objects of their type are selected, in which case adjusting the controls will affect newly created objects.