Re: [Gimp-user] Question about the new sliders

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;

  value=175.000  granularity=1.500  minValue=-100.000  maxValue=400.000  deltaPtr=15  maxPtr=1024
  deltaPtr * valueExtent * 100 / maxPtr=732.421875
  valueDelta / granularityX100=4.882812
  valueDelta=4.500000  newValue=179.500000


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]