Re: [Gimp-developer] Blend Tool UI

2014-06-29 Thread Michael Henning
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 pe...@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 

Re: [Gimp-developer] Blend Tool UI

2014-06-29 Thread Ofnuts

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

Re: [Gimp-developer] Blend Tool UI

2014-06-29 Thread Saul Goode
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. 
___
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


Re: [Gimp-developer] Blend Tool UI

2014-06-29 Thread scl


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


___
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


Re: [Gimp-developer] Blend Tool UI

2014-06-26 Thread Jason van Gumster

Michael Natterer mi...@gimp.org 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
___
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


Re: [Gimp-developer] Blend Tool UI

2014-06-25 Thread Ofnuts

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?

___
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


Re: [Gimp-developer] Blend Tool UI

2014-06-25 Thread peter sikking
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 (30–50px 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



___
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


Re: [Gimp-developer] Blend Tool UI

2014-06-25 Thread Simon Budig
peter sikking (pe...@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
-- 
  si...@budig.de  http://simon.budig.de/
___
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


Re: [Gimp-developer] Blend Tool UI

2014-06-25 Thread Alexandre Prokoudine
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
___
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


Re: [Gimp-developer] Blend Tool UI

2014-06-25 Thread Michael Natterer
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


___
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


Re: [Gimp-developer] Blend Tool UI

2014-06-25 Thread Joao S. O. Bueno
On 25 June 2014 01:59, Michael Henning dra...@darkrefraction.com 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, FiltersRender 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 pe...@mmiworks.net 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. return) 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
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: 

Re: [Gimp-developer] Blend Tool UI

2014-06-24 Thread peter sikking
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.

let’s 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. return) 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



___
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


Re: [Gimp-developer] Blend Tool UI

2014-06-24 Thread Michael Henning
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, FiltersRender 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 pe...@mmiworks.net 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. return) 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


Re: [Gimp-developer] Blend Tool UI

2014-06-23 Thread Ofnuts

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 FiltersRender perhaps?



___
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


Re: [Gimp-developer] Blend Tool UI

2014-06-23 Thread Alexandre Prokoudine
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
___
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


[Gimp-developer] Blend Tool UI

2014-06-22 Thread Michael Henning
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
___
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


Re: [Gimp-developer] Blend Tool UI

2014-06-22 Thread Joao S. O. Bueno
On 23 June 2014 00:31, Michael Henning dra...@darkrefraction.com 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
___
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


Re: [Gimp-developer] Blend Tool UI

2014-06-22 Thread scl

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

___
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


Re: [Gimp-developer] Blend Tool UI

2014-06-22 Thread scl

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




___
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