Or simply hide the cursor? On Nov 22, 2011 4:12 PM, "Fons Adriaensen" <[email protected]> wrote:
> 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 > [email protected] > http://lists.linuxaudio.org/listinfo/linux-audio-dev >
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
