Or simply hide the cursor?
On Tue, Nov 22, 2011 at 09:13:37PM +0100, Nick Copeland wrote:
> If you are using a toolkit that has a data flow of the following:
>
> pointer motion->graphical display->values->application->output
>
> Well, basically that is broken as you have a flow that is
>
> input->output->input->application->output
>
> invariably that is going to lead to issues. The tail (the toolkit) is wagging the dog
> (the application) as it imposes restrictions on the values the application is allowed
> to see.
>
> In my opinion (ok, it is only opinion) is that the correct flow is
>
> input->application->output
Yes, I see your point, and it makes a lot of sense. So what would be
required is
* compute the new parameter value from
- a stored state in 'paramater space' rather than 'widget space'
- and pointer (mouse) gestures,
* update the widget according to that value.
This is more or less what I do in the rotary controls used
in e.g. zita-at1 and zita-rev1. It's possible because the
mouse movement and the visual representation of the value
(the angle of the line on the rotary knob) are not directly
related anyway.
But this is not how most (all) toolkits work.
You could probably use them in the way you suggest with some
extra effort. But in many cases (e.g. linear sliders) the
pointer and widget would have to remain in sync visually,
which then means that your resolution in paramater space
can't be better than the visual one. Unless you allow the
pointer to move faster than the visual object it is controlling
(which is what I do in the 2-D panner, but it's possible only
because the widget is so small).
Ciao,
--
FA
Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev