[MPlayer-dev-eng] [PATCH] GUI: Potmeter button corrections

[Hans-Dieter Kosch]

Ingo Brückl wrote:

> Hans-Dieter Kosch wrote on Wed, 26 Mar 2014 01:05:27 +0100:
> 
>> Ingo Brückl wrote:
> 
>>> This will go beyond the boundaries, resulting in an uiEvent() call with an
>>> illegal value.
> 
>> You're right. I missed that. There's no value range check like in 'case
>> wsMoveMouse:'
> 
> In this case value will always remain within the limits (which isn't true for
> the mouse move).

But uiEvent() is really called with an out of range value.

>> (nevertheless, I noticed exactly the expected behaviour, though (?) ).
> 
> btnModify() (called prior to rendering) finally restricts value.

So, possibly restrict the value as done in wsMoveMouse before calling uiEvent() 
(to be formally correct) and implement this patch or a variant as at least an 
intermediate solution?

>> The mouse position yields an item value, and then in turn, the item value
>> yields an object position. If the forward and reverse calculations differ,
>> arbitrarily wierd displays can result.
> 
> Currently we actually have: mouse position -> value (which is decisive) ->
> item representation (by rendering).

At this point coming into my mind: The button position is also updated by 
'external' item value changes, e.g. movie position while playing, or 
volume/balance changed by a concurrently running audio mixer. This works 
perfectly so far. So, the item value appears really to be the correct reference 
for rendering. And thus, the translation 'mouse position -> value' should match 
the translation 'value -> rendering position'. The current problem seems to me, 
that the related calculations are scattered loosely across the files; maybe this 
could be made consistent by defining appropriate macros in a common header file.

> I'm aware that there may be precision problems when using a potmeter to
> adjust something, but so far this didn't cause major troubles.

Yes, of course, I didn't mention, as it appeared obvious to me. And precision is 
even more reduced with my patch. But that's physical constraint anyway, a high 
res screen gives finer control than a low res one.

>> PS: The rpotmeter is working now at least for the GTK GUI (I have still
>> nothing to test Win32).
> 
> Don't spend too much time dealing with Win32. I can do the tests, and we can
> even implement it for Win32 later (though I'd like to implement at one go).

OK. I'll post latest at next weekend. It's my habit to let settle and review, 
and push out related things all together. You can of course at your discretion 
hold off committing until Win32 is worked out.

Hans-Dieter