shaunak writes:

I notice that there are two "cursors" that appear while using the new sliders. One is an "up" arrow that allows me to quickly change from 0 - 100 (Like the old slider) and another is the "double side arrow" cursor that makes only small changes. I can see how this is useful but I cant seem to figure out how to get one to show over the other.

The fast moving (up-arrow) slider appears when you have your mouse in the top half of the slider area. The slow moving (horizontal arrows) appear when you are in the lower half of the area. It is new behavior to learn, but it will become second nature eventually.

Regards,

Jeff

On 12/04/12 00:28, Jeffery Small wrote:

shaunak writes:

I notice that there are two "cursors" that appear while using the new sliders. One is an "up" arrow that allows me to quickly change from 0 - 100 (Like the old slider) and another is the "double side arrow" cursor that makes only small changes. I can see how this is useful but I cant seem to figure out how to get one to show over the other.

The fast moving (up-arrow) slider appears when you have your mouse in the top half of the slider area. The slow moving (horizontal arrows) appear when you are in the lower half of the area. It is new behavior to learn, but it will become second nature eventually.

On freebsd, I get both arrows as described, but *both* of them do the fine- grained increments. Is there a setting that controls this, or is this a bug?

Gary

On Wed, Dec 5, 2012 at 10:32 PM, Gary Aitken wrote:

The fast moving (up-arrow) slider appears when you have your mouse in the top half of the slider area. The slow moving (horizontal arrows) appear when you are in the lower half of the area. It is new behavior to learn, but it will become second nature eventually.

On freebsd, I get both arrows as described, but *both* of them do the fine- grained increments. Is there a setting that controls this, or is this a bug?

Definitely a bug.

Alexandre Prokoudine http://libregraphicsworld.org

On Wed, 2012-12-05 at 11:32 -0700, Gary Aitken wrote:

On 12/04/12 00:28, Jeffery Small wrote:

The fast moving (up-arrow) slider appears when you have your mouse in the top half of the slider area. The slow moving (horizontal arrows) appear when you are in the lower half of the area. It is new behavior to learn, but it will become second nature eventually.

On freebsd, I get both arrows as described, but *both* of them do the fine- grained increments. Is there a setting that controls this, or is this a bug?

To be clear, see the enclosed image. The slider with the word Threshold on it is an example.

Hovering the mouse pointer in the upper half, e.g. over the word Threshold, changes the mouse pointer to an upwards pointing arrow; clicking in the bar when the mouse pointer displays the upwards arrow will set the amount directly: clicking on the left of the top-half of the bar will set Threshold to 0, clicking on the right (over the 81.5 in this example) sets it to around the maximum of 255, clicking in the middle (e.g.just under the "g" of "sample merged") sets it to about half, or 127. Dragging in this mode will drag the edge of the shaded bar directly.

When the mouse pointer is in the lower half of the bar, e.g. in the shaded area under the word Threshold, the mouse pointer is shown with a cursor made of a horizontal arrow pointing both left and right. In this mode, dragging in the bottom half of the area will select the number (81.5 in the image I attached to this message) and the number will change as you drag.

In addition, there are two small arrows to the right of the number, and clicking on those will increase or reduce the number shown. But those are not the arrows being discussed in this thread :-)

I hope this helps.

Liam

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

* Liam R E Quin [12-05-12 13:48]:

On Wed, 2012-12-05 at 11:32 -0700, Gary Aitken wrote:

On 12/04/12 00:28, Jeffery Small wrote:

The fast moving (up-arrow) slider appears when you have your mouse in the top half of the slider area. The slow moving (horizontal arrows) appear when you are in the lower half of the area. It is new behavior to learn, but it will become second nature eventually.

On freebsd, I get both arrows as described, but *both* of them do the fine- grained increments. Is there a setting that controls this, or is this a bug?

To be clear, see the enclosed image. The slider with the word Threshold on it is an example.

Hovering the mouse pointer in the upper half, e.g. over the word Threshold, changes the mouse pointer to an upwards pointing arrow; clicking in the bar when the mouse pointer displays the upwards arrow will set the amount directly: clicking on the left of the top-half of the bar will set Threshold to 0, clicking on the right (over the 81.5 in this example) sets it to around the maximum of 255, clicking in the middle (e.g.just under the "g" of "sample merged") sets it to about half, or 127. Dragging in this mode will drag the edge of the shaded bar directly.

When the mouse pointer is in the lower half of the bar, e.g. in the shaded area under the word Threshold, the mouse pointer is shown with a cursor made of a horizontal arrow pointing both left and right. In this mode, dragging in the bottom half of the area will select the number (81.5 in the image I attached to this message) and the number will change as you drag.

In addition, there are two small arrows to the right of the number, and clicking on those will increase or reduce the number shown. But those are not the arrows being discussed in this thread :-)

I would have expected the mouse wheel to act the same but it increments/ decrements at 1% intervals in both areas, upper/lower.

(paka)Patrick Shanahan       Plainfield, Indiana, USA      HOG # US1244711
http://wahoo.no-ip.org        Photo Album: http://wahoo.no-ip.org/gallery2
http://en.opensuse.org                           openSUSE Community Member
Registered Linux User #207535                    @ http://linuxcounter.net

On 12/05/12 11:45, Liam R E Quin wrote:

On Wed, 2012-12-05 at 11:32 -0700, Gary Aitken wrote:

On 12/04/12 00:28, Jeffery Small wrote:

The fast moving (up-arrow) slider appears when you have your mouse in the top half of the slider area. The slow moving (horizontal arrows) appear when you are in the lower half of the area. It is new behavior to learn, but it will become second nature eventually.

On freebsd, I get both arrows as described, but *both* of them do the fine- grained increments. Is there a setting that controls this, or is this a bug?

To be clear, see the enclosed image. The slider with the word Threshold on it is an example.

Hovering the mouse pointer in the upper half, e.g. over the word Threshold, changes the mouse pointer to an upwards pointing arrow; clicking in the bar when the mouse pointer displays the upwards arrow will set the amount directly: clicking on the left of the top-half of the bar will set Threshold to 0, clicking on the right (over the 81.5 in this example) sets it to around the maximum of 255, clicking in the middle (e.g.just under the "g" of "sample merged") sets it to about half, or 127. Dragging in this mode will drag the edge of the shaded bar directly.

When the mouse pointer is in the lower half of the bar, e.g. in the shaded area under the word Threshold, the mouse pointer is shown with a cursor made of a horizontal arrow pointing both left and right. In this mode, dragging in the bottom half of the area will select the number (81.5 in the image I attached to this message) and the number will change as you drag.

The behavior I am seeing under freebsd is as follows:

In the upper half, I get the up-arrow mouse pointer. Pressing and dragging that up-arrow mouse pointer changes the value in gross, non-integral increments. When moved from the extreme left to the extreme right, the range covered is large -- If I have the paintbrush tool options up, the size ranges from 1.00 at the extreme left to 1074.55 at the extreme right, although it may be dragged clear across the screen to get much larger values (9491.50 at my right screen limit in this case. Hmmm... If I test the fuzzy select tool as in your image, it goes from 0.0 at the extreme left to 255.0 at the extreme right, where it is clamped at that maximum value -- dragging further across the display causes no further increase.

In the lower half, I get the left-right mouse pointer. Pressing and dragging that left-right mouse pointer changes the value in small, non-integral increments. Depending on what the current value is, the possible range varies. If I type in the value 500 to set the value, then grab at the approximate location of the vertical dividing line between the grey and white areas, I get a range of approx 448.56 to 564.11, but if dragged clear across the display it will go up to approx 1400.

So two thoughts:

1. Should the integral behavior I am seeing with the up-arrow on the threshold for fuzzy select be going by tenths, or by whole integers?

2. It looks like the bug may be tool-related.

Gary

On 12/05/2012 10:45 AM, Liam R E Quin wrote

To be clear, see the enclosed image. The slider with the word Threshold on it is an example.

How about --

On Wed, 2012-12-05 at 12:38 -0700, Gary Aitken wrote:

So two thoughts:

1. Should the integral behavior I am seeing with the up-arrow on the threshold for fuzzy select be going by tenths, or by whole integers?

Neither, it depends on the width of the toolbox.

It should go up or down by distance you drag as a percentage of the max value, times max value E.g. when the up arrow is one third the way along from the left of the scrollbar-thingy, clicking (or dragging at that point, it's the same) gives you one third of the maximum value.

So, it's supposed to work as it does, I think.

2. It looks like the bug may be tool-related.

What exactly are you saying is a bug? I'm not saying GIMP is bug-free :-) just trying to see if in fact it's a problem with how to use these controls not being obvious, or whether your gimp is behaving different from mine, or whether all the gimps in the world are misbehaving (always a possibility, especially near a full moon).

Thanks,

Liam

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

On 12/05/12 13:12, Liam R E Quin wrote:

On Wed, 2012-12-05 at 12:38 -0700, Gary Aitken wrote:

So two thoughts:

1. Should the integral behavior I am seeing with the up-arrow on the threshold for fuzzy select be going by tenths, or by whole integers?

Neither, it depends on the width of the toolbox.

It should go up or down by distance you drag as a percentage of the max value, times max value E.g. when the up arrow is one third the way along from the left of the scrollbar-thingy, clicking (or dragging at that point, it's the same) gives you one third of the maximum value.

So, it's supposed to work as it does, I think.

I don't think so. In the case of the paintbrush size, what is the max value? It is certainly not reached at the right boundary of the size slider, where it is ~1000. I can drag clear outside the slider to the right edge of the display and get it up to ~9500.

The OP was requesting a manner in which to get integral values, which I think is the main frustration. When sizing a brush, for example, if I know the brush was designed as a 100x100 image, I often want to pick sizes in integral amounts. It's essentially impossible to do with the slider. In addition, once one attempts to do that, the value ends up at some fractional amount like 437.23 and you have to delete the decimal part to get back to whole integers.

2. It looks like the bug may be tool-related.

What exactly are you saying is a bug? I'm not saying GIMP is bug-free :-) just trying to see if in fact it's a problem with how to use these controls not being obvious, or whether your gimp is behaving different from mine, or whether all the gimps in the world are misbehaving (always a possibility, especially near a full moon).

From what you've described as the formula, I would say it may be mostly behaving as intended, modulo the max value issue and modulo the where is it supposed to be clamped on the right boundary issue.

Outside of that, what I would question is whether that intention / design plays well in reality, given the desire for whole-number increments in many cases.

BTW you've probably already seen I may have jumped the gun and filed a minor bug on this. My apologies.

Could be a full moon thing, as I had a horse magically appear on the wrong side of a fence today. But I doubt it ;-)

Gary

On Wed, 2012-12-05 at 13:46 -0700, Gary Aitken wrote:

On 12/05/12 13:12, Liam R E Quin wrote:

I don't think so. In the case of the paintbrush size, what is the max value?

The maximum value is 10,000. However, since your slider is probably less than 10,000 pixels wide, the approach taken seems to have been to use 1,000 as the maximum settable within the slider, but to let you continue dragging (or edit the number, or use the tiny increment button).

It is certainly not reached at the right boundary of the size slider, where it is ~1000. I can drag clear outside the slider to the right edge of the display and get it up to ~9500.

Right.

The OP was requesting a manner in which to get integral values, which I think is the main frustration.

Yes, you can't do that this way.

I admit I usually use editable brushes, which are limited to square, diamond, circle, triangle, etc., and I have keys bound to increment-by-10, increment-by-1, and the same for decrement.

I think wanting integer-only brush sizes would be an enhancement request, although I'm not sure I understand the motivation: scaling by a non-integral amount sometimes gives better results. But maybe integral brush sizes is just a thing I happen never to have wanted :)

[...]

From what you've described as the formula, I would say it may be mostly behaving as intended, modulo the max value issue and modulo the where is it supposed to be clamped on the right boundary issue.

I think this is a feature and not a bug.

BTW you've probably already seen I may have jumped the gun and filed a minor bug on this. My apologies.

No need to apologise, but you might want to revisit the bug description and revise it if appropriate (I didn't check).

Could be a full moon thing, as I had a horse magically appear on the wrong side of a fence today. But I doubt it ;-)

:-)

Liam

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
The barefoot typographer - http://www.holoweb.net/~liam/

--- On Wed, 12/5/12, Gary Aitken wrote:

From: Gary Aitken Subject: Re: [Gimp-user] Question about the new sliders To: "Liam R E Quin"
Cc: gimp-user-list@gnome.org
Date: Wednesday, December 5, 2012, 3:46 PM

On 12/05/12 13:12, Liam R E Quin wrote:

On Wed, 2012-12-05 at 12:38 -0700, Gary Aitken wrote:

So two thoughts:

1.  Should the integral behavior I am seeing with the up-arrow on the threshold for fuzzy select be going by tenths, or by whole integers?

Neither, it depends on the width of the toolbox.

It should go up or down by      distance you drag as a percentage of the max value, times max value E.g. when the up arrow is one third the way along from the left of the scrollbar-thingy, clicking (or dragging at that point, it's the same) gives you one third of the maximum value.

So, it's supposed to work as it does, I think.

I don't think so.  In the case of the paintbrush size, what is the max value? It is certainly not reached at the right boundary of the size slider, where it is ~1000.  I can drag clear outside the slider to the right edge of the display and get it up to ~9500.

The OP was requesting a manner in which to get integral values, which I think is the main frustration.  When sizing a brush, for example, if I know the brush was designed as a 100x100 image, I often want to pick sizes in integral amounts.  It's essentially impossible to do with the slider.  In addition, once one attempts to do that, the value ends up at some fractional amount like 437.23 and you have to delete the decimal part to get back to whole integers.

2.  It looks like the bug may be tool-related.

What exactly are you saying is a bug? I'm not saying GIMP is bug-free :-) just trying to see if in fact it's a problem with how to use these controls not being obvious, or whether your gimp is behaving different from mine, or whether all the gimps in the world are misbehaving (always a possibility, especially near a full moon).

From what you've described as the formula, I would say it may be mostly behaving as intended, modulo the max value issue and modulo the where is it supposed to be clamped on the right boundary issue. 

Outside of that, what I would question is whether that intention / design plays well in reality, given the desire for whole-number increments in many cases.

BTW you've probably already seen I may have jumped the gun and filed a minor bug on this.  My apologies.

Could be a full moon thing, as I had a horse magically appear on the wrong side of a fence today.  But I doubt it ;-)

Gary

gimp-user-list mailing list
gimp-user-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-user-list

On 12/05/12 14:00, Liam R E Quin wrote:

On Wed, 2012-12-05 at 13:46 -0700, Gary Aitken wrote:

On 12/05/12 13:12, Liam R E Quin wrote:

I don't think so. In the case of the paintbrush size, what is the max value?

The maximum value is 10,000. However, since your slider is probably less than 10,000 pixels wide, the approach taken seems to have been to use 1,000 as the maximum settable within the slider, but to let you continue dragging (or edit the number, or use the tiny increment button).

It is certainly not reached at the right boundary of the size slider, where it is ~1000. I can drag clear outside the slider to the right edge of the display and get it up to ~9500.

Right.

The OP was requesting a manner in which to get integral values, which I think is the main frustration.

Yes, you can't do that this way.

Bummer

I admit I usually use editable brushes, which are limited to square, diamond, circle, triangle, etc., and I have keys bound to increment-by-10, increment-by-1, and the same for decrement.

likewise, without the bindings.

I think wanting integer-only brush sizes would be an enhancement request, although I'm not sure I understand the motivation: scaling by a non-integral amount sometimes gives better results. But maybe integral brush sizes is just a thing I happen never to have wanted :)

Not sure I understand that statement. You apparently use integral brush sizes enough to have bound keys to incrementing and decrementing by 1 and 10. That seems to imply you use integral brushes a lot, unless you always start with an odd-ball non-integer brush size.
Am I missing something?

I'm not a graphic artist, but if you're designing an icon, for example, or a finely detailed map as a that you want as compact as possible, you sometimes want to minimize feathering, anti-aliasing, and everything else that results in "partial" colors of one form or another. I don't have a lot of experience with this but I know I often end up with these artifacts when I've forgotten to turn off things like anti-aliasing and feathering for various operations. How does one intuit what is a brush with a 2.85 pixel diameter going to do when it paints? In these sorts of instances when I'm editing pixels, I want a brush size that lays / aligns more or less exactly with the pixels in the image.

That may not be the best way to do the things I'm trying to do in these instances, and I'm happy to learn better ways. But one uses the tools in the way one knows how, although that's sometimes like using the back of a knife to undo a screw...

[...]

From what you've described as the formula, I would say it may be mostly behaving as intended, modulo the max value issue and modulo the where is it supposed to be clamped on the right boundary issue.

I think this is a feature and not a bug.

If this is a feature, and if you can grant that wanting integral sizes has some utility, shouldn't that be relatively easy to attain by the user? I would submit that integral sizes, or something more integral than 0.01 increments for brush size in particular, is likely a common desire. This could be as simple as a global option, over-rideable on a per-tool basis, over-rideable on a per attribute basis, for "minimum increment". It might also be useful to be able to set the max and min values (max in particular). I suspect there are very few people who want a brush size more than 1000 (but hey, I don't design billboards). If there are, I would like to be able to set a more reasonable max.

Gary

On Wed, 2012-12-05 at 17:25 -0700, Gary Aitken wrote:

On 12/05/12 14:00, Liam R E Quin wrote:

[...]

I admit I usually use editable brushes, which are limited to square, diamond, circle, triangle, etc., and I have keys bound to increment-by-10, increment-by-1, and the same for decrement.

likewise, without the bindings.

I think wanting integer-only brush sizes would be an enhancement request, although I'm not sure I understand the motivation: scaling by a non-integral amount sometimes gives better results. But maybe integral brush sizes is just a thing I happen never to have wanted :)

Not sure I understand that statement. You apparently use integral brush sizes enough to have bound keys to incrementing and decrementing by 1 and 10. That seems to imply you use integral brushes a lot, unless you always start with an odd-ball non-integer brush size.
Am I missing something?

Yes. I pretty much only use the dynamic (editable) brushes, and all I care about is the approximate size in most cases. I just looked, and my current brush has a size of 172.36, so pressing } will make it 182.36 and pressing ] will make it 173.36. They get to odd sizes because I might click anywhere on the Size slider. I also have $ and % bound to softer/harder by 10, and 4 and 5 for softer/harder by 1. Right now the brush hardness is 0.69.

I'm not a graphic artist, but if you're designing an icon, for example, or a finely detailed map as a that you want as compact as possible, you sometimes want to minimize feathering, anti-aliasing, and everything else that results in "partial" colors of one form or another.

Makes sense but it's a long way from cleaning up 2400dpi full-page scanned images for sale as stock :-) or from freehand painting, or from using dodge/burn on a photograph, where soft edges are needed.

[...]

If this is a feature, and if you can grant that wanting integral sizes has some utility, shouldn't that be relatively easy to attain by the user? I would submit that integral sizes, or something more integral than 0.01 increments for brush size in particular, is likely a common desire.

I suppose for people doing professional pixel-level work it may be, that hadn't occurred to me. I don't mean to imply that one usage is better or more important than another.

It might
also be useful to be able to set the max and min values (max in particular). I suspect there are very few people who want a brush size more than 1000 (but hey, I don't design billboards).

I used to recompile my own gimp with a larger maximum brush size, although I have not often used more than 400 pixels or so.

Being able to set a maximum might help with "Fitt's Law" - quicker selection of the largest size.

Even in a pixel context a square brush with a radius of 0.5 pixels makes sense to me though. So I'm not sure what is a good answer here. There's a paint tool options button to reset bitmap brushes to their "native size", so maybe keybindings for tool presets would let you switch brush sizes with a single keypress?

Liam

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

On 12/05/12 18:56, Liam R E Quin wrote:

On Wed, 2012-12-05 at 17:25 -0700, Gary Aitken wrote:

On 12/05/12 14:00, Liam R E Quin wrote:

[...]

I admit I usually use editable brushes, which are limited to square, diamond, circle, triangle, etc., and I have keys bound to increment-by-10, increment-by-1, and the same for decrement.

likewise, without the bindings.

I think wanting integer-only brush sizes would be an enhancement request, although I'm not sure I understand the motivation: scaling by a non-integral amount sometimes gives better results. But maybe integral brush sizes is just a thing I happen never to have wanted :)

Not sure I understand that statement. You apparently use integral brush sizes enough to have bound keys to incrementing and decrementing by 1 and 10. That seems to imply you use integral brushes a lot, unless you always start with an odd-ball non-integer brush size.
Am I missing something?

Yes. I pretty much only use the dynamic (editable) brushes, and all I care about is the approximate size in most cases. I just looked, and my current brush has a size of 172.36, so pressing } will make it 182.36 and pressing ] will make it 173.36. They get to odd sizes because I might click anywhere on the Size slider. I also have $ and % bound to softer/harder by 10, and 4 and 5 for softer/harder by 1. Right now the brush hardness is 0.69.

I'm not a graphic artist, but if you're designing an icon, for example, or a finely detailed map as a that you want as compact as possible, you sometimes want to minimize feathering, anti-aliasing, and everything else that results in "partial" colors of one form or another.

Makes sense but it's a long way from cleaning up 2400dpi full-page scanned images for sale as stock :-) or from freehand painting, or from using dodge/burn on a photograph, where soft edges are needed.

agreed; I don't do those pixel things very often, but others might.

[...]

If this is a feature, and if you can grant that wanting integral sizes has some utility, shouldn't that be relatively easy to attain by the user? I would submit that integral sizes, or something more integral than 0.01 increments for brush size in particular, is likely a common desire.

I suppose for people doing professional pixel-level work it may be, that hadn't occurred to me. I don't mean to imply that one usage is better or more important than another.

It might
also be useful to be able to set the max and min values (max in particular). I suspect there are very few people who want a brush size more than 1000 (but hey, I don't design billboards).

I used to recompile my own gimp with a larger maximum brush size, although I have not often used more than 400 pixels or so.

Being able to set a maximum might help with "Fitt's Law" - quicker selection of the largest size.

Even in a pixel context a square brush with a radius of 0.5 pixels makes sense to me though. So I'm not sure what is a good answer here. There's a paint tool options button to reset bitmap brushes to their "native size", so maybe keybindings for tool presets would let you switch brush sizes with a single keypress?

I agree a .5 radius makes sense; it's also a 1.0 diameter ;-). Dang, there's a conundrum -- brush "Size" should be labelled "Radius" or "Max Extent" (or something like that for non-circular type brushes).

I may not be understanding correctly, but it seems like that would allow setting of specific sizes, not the whole range one might be interested in?

What bothers me about the keybindings idea is that it is an accelerator, and the less-proficient / less-experienced with the specific tool user tends to use the mouse. Getting the desired behavior should be possible via the mouse.

Going back to my original proposal, what downsides does it have? It requires no changes to the interface, some additions to preferences,
and pretty simple changes to the guts of the generic slider. It allows arbitrary granularity and a pretty wide range of possibilities, and is relatively simple:

valueDelta = ((float)deltaPtr / (float)maxPtr) * (valueExtent * 100.) / granularityX100; valueDelta = (float)((int)(valueDelta * 100) / granularityX100) * granularityX100 / 100.; newValue = value + valueDelta;

e.g.: value=175.000 granularity=1.500 minValue=-100.000 maxValue=400.000 deltaPtr=15 maxPtr=1024 valueExtent=500.000000
granularityX100=150
deltaPtr * valueExtent * 100 / maxPtr=732.421875 valueDelta / granularityX100=4.882812 valueDeltaX100=450.000000
valueDelta=4.500000 newValue=179.500000

Gary