RSS/Atom feed Twitter
Site is read-only, email is disabled

Blend Tool UI

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

19 of 19 messages available
Toggle history

Please log in to manage your subscriptions.

Blend Tool UI Michael Henning 23 Jun 03:31
  Blend Tool UI Joao S. O. Bueno 23 Jun 03:45
   Blend Tool UI scl 23 Jun 05:28
  Blend Tool UI scl 23 Jun 05:22
  Blend Tool UI Ofnuts 23 Jun 08:42
   Blend Tool UI Alexandre Prokoudine 23 Jun 08:46
  Blend Tool UI peter sikking 24 Jun 11:49
   Blend Tool UI Michael Henning 25 Jun 04:59
    Blend Tool UI peter sikking 25 Jun 10:53
     Blend Tool UI Simon Budig 25 Jun 11:12
     Blend Tool UI Alexandre Prokoudine 25 Jun 11:41
     Blend Tool UI Michael Natterer 25 Jun 14:39
      Blend Tool UI Jason van Gumster 26 Jun 14:33
     Blend Tool UI Michael Henning 29 Jun 19:08
      Blend Tool UI Ofnuts 29 Jun 21:19
       Blend Tool UI Saul Goode 29 Jun 22:18
       Blend Tool UI scl 30 Jun 04:09
    Blend Tool UI Joao S. O. Bueno 25 Jun 16:09
   Blend Tool UI Ofnuts 25 Jun 07:45
Michael Henning
2014-06-23 03:31:11 UTC (almost 10 years ago)

Blend Tool UI

I'd like to make some incremental improvements to the blend tool. On IRC, Alexandre suggested to get the UI team involved, so I'm looking for feedback/advice from the UI team.

Here are my general plans:

* I'd like to make the blend tool generally more interactive. By this, I mean that after the user has created a gradient, they will be presented with handles that they can use to modify the endpoints of the gradient before committing their changes.

* I'd also like to add a live preview to the blend tool so users can preview the gradient and experiment with different options, before committing their changes.

* I'm also planning to add undo support within the tool.

* The general consensus within the dev team seems to be that the shapebursts (all of the gradient types currently marked "shaped") should be moved out of the blend tool. They would likely be moved into either a menu item, or (maybe?) within the fill tool.

Any thoughts?

-- drawoc

Joao S. O. Bueno
2014-06-23 03:45:19 UTC (almost 10 years ago)

Blend Tool UI

On 23 June 2014 00:31, Michael Henning wrote:

I'd like to make some incremental improvements to the blend tool. On IRC, Alexandre suggested to get the UI team involved, so I'm looking for feedback/advice from the UI team.

Here are my general plans:

* I'd like to make the blend tool generally more interactive. By this, I mean that after the user has created a gradient, they will be presented with handles that they can use to modify the endpoints of the gradient before committing their changes.

I don't quite nderstand what you mean by "commiting changes" - as of now, gradients as all GIMP assts are all updated in realtime - You move a handle, that is the valid value for that gradient right now, for all purposes: that is, you make a move, you "commit" it.

Having undo and redo steps on possible on the gradient window would be great,

* I'd also like to add a live preview to the blend tool so users can preview the gradient and experiment with different options, before committing their changes.

You mean a radial and square previews, beyond the existing linear preview?

* I'm also planning to add undo support within the tool.

Yes - that would be great! I guess you mean within the "gradient editor dialog", not for the blending tool itself.

* The general consensus within the dev team seems to be that the shapebursts (all of the gradient types currently marked "shaped") should be moved out of the blend tool. They would likely be moved into either a menu item, or (maybe?) within the fill tool.

Not sure. One thing they lack is more control: the offset shuldbe vaid for them -
otherwise, when using these in a workflow, I think of different shaopes for the blending tool, not
anything else.
The fact that they currently take no advantage on the point one click, to the point one drag is more
motive to improve on that, within the blending tool, than to turn then into dumb menu entries, I think.

However,a "shape fill" tool, which could not only fill an area with a gradient, but also with a pattern
(a selection copied from somewhere else) would be great. Then, gradient shapes could be aggregated there, and GIMP would finally match the feature which was present in 1986's Deluxe Paint .

But again: I don't think moving it out of the blending shape options, just for ding so, is a nice idea.

js ->

Any thoughts?

-- drawoc
_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list

scl
2014-06-23 05:22:15 UTC (almost 10 years ago)

Blend Tool UI

Hi,

first of all thank you for your efforts and the posting. In general I like the ideas.

On 23.6.2014 at 5:31 AM Michael Henning wrote:

I'd like to make some incremental improvements to the blend tool. On IRC, Alexandre suggested to get the UI team involved, so I'm looking for feedback/advice from the UI team.

The UI team sits in Berlin and is named Peter Sikking ;-) You might have luck by sending him an e-mail.

Here are my general plans:

* I'd like to make the blend tool generally more interactive. By this, I mean that after the user has created a gradient, they will be presented with handles that they can use to modify the endpoints of the gradient before committing their changes.

* I'd also like to add a live preview to the blend tool so users can preview the gradient and experiment with different options, before committing their changes.

* I'm also planning to add undo support within the tool.

That's all fine!

* The general consensus within the dev team seems to be that the shapebursts (all of the gradient types currently marked "shaped") should be moved out of the blend tool. They would likely be moved into either a menu item, or (maybe?) within the fill tool.

I only remember a conversation between you and Mitch in IRC. To get a general consensus this place seems more suitable (thank you Alex).

Do you mean all shapes in the tool's options or only those whose name starts with 'Shaped'?

Why should they be moved out of the Blend tool?

As we are just improving this tool's interaction, there are some evaluation notes as input for our work:

http://gui.gimp.org/index.php/Evaluation_Notes_-_Photo_Composing#Blend_-_Gradient_tool

http://gui.gimp.org/index.php/Evaluation_Notes_-_Creating_Web_Images#Gradient_tool

I could not find any specs nor at a glance any open, influencing bugs.

Kind regards,

Sven

scl
2014-06-23 05:28:29 UTC (almost 10 years ago)

Blend Tool UI

On 23.6.2014 at 5:45 AM Joao S. O. Bueno wrote:

However,a "shape fill" tool, which could not only fill an area with a gradient, but also with a pattern
(a selection copied from somewhere else) would be great.

Are you perhaps looking for the Bucket Fill Tool's fill type 'Pattern fill'? Its first item is a pattern from the clipboard.

Or did you mean to distort the fill pattern to make it fit into the selection's shape?

Kind regards,

Sven

Ofnuts
2014-06-23 08:42:21 UTC (almost 10 years ago)

Blend Tool UI

On 23/06/14 05:31, Michael Henning wrote:

I'd like to make some incremental improvements to the blend tool. On IRC, Alexandre suggested to get the UI team involved, so I'm looking for feedback/advice from the UI team.

Here are my general plans:

* I'd like to make the blend tool generally more interactive. By this, I mean that after the user has created a gradient, they will be presented with handles that they can use to modify the endpoints of the gradient before committing their changes.

* I'd also like to add a live preview to the blend tool so users can preview the gradient and experiment with different options, before committing their changes.

* I'm also planning to add undo support within the tool.

* The general consensus within the dev team seems to be that the shapebursts (all of the gradient types currently marked "shaped") should be moved out of the blend tool. They would likely be moved into either a menu item, or (maybe?) within the fill tool.

Any thoughts?

I like the idea.

If you have a "live preview", do you really need the handles to change it afterwards? IMHO it would be one or the other, and a live preview would be best (I've long been dreaming of seeing in real time gradients applied to layer masks).

Yes, shaped gradients are an oddity, but they would also be a bit out of place in the bucket-fill (unless this can be applied to other fillings). This would also require a new gradient icon in a rather busy Tool options dialog. At least in the Blend tool they are in a tool that deals with gradients. But would we need a "tool" for this? The UI is minimal since it is just applying the current gradient to the selection. A filter in Filters>Render perhaps?

Alexandre Prokoudine
2014-06-23 08:46:28 UTC (almost 10 years ago)

Blend Tool UI

On Mon, Jun 23, 2014 at 12:42 PM, Ofnuts wrote:

If you have a "live preview", do you really need the handles to change it afterwards?

Absolutely. In a non-destructive workflow users should be able to tweak gradients at any time.

Personally, I think that this tool should also have Inkscape-like on-canvas editing of color stops (adding, removing, multi-selecting, shifting). But this is currently out of scope of Michael's work -- at least, that's what he told me :)

Alexandre

peter sikking
2014-06-24 11:49:02 UTC (almost 10 years ago)

Blend Tool UI

Michael Henning wrote:

I'd like to make some incremental improvements to the blend tool. On IRC, Alexandre suggested to get the UI team involved, so I'm looking for feedback/advice from the UI team.

lets see how I can help you.

Here are my general plans:

* I'd like to make the blend tool generally more interactive. By this, I mean that after the user has created a gradient, they will be presented with handles that they can use to modify the endpoints of the gradient before committing their changes.

good plan. combine it with updating the colours of the endpoints to make it truly adjustable to get it _right_

hint: please do not make the endpoint handles small; think generous (more tens of pixels than single digits) and also show where the exact endpoint is in the centre of the handle (say, with a cross to aim).

* I'd also like to add a live preview to the blend tool so users can preview the gradient and experiment with different options, before committing their changes.

yes, vital for making the previous point work.

please make commit an implicit thing (moving on to another tool, starting another gradient) combined with explicit (e.g. ) as a backup. see handling of committing selections in the rectangular selection tool.

* I'm also planning to add undo support within the tool.

I hope you mean: step-by-step undo while not committed, after a commit undo the whole committed gradient.

again: vital, to make other points above _really_ work. both for the interactive part and as a form of non-committing

* The general consensus within the dev team seems to be that the shapebursts (all of the gradient types currently marked "shaped") should be moved out of the blend tool. They would likely be moved into either a menu item, or (maybe?) within the fill tool.

as far as my thoughts go: there will be more working with (vector) shapes in the future, and modifying those shapes with a gradient fill (by the gradient tool) could be the way to handle that.

--ps

founder + principal interaction architect man + machine interface works

http://blog.mmiworks.net: on interaction architecture

Michael Henning
2014-06-25 04:59:46 UTC (almost 10 years ago)

Blend Tool UI

Joao: You might have misunderstood me. I'm referring to the blend tool, not the gradient editor.

scl: Just the ones whose name starts with 'Shaped'.

Ofnuts: Yes, Filters>Render is probably a better place than the bucket tool, if we do move the shapebursts.

Alexandre: I'm hoping to also hook up the live preview to update along with any modifications of the gradient that happen in the gradient editor. It isn't quite the same as on-canvas editing of color stops, but if you're doing that sort of work, it should become it a lot nicer.

peter:
On Tue, Jun 24, 2014 at 7:49 AM, peter sikking wrote:

Michael Henning wrote:

* I'd like to make the blend tool generally more interactive. By this, I mean that after the user has created a gradient, they will be presented with handles that they can use to modify the endpoints of the gradient before committing their changes.

good plan. combine it with updating the colours of the endpoints to make it truly adjustable to get it _right_

hint: please do not make the endpoint handles small; think generous (more tens of pixels than single digits) and also show where the exact endpoint is in the centre of the handle (say, with a cross to aim).

I had been imagining selection handles that are simply filled circles. In my early prototype, they look like this: http://i.imgur.com/t4g1zOE.png

I think they are big enough, but they don't really show the exact location of the endpoint. I guess I'll need to experiment with this more.

I have a feeling that If I make them circle outlines with crosshairs in them, they'll look cluttered. Having just crosshairs won't make it obvious that you can drag the points. Maybe drawing circles most of the time, and then hiding the circles and switching to crosshairs while dragging the points, would be good? (The idea is to show the precise handles when they're needed during dragging, and then switch to handles that invite grabbing for the remainder of the time.)

* I'd also like to add a live preview to the blend tool so users can preview the gradient and experiment with different options, before committing their changes.

yes, vital for making the previous point work.

please make commit an implicit thing (moving on to another tool, starting another gradient) combined with explicit (e.g. ) as a backup. see handling of committing selections in the rectangular selection tool.

Agreed. I wasn't planning to make starting another gradient commit the first, but now that I think about it, that does make more sense.

* I'm also planning to add undo support within the tool.

I hope you mean: step-by-step undo while not committed, after a commit undo the whole committed gradient.

Yes, that's exactly the plan.

again: vital, to make other points above _really_ work. both for the interactive part and as a form of non-committing

* The general consensus within the dev team seems to be that the shapebursts (all of the gradient types currently marked "shaped") should be moved out of the blend tool. They would likely be moved into either a menu item, or (maybe?) within the fill tool.

as far as my thoughts go: there will be more working with (vector) shapes in the future, and modifying those shapes with a gradient fill (by the gradient tool) could be the way to handle that.

Hmm, you might have misunderstood what I meant by shapebursts. The shapebursts are special gradients that mimic the shape of your selection (currently labeled "Shaped (angular)", "Shaped (spherical)", and "Shaped (dimpled)"). Anyway, at this point I'm really conflicted as to what should be done with them. I'm not sure whether they belong in the blend tool or not right now.

Anyway, thanks for the input.

-- drawoc

Ofnuts
2014-06-25 07:45:55 UTC (almost 10 years ago)

Blend Tool UI

On 24/06/14 13:49, peter sikking wrote:

Michael Henning wrote:

Here are my general plans:

* I'd like to make the blend tool generally more interactive. By this, I mean that after the user has created a gradient, they will be presented with handles that they can use to modify the endpoints of the gradient before committing their changes.

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?

peter sikking
2014-06-25 10:53:03 UTC (almost 10 years ago)

Blend Tool UI

Michael wrote:

hint: please do not make the endpoint handles small; think generous (more tens of pixels than single digits) and also show where the exact endpoint is in the centre of the handle (say, with a cross to aim).

I had been imagining selection handles that are simply filled circles. In my early prototype, they look like this: http://i.imgur.com/t4g1zOE.png

I think they are big enough, but they don't really show the exact location of the endpoint. I guess I'll need to experiment with this more.

sorry, they are not big enough for the speed of working that is required of a tool like GIMP.

remember, at that moment all that counts for users is reviewing the gradient and adjusting it.

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

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

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.

* The general consensus within the dev team seems to be that the shapebursts (all of the gradient types currently marked "shaped") should be moved out of the blend tool. They would likely be moved into either a menu item, or (maybe?) within the fill tool.

as far as my thoughts go: there will be more working with (vector) shapes in the future, and modifying those shapes with a gradient fill (by the gradient tool) could be the way to handle that.

Hmm, you might have misunderstood what I meant by shapebursts. The shapebursts are special gradients that mimic the shape of your selection (currently labeled "Shaped (angular)", "Shaped (spherical)", and "Shaped (dimpled)"). Anyway, at this point I'm really conflicted as to what should be done with them. I'm not sure whether they belong in the blend tool or not right now.

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.

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...

--ps

founder + principal interaction architect man + machine interface works

http://blog.mmiworks.net: on interaction architecture

Simon Budig
2014-06-25 11:12:33 UTC (almost 10 years ago)

Blend Tool UI

peter sikking (peter@mmiworks.net) wrote:

Hmm, you might have misunderstood what I meant by shapebursts. The shapebursts are special gradients that mimic the shape of your selection (currently labeled "Shaped (angular)", "Shaped (spherical)", and "Shaped (dimpled)"). Anyway, at this point I'm really conflicted as to what should be done with them. I'm not sure whether they belong in the blend tool or not right now.

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.

A little background on shapeburst modes to get an idea about what might be adjustable by the user.

When filling with a shapeburst mode, a distance map is computed, where for each somewhat-selected pixel a distance to the nearest unselected pixel is computed. The "distance" is computed using a manhattan metrics (dx+dy), with some funky shit for partially selected pixels. For the latter part I am currently not convinced that it works correctly and consistent.

Computing the distance map is an expensive operation (and unfortunately the manhattan-metrics approach introduces some quite visible weird unexpected artefacts). But this actually needs to be done only when the selection changes, I think right now it is computed every time.

A huge improvement would be to change the distance metrics to something euclidean. That'd give way more predictable and useful results. However, this is not easy at all apparently...

The currently selected gradient is then mapped to the distance (think gradient-map). The "angular", "spherical" and "dimpled" variants are basically specifying what function is used to map the distance to a position in the gradient.

This *could* be something more funky, similiar to how I used the curves tool to determine the shape of the golden text in my ancient golden-text-tutorial: http://www.home.unix-ag.org/simon/gimp/golden2.html

"angular" would be a linear mapping and I believe that "spherical" and "dimpled" basically would be quarter-circle mappings (in different directions).

Changing this to a generic (editable?) curve should be fairly straightforward.

Bye,
Simon

simon@budig.de              http://simon.budig.de/
Alexandre Prokoudine
2014-06-25 11:41:13 UTC (almost 10 years ago)

Blend Tool UI

On Wed, Jun 25, 2014 at 2:53 PM, peter sikking wrote:

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

A word of warning: this is going to be the next save/export controversy. Designers are quite anal (pardon my Klatchian) about that sort of thing. Inkscape used to be mocked for large on-canvas controls, the team even made their size configurable in upcoming v0.91, and the first thing I personally did is making controls one step smaller. If that is possible to do, I would humbly suggest doing a research, unless, of course, you have data on your hands that this sort of large controls is exactly what end-users need (Hi-DPI displays taken into consideration, of course).

Alex

Michael Natterer
2014-06-25 14:39:52 UTC (almost 10 years ago)

Blend Tool UI

On Wed, 2014-06-25 at 12:53 +0200, peter sikking wrote:

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

I would rather keep the line, but make it draggable. The first thing I found missing when trying the new tool was a way to move both control points at the same time. We could use our default Alt-Modifier for that, but I think simply dragging the line is more natural and obvious, especially when hinted by hover effects like the line changing and/or the mouse cursor changing.

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

Not so sure about this, but has to be tried. I personally prefer smaller control points, but that might change when experimenting around.

In any case I'm pretty sure that the handle size should be consistent with other tools that use "line and handles" UI, such as vectors or free select.

--mitch

Joao S. O. Bueno
2014-06-25 16:09:18 UTC (almost 10 years ago)

Blend Tool UI

On 25 June 2014 01:59, Michael Henning wrote:

Joao: You might have misunderstood me. I'm referring to the blend tool, not the gradient editor.

Yes . I indeed was thinking about the gradient editor - just later I realized it was the
actual application of the gradient on Canvas.

My comment about the "shapped" ones however is valid - I think they should stay, even if terhe
is no possible action for the time being. The shaped blends do require control as well, and it would be nice if we could be work ont hat for the future. If you look there, there is an open bug
about the "offset" parameter not being used in the shapped fills (and the ending point is actually ignored). Maybe, adding some control there, the 3 "shaped..." fills could be made into a single one.

https://bugzilla.gnome.org/show_bug.cgi?id=505755

js ->

scl: Just the ones whose name starts with 'Shaped'.

Ofnuts: Yes, Filters>Render is probably a better place than the bucket tool, if we do move the shapebursts.

Alexandre: I'm hoping to also hook up the live preview to update along with any modifications of the gradient that happen in the gradient editor. It isn't quite the same as on-canvas editing of color stops, but if you're doing that sort of work, it should become it a lot nicer.

peter:
On Tue, Jun 24, 2014 at 7:49 AM, peter sikking wrote:

Michael Henning wrote:

* I'd like to make the blend tool generally more interactive. By this, I mean that after the user has created a gradient, they will be presented with handles that they can use to modify the endpoints of the gradient before committing their changes.

good plan. combine it with updating the colours of the endpoints to make it truly adjustable to get it _right_

hint: please do not make the endpoint handles small; think generous (more tens of pixels than single digits) and also show where the exact endpoint is in the centre of the handle (say, with a cross to aim).

I had been imagining selection handles that are simply filled circles. In my early prototype, they look like this: http://i.imgur.com/t4g1zOE.png

I think they are big enough, but they don't really show the exact location of the endpoint. I guess I'll need to experiment with this more.

I have a feeling that If I make them circle outlines with crosshairs in them, they'll look cluttered. Having just crosshairs won't make it obvious that you can drag the points. Maybe drawing circles most of the time, and then hiding the circles and switching to crosshairs while dragging the points, would be good? (The idea is to show the precise handles when they're needed during dragging, and then switch to handles that invite grabbing for the remainder of the time.)

* I'd also like to add a live preview to the blend tool so users can preview the gradient and experiment with different options, before committing their changes.

yes, vital for making the previous point work.

please make commit an implicit thing (moving on to another tool, starting another gradient) combined with explicit (e.g. ) as a backup. see handling of committing selections in the rectangular selection tool.

Agreed. I wasn't planning to make starting another gradient commit the first, but now that I think about it, that does make more sense.

* I'm also planning to add undo support within the tool.

I hope you mean: step-by-step undo while not committed, after a commit undo the whole committed gradient.

Yes, that's exactly the plan.

again: vital, to make other points above _really_ work. both for the interactive part and as a form of non-committing

* The general consensus within the dev team seems to be that the shapebursts (all of the gradient types currently marked "shaped") should be moved out of the blend tool. They would likely be moved into either a menu item, or (maybe?) within the fill tool.

as far as my thoughts go: there will be more working with (vector) shapes in the future, and modifying those shapes with a gradient fill (by the gradient tool) could be the way to handle that.

Hmm, you might have misunderstood what I meant by shapebursts. The shapebursts are special gradients that mimic the shape of your selection (currently labeled "Shaped (angular)", "Shaped (spherical)", and "Shaped (dimpled)"). Anyway, at this point I'm really conflicted as to what should be done with them. I'm not sure whether they belong in the blend tool or not right now.

Anyway, thanks for the input.

-- drawoc _______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list

Jason van Gumster
2014-06-26 14:33:19 UTC (almost 10 years ago)

Blend Tool UI

Michael Natterer wrote:

On Wed, 2014-06-25 at 12:53 +0200, peter sikking wrote:

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

I would rather keep the line, but make it draggable. The first thing I found missing when trying the new tool was a way to move both control points at the same time. We could use our default Alt-Modifier for that, but I think simply dragging the line is more natural and obvious, especially when hinted by hover effects like the line changing and/or the mouse cursor changing.

Additionally, the line is useful for determining the slope of the gradient. Frequently I need a gradient to match a specific angle of something else in my image (or be perfectly orthogonal). The line helps visualize this.

-Jason

Michael Henning
2014-06-29 19:08:22 UTC (over 9 years ago)

Blend Tool UI

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 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.

Ofnuts
2014-06-29 21:19:17 UTC (over 9 years ago)

Blend Tool UI

On 29/06/14 21:08, Michael Henning wrote:

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 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...

I'm not convinced that shape bursts still need a complicated UI or many fill options. Once you have a nice clean black-to-white linear fill you can always use the Levels or Curves (or a gradient map) on it to achieve whatever you want. It is possible that in the 8-bit world inaccuracies and round-off errors make it useful to produce directly some specific shapes but with 16- or 32-bit processing this could no longer be necessary.

Saul Goode
2014-06-29 22:18:42 UTC (over 9 years ago)

Blend Tool UI

I like the idea of shaped gradients being handled in the Blend Tool. If the length of the stroke determines the maximum distance from the selection boundary, it would provide a quick means of stroking the selection or creating shadows and highlights with interactive control of the thickness.

With regard to moving the blend stroke, I think that ALT+drag should be required, to be consistent with the behavior of the Vectors Tool. For further consistency with the Vectors Tool, CTRL-drag on the blend stroke should add a new stop and then repositioning all the stops while dragging. With no modifier key pressed while dragging along the blend stroke, no new stop should be created and the existing stops should repositioned based on the drag.

Any mouse drags that are not on the blend stroke or its endpoints should result in the existing blend being committed and a new one commenced. However, a mouse click by itself that is not on the blend stroke or one of its endpoints should result in just the blend being committed.

scl
2014-06-30 04:09:33 UTC (over 9 years ago)

Blend Tool UI

On 29.6.2014 at 11:19 PM Ofnuts wrote:

I'm not convinced that shape bursts still need a complicated UI.

+1

Once you have a nice clean black-to-white linear fill you can always use the Levels or Curves (or a gradient map) on it to achieve whatever you want.

How would you bend and distort a straight linear fill (i.e. from left to right) to make it fit into an arbitrary shape with the Levels or Curves tool? They are Color tools and all they can do are tonal corrections. In our case they can only shift the gradient a bit more to the left or right or make it wider or slimer.

I think in the context of gradient fill these tools a) don't meet the needs (see above), b) they add an extra step. Modifying a linear, circular etc. gradient with handles, but other gradient shapes with the Color tools is simply confusing. Extra steps also impede the users in working fastly. Therefore Color tools can be taken as optional step for fine tuning a gradient, but never be part of the default filling workflow.

I also agree that too many options are more confusing than helpful, but let's not drop useful functionality.

Kind regards,

Sven