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

[Ingo Brückl]

Hans-Dieter Kosch wrote on Wed, 02 Apr 2014 04:24:47 +0200:

> Ingo Brückl wrote:

>> Well, it seems that you've fixed where 0% is. Have you given plastic skin
>> a go? ;-)

> Not yet, I'll look.

Please do so, and I'm sure there are a few interesting other ones.

>> It is hard to say where 0 for a poti should be

> Right, the zero point is arbitrary, I thought about this, too.

But with your patch it's fixed.

> Specifying the zero point would need a skin definition and appears somewhat
> luxury to me.

Well, to me it seems absolutely necessary. And after having thought about it
for a while (which I should have done earlier), we not only need to know
about the 0% point but the 100% point, too.

> The endless potis are designed for incremental adjusting of different
> values depending on an item selection. The item value, of course, has
> limits [...] Do we want such?

Why not, if the implementation is universal enough to handle this without
extra effort.

>> I've not completely thought about it, but it seems that we would need some
>> additional information about the zero point of a rpotmeter, or mouse clicks
>> can't be handled else.

> Mouse clicks work like with the other potis, position and value jump to the
> clicked point (GTK GUI).

Yes, but I'm speaking of a potmeter which unknown zero point. You only know
the one from the standard skin, because you've looked into the image file and
interpreted it. ;-)

While mouse dragging and wheeling is possible without knowing the zero point,
clicking isn't (at least, it seems this way to me).

>> Since rpotmeters don't yet exist at the moment, we can set up the rules for
>> them without breaking existing skins. However, I want to remain as compatible
>> as possible with the other potmeters.
>>
>> What do you think?

> OK. Compatibility first, but open for any ideas. I regard a rotary poti
> just like a linear one.

Agreed, but for linear ones you always know the 0% and 100% points.

> The difference is that a circle has basically no start and no end...

Unless you get this information... (not about the circle, but the potmeter).

I've thought about a more general approach for rpotmeters and I think that it
is necessary to get the end point information (0% and 100%) from the
designer.

The problem is that I want to remain compatible and I don't want to overexert
the designer. He/she shouldn't have to think about degrees or some
trigonometric functions, but as is usual in pixels.

Well, this is what I've come up with: For a rpotmeter the default value of
the definition has to be default;x;y;X;Y where x,y is the coordinate (on the
edge of the potentiometer image) of the 0% point in phase#1 and X,Y the one
for the 100% in phase#n - in other words the tip of the mark on the
potentiometer image.

These (their atan2 probably) will be stored in guiItem which makes it
possible to consider them during calculation, and the gap is calculable now.

This should allow all kinds of rotary potentiometers.

What do you think?
Do you feel like proceeding?

Ingo

PS: For clarity, I'd prefer the (argument-wise) more straightforward
    transformation atan2(-dy, -dx) resulting in

       0.75
    0.5    0.0/1.0
       0.25

    unless this turns out to be impractical.