Re: [linux-audio-dev] Spinboxes

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Spinboxes
From: Thorsten Wilms (t_w__AT_freenet.de)
Date: Mon Jun 21 2004 - 10:40:10 EEST


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

> Fading the whole background/foreground could be an option. The idea
> being that a led behind the widget emits more light as the values get
> higher.

Conflicts with mouse-over highlighting.

> > Mousewheel should work on mouse-over (no clicking required)
> > just like is the case with GTK+ spinboxes (can't test other
> > toolkits now).
> > The minus key should be reserved for entering the minus sign.
>
> So plus/minus buttons is kind of off, no matter the esthetics?

The keyboard focus can be on another textfield, where it
might be possible to actualy enter minus. That's why the
button should never work on mouse-over for decreasing,
because it can not always work. And if the minus key doesn't
work like that, it would be a bit strange if the plus key
would.
But yes, the - and + icons can be seen as being misleading
in this regard. So I might be better of trying to create
nicer arrows.
 
> > So only clicks with modifier keys are left.
> > I would propose Ctrl leftclick on -/+ buttons for larger
> > steps.
>
> 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.

---
Thorsten Wilms


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Mon Jun 21 2004 - 10:35:10 EEST