20 Jun
2004
20 Jun
'04
2:26 p.m.
Hi!
The usual spinboxes with their tiny up/down arrow buttons
made me think about an alternative.
Since using more height than a textfield has would make
layout very troublesome, my solution is placing the
buttons horizontaly.
http://wrstud.urz.uni-wuppertal.de/~ka0394/forum/04-06-20_spinbox_set_02.png
I think the variations with arrows are less pleasant to
look at. Using - and + also avoids confusion with option
menus. But I would like to hear everyone's opinion on that.
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 (?)
The right ones show highlighting (and the usual cursor
change) on mouse-over.
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.
Middle mouse button should be reserved for paste, right one
for context menu (besides copy/paste it could contain
max, min and 50% commands).
So only clicks with modifier keys are left.
I would propose Ctrl leftclick on -/+ buttons for larger
steps.
---
Thorsten Wilms
21 Jun
21 Jun
4:03 a.m.
At Sun, 20 Jun 2004 18:16:54 +0200,
Thorsten Wilms wrote:
The usual spinboxes with their tiny up/down arrow buttons made me
think about an alternative. Since using more height than a
textfield has would make layout very troublesome, my solution is
placing the buttons horizontaly.
I think you are *really* on to something here.
I think the variations with arrows are less pleasant
to look
at. Using - and + also avoids confusion with option menus. But I
would like to hear everyone's opinion on that.
I prefer -/+ myself, it seems easier to assess at a glance.
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 (?)
Perhaps hiding the numbers, and only showing them if the user mouses
over the texbox or clicks on it?
I definitely think these are a major improvement over spinbuttons as
far as audio apps are concerned. My only question is if they're
superior to traditional knobs/sliders. I think the only way to tell
would be to implement and compare.
-Pete
5:20 a.m.
On Mon, Jun 21, 2004 at 01:53:55AM -0400, Pete Bessman wrote:
I think you are *really* on to something here.
:)
I definitely think these are a major improvement over
spinbuttons as
far as audio apps are concerned. My only question is if they're
superior to traditional knobs/sliders. I think the only way to tell
would be to implement and compare.
Spinboxes on their own are the right control for stepped values,
like channel.
For continuous values (like volume) knobs or sliders are better,
because the actualy show the range/relative value and generaly
give a feel for the continous nature of the parameter.
Spinboxes are a good addition to knobs/sliders for providing
numerical info/input and finestepped adjustment.
Limited space can still be a reason for using spinboxes
exclusively for continous parameters.
---
Thorsten Wilms
4:54 a.m.
On sön, 2004-06-20 at 18:16, Thorsten Wilms wrote:
I think the variations with arrows are less pleasant
to
look at. Using - and + also avoids confusion with option
menus. But I would like to hear everyone's opinion on that.
How about sideway fwd/back arrows. The sideway movement of the bar
indicates something like that
|<|>|
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.
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?
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.
The right ones show highlighting (and the usual cursor
change) on mouse-over.
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?
Middle mouse button should be reserved for paste, right one
for context menu (besides copy/paste it could contain
max, min and 50% commands).
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.
mvh // Jens M andreasen
---
Thorsten Wilms
5:49 a.m.
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.
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.
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.
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
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. 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? 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.
6:57 a.m.
On mån, 2004-06-21 at 09:40, Thorsten Wilms wrote:
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.
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
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. 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. 
3:25 p.m.
On Sunday 20 June 2004 13:16, Thorsten Wilms wrote:
Hi!
The usual spinboxes with their tiny up/down arrow buttons
made me think about an alternative.
Since using more height than a textfield has would make
layout very troublesome, my solution is placing the
buttons horizontaly.
I personally like to simply use the mouse wheel over the updown area to
increase/decrease the values on the boxes.. Qt and GTK2 support this
behavior.. though Gtk 1.2 doesnt seem too..
Cheers!
reduz
7553
days inactive
7554
days old
linux-audio-dev@lists.linuxaudio.org
6 comments
4 participants
participants (4)
-
Jens M Andreasen -
Juan Linietsky -
Pete Bessman -
Thorsten Wilms