[linux-audio-dev] Spinboxes

[Jens M Andreasen]

On mån, 2004-06-21 at 09:40, Thorsten Wilms wrote:
> On Mon, Jun 21, 2004 at 08:48:07AM +0200, Jens M Andreasen wrote:
> > > 
> > How about sideway fwd/back arrows. The sideway movement of the bar
> > indicates something like that
> > 
> >  |<|>|
> 
> Right. Would make more sense in combination with  bar display.
> 
> The reason for using down/up is of course it's more clear / 
> gives a stronger asociation to decreasing / increasing.

I am not sure i can agree when the display is sideways ;)

>  
> 
> > > I don't know if showing the value as bar in the background 
> > > is a good idea in the end, because it might be confusing (?)
> > > 
> > Not all values are on a scale. Channel one is no more nor less than
> > channel 16. Sound 128 is not nescessarily fatter or thinner than any
> > other sound. So in those cases the bar would get in the way.
> 
> Right. For stepped paramters, no bar should be displayed. 
> For continous parameters (like volume), spinboxes should be 
> accompanied by knobs or sliders anyway.
> 
> But I have an idea for spinbox like widgets that would be  
> better suited for continous parameters, if there's no  
> space for knobs/sliders.
> 
> 
> > Also having the bar go thru a number that you might like to read is not
> > so perfect. Is that a 3 or is it an 8? And where did that tiny decimal
> > point go?
> 
> I think that's not such a problem with contrast like used in the mockup.
> But then again creating a high contrast version for those who need it 
> would be problematic. So you have a point.

Perhaps the edge between orange/grey need not to be so sharp. There
could be a handful of blurred pixels fading from the one to the other.

Also, since space is very limited, you could use more than two colours
but only show at most two of them at any time, ie:

  grenadine | orange | icewater

Setting the level at the middle position would be all orange, at full
would be all grenadine and at minimum would be all icewater (or "thin
air"?) All other values has a two-coloured background.

This should give back some of the visual advantages of a long-throw
fader.

Finally, if the borderlines between colours are tilted:

  grenadine / orange / icewater

... then you would be able to see that you are leaving/entering a range
before it happens. Kind of a "look-around-corners" feature.

The exact middle position would then be all orange except for a few
grenadine pixels in the upper left corner and a few icewater pixels in
the lower right corner.

For a balance control one could use:

 orange / icewater \ orange

... where the zero position would reveal a few orange pixels in each of
the upper left/right corners.
> 

> > I think page up/down is standard behaviour for large steps in GTK.
> > Arrow left/down decrements, right/up increments.
> > 
> > Click and Hold spins thru all values, first with the small increment
> > value and then after some time with the page size.
> 
> I think click and hold on spinbox buttons works fine as is. 
> Seems to have a small delay until it starts, but the rate 
> is constant. Increasing step size after some time would make 
> it harder to stop at or near the right value.
> 
Ehrmm ... Maybe I wasn't too clear here? I tried to describe the actual
default behaviour of GTK. Of course, if page-size equals increment-size,
then the rate would be constant. They are two separate arguments though.

Mouse-wheel appears to go for half a page-size.

mvh // Jens m Andreasen

> 
> ---
> Thorsten Wilms