Re: [Gimp-developer] Blend Tool UI

[Michael Henning <drawoc darkrefraction com>]

mitch: The alt shortcut has always worked in my prototype. (You sound
like you might not have been aware of this in your email.)

I'm also not sure that the handle size should should necessarily be
consistent with other tools. Gradients have only two endpoints, while
paths or free selections can get significantly more complicated, which
I think justifies having larger handles.

Ofnuts: If a gradient is modified in any way, the preview will update properly.

Simon: Spherical and Dimpled are actually portions of sinusoids, not
quarter circles, but that might be what you meant.

So, the transformations functions look like this:
http://www.wolframalpha.com/input/?i=plot+1.0+-+sin%28x%29%2C+plot+cos%28x%29%2C++from+x+%3D+0+to+pi%2F2

I'm actually in favor of just removing the Spherical and Dimpled
versions of the shaped gradients. There's not too much to
differentiate between the three right now, and the transformation
functions seem a little silly to me.

I'd like to add in a euclidean-based shaped gradient though, and give
the user a choice between euclidean and manhattan distance metrics.
The manhattan ones aren't very useful alone.

On Wed, Jun 25, 2014 at 6:53 AM, peter sikking <peter mmiworks net> wrote:
> > Maybe drawing circles most of
> > the time, and then hiding the circles and switching to crosshairs
> > while dragging the points, would be good?
>
> the alignment of the endpoint with the underlying content needs
> to also be reviewed when not moving the point.

Fair enough.

> - make the control points big (30–50px diameter) and essentially
> transparent; clearly mark the centre where the co-ordinate is.

My first naive implementation looked like this:
http://i.imgur.com/ynQTFHi.png
Those handles tended to grab your attention away from the image too much.

I went back to my original ones briefly, and I have to admit that they
are definitely more difficult to grab than the larger ones.

So, I tinkered with them and came up with this:
http://i.imgur.com/RK0odEE.png

The user still has a 40 px grab target (the entire circle), but I now
hide the circle whenever the mouse isn't within 60px of the center of
the handle. So, they look quite minimal (just the cross) most of the
time, and the grabbable area is still large. I'm generally satisfied
with them.

> - you can drop the line because the gradient is there to
>  represent itself; saves on clutter.

I did remove the line, but I think I might like to add it back in if
nobody's strongly opposed. Here's why:

 * I feel like the handles are minimal enough, even with the line present.

 * I'd like to implement mitch's idea of being able to drag the line
to move both points at once.

 * apparently some people would miss the line (see Jason's post)

 * I'm planning on allowing the user to disable the preview, (which is
something that basically all of gimp's tools have, just in case the
user is working on a huge image where the preview would be painfully
slow to update), so we can't always rely on the user seeing the on
screen preview.

At the very least, we should show the line whenever the preview is hidden.

> OK, I should have consulted the manual and now I have done it.
>
> I am now completely convinced that the shape burst belongs
> in the gradient tool. there is nothing contradictory about
> that. the gradient tool applies a gradient fill (as everything:
> modified by the selection) and Shape is a fill ‘mode’.
>
> and when talking interactive: next move would be to control
> these funky fill shapes on the canvas with a handle or two.

Okay. I think I have a decent idea of how to control the shapebursts
with handles. I'm going to focus on getting the other gradients
working first though.

> Ofnuts wrote:
>
> > > good plan. combine it with updating the colours of the
> > > endpoints to make it truly adjustable to get it _right_
> >
> > This would be updating the gradient while using it, but a gradient can be much more complicated than one 
> > color at each end. And what do you do with gradient colors that are not explicit but bound to FG/BG colors?
>
> well, I imagined straightaway that the endpoints would be
> highlightable and then modifiable through the regular
> color selection dialog(s).
>
> this point -> that (adjusted) color
>
> a more complex gradient is defined by ‘waypoints’
>
> on the canvas, while working interactive, the position
> where these waypoints fall on the gradient can be shown.
>
> then each of them can be highlighted and color-adjusted.
>
> when the points are there anyway on the canvas, users can
> move them, in 2 dimensions.
>
> and gee, once you got that. users can build a complex
> gradient out of nothing by:
>
> - starting with a begin and end color;
>
> - set up a multi-point path (click, click, click,
>  double-click or return; to begin with: a straight-segment
>  path; intermediate colours get interpolated, based on
>  distance along the path)
>
> - update the points’ position and colours;
>
> - commit (another double-click or return).
>
> if this overloads Michael: you can introduce this step-by-step.
>
> I like where this is going...

Sigh. Alexandre's been asking for the same thing. I was hoping to move
on from the blend tool fairly quickly though, and spend some time
working on other things too.