22 Nov
2011
22 Nov
'11
10:12 p.m.
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.