On 11/02/2010 06:16 PM, hermann wrote:
>> When such an audio-gui standard and configuration is developed, I would love to
>> participate. And use it in my apps. I think its a good idea, especially the
>> idea of allowing the user to switch between circular and linear behaviour for
>> round controls. And have that changes affect all apps supporting this
>> "standard".
>>
> As far there is no such a standard and it seems it wouldn't come so fast. So I
> have add a menu option to gx_head (guitarix successor) were the user can select
> between radial or linear knob interaction. All is in a lib witch can be used
> static or shared. The switch work with a bool operator, and it will be easy to
> set it over getenv() for example.
>
> More difficult it will be to comes to a conclusion in the free developer world
> of how, why, if and would we really all use the same environment variable.
> If we, it makes now matter witch lib or not one use to create the knob, only
> the var needs to be read.
As the topic is coming back, attached is my Proposal for a versatile GTK+ knob
widget.
It isn't really a standard, it is more intended to be an inventory of things
that were mentioned in a couple of recent threads, and to serve as a
design/implementation plan for a real widget.
There are a few things that I wanted to improve before posting it here, but I'm
running out of time. Comments are welcome.
-- Olivier
=========================================
Proposal for a versatile GTK+ knob widget
=========================================
.. contents::
Introduction
------------
The purpose of the present document is to specify and describe the
features that could be implemented in a new GTK+ rotary control widget,
also called a *knob*.
The goal is to provide a highly reusable widget, which supports a good
set of customization options, so that developers can adapt both its
Rendering_ and Behavior_ to their needs and preferences.
Another goal is to ease integration in a variety of desktop environments,
by trying to support visual user themes.
Eventually, a certain level of accessibility should be provided by
the widget.
Design overview
---------------
First of all, knob is just a nickname here. This widget is actually
a slider, with a circular shape. What this means is that a particular
attention is given to visual feedback: the widget should not only allow
to control a given parameter, but also to represent it graphically,
as any slider do.
The question of the aesthetics is not left aside. Whether the widget
renders as a rather abstract shape, or looks like a pseudo-realistic
potentiometer, could be part of the customization options.
In regard to interaction, there are quite a few possibilities and tastes
around, and the idea is to try and offer support for all of the ones that
we've heard about. There are several aspects here, but they are highly
determined by whether the widget should respond to rotary or to linear
pointer motion. Also, keyboard-based control should be properly supported.
Rendering
---------
Functional aspects
~~~~~~~~~~~~~~~~~~
The rendering has a role to play on the functional side of things,
especially about visual feedback. Here are possible features:
* graphical visualization of the current level/value, with a circular
slider showing a *full* part and an *empty* part, represented as
two colors
* customizable *ground*: the so-called ground is the position of the knob
where it visually looks totally empty. This should be customizable
so that this ground value can be any of the actual values allowed in
the range. Most obvious cases are the ground value being equal to the
lowest value (volume), and to the average value (balance).
* customizable color: having different knobs use different colors can
be very efficient in certain complex interfaces. Therefore, the color
representing the *full* part of the slider should be customizable by
the developer.
* current value as label: the knob should allow to display the
current value near the actual circular shape. This would be
customizable: the label would need to be made explicitly visible by
the developer. Other options would include the choice of the unit
displayed, and of the position of the label: centered, mostly for
integers not taking too much space, or under the knob.
* scale as labels: another option would allow to display several points
of the scale as small labels around the circular shape. The displayed
points should be fully customizable by the developer, using a step
parameter, or alternatively a enumeration of values.
Accessibility
~~~~~~~~~~~~~
For visually impaired users, there should be a high contrast between
the *full* and the *empty* colors, and the visual slider should not
be too small/thin.
Aesthetics
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There are several constraints here:
* In the context of music applications, the aesthetic aspect of a widget
can play an important role. A musician is not necessarily a scientist,
and so might be sensible to the way the user interface looks and feels
(and well.. a scientist might too).
* On the other side, there are quite a few rules and practices to follow
to ensure proper integration in user-customized desktop environments.
Ordered by priority, we believe that the first rule is scaling ability,
and the second theme adaptability
* We have also mentioned that the knob-specific color can play a role in
regard to `Functional aspects`_. The color and shape should also take
Accessibility_ into account.
Here follows a proposal which tries to draw a path between these
constraints:
* the knob should be able to render in two flavours: a rather abstract
version, and a pseudo-realistic one. This last one would make quite
an extensive use of gradients. This feature could be generalized
with knob *renderers*, to support additional flavours.
* in both flavours the *full* color would be based on the GTK+
GDK_STATE_SELECTED background color, which often (but not always)
renders as a high intensity color, such as blue, orange, etc.. Where
other colors are generally shades of gray. In the pseudo-realistic
version, this color would be used as a base for computing a gradient.
* but the widget should try and detect if this color has a high intensity
or not. If it detects that it's just another gray, the widget should
use a hard-coded default color instead
* given that the base *full* color has been determined as mentionned
above, the developer could still configure it by changing its hue,
understood as in the HSV color model, but not the saturation or
value. This would allow to:
1. try and stay compatible with the default theme colors,
2. to specify an absolute hue, such as red, green, in order to respect
some convention
3. to easily compute color gradients accordingly
* apart from the *full* color, the other colors used in the knob should
be somehow based on the other colors configured in the GTK+ theme.
Behavior
--------
As mentioned above, there are mainly two schools about how the knob
should react to pointer motion.
* linear: the pointer moves up and down, or right and left, which results
in a rotation of the knob with a fixed precision
* rotary: the rotation of the knob is determined by rotary motion. This
result in a higher precision when the pointer is far from the widget,
but also cause sudden jumps when the pointer is near the widget,
which necessarily happens right after mouse-down
In our experience, the rotary variant is suited for touch screen
environments. On small touch screen, the finger moves on the knob
itself, following its circular shape.
These given, here are possible features:
* The widget should allow the developer to choose one of these two
interaction variants, and also the orientation (horizontal or vertical)
in the case of the linear one.
* There could also be a global setting, for example in GTK+ rc styles,
for the user to override the default behavior chosen by the developer.
* To support the linear variant in a variety of setups and applications,
the pointer should be made invisible and centered on the screen while
moving. This would workaround reaching screen borders, especially for
those knobs located at one of the edges of the interface.
* Quantization: the step parameter in the underlying GtkAdjustment should
be taken into account
* A keyboard modifier, certainly Ctrl, could allow to enter fine-tuning
mode in the linear variant.
* A double-click on the value label would allow to enter a value manually,
only if this label is visible, by temporarily replacing the label with
an input field (in-place editing)
* Interpolation: the knob could be configured for either logarithmic or
linear variation. However, in our experience, almost every piece of
software has a different understanding of how a volume control
should behave. Therefore, the API should also allow to set an interpolation
callback.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Wed Nov 3 00:15:01 2010
This archive was generated by hypermail 2.1.8 : Wed Nov 03 2010 - 00:15:01 EET