[MPlayer-dev-eng] [PATCH] GUI: Implement a true rotary potmeter

[Hans-Dieter Kosch]

Ingo Brückl wrote:

> Hans-Dieter Kosch wrote on Sat, 12 Apr 2014 02:13:21 +0200:
> 
>> Ingo Brückl wrote:
> 
>>> Well, and as soon as you try to change a simple feature you're meeting a
>>> peck of troubles...
>>>
>>> When you click on a potmeter button to grab it, it would already move due
>>> to its new value now. :-(
> 
>> No, yes, of course, that's exactly the pretty behaviour (IMO) :-)
> 
> For a rpotmeter yes, but I was talking about v/hpotmeters (with a button of
> some heigth/width) - sorry for forgetting to mention it.

The rpotmeter has a button, too, with width/height; I see no difference. 
render.c already takes care about.

>> 3) New (your revoked change): The value would jump already on press, and
>> from there on smoothly follow the drag. This appears to me intuitive and
>> much better than if it would jump surprisingly upon a drag ( 2) ).
> 
> I don't disagree, but in order to prevent a jumping v/hpotmeter button quite
> some code changes seem necessary then (which certainly will lead immediately
> to other necessary changes; and it would be useful to revise the ui/*.c code
> before).
> 
> The point is, the X11/GTK GUI mouse handler (unlike the Win32 GUI's one)
> doesn't know and doesn't care about the potmeter buttons. (There are pros
> and cons either way.)

It obviously doesn't need to care, it only sets the value. And render.c places 
the button correctly according to the value, which it does already. More 
precisely, not the button jumps in first place, but the value does so. So I see 
no other issues implied. The v/hpotmeter code under wsRLMouseButton would be 
moved to wsPLMouseButton and all potmeters would have the same behaviour.

Hans-Dieter