[MPlayer-dev-eng] [PATCH] Apple Remote support double click

[Ergzay]

On 2007/09/29, at 17:49, Michael Niedermayer wrote:

> Hi
>
> On Sat, Sep 29, 2007 at 10:08:32PM +0800, Ulion wrote:
>>>
>>> How come no other input device has ever required huge invasive 
>>> changes
>>> to support? Either this patch is just badly written and not doing
>>> things right, or Apple's API is nonsense. Moreover the whole idea of
>>> delaying the processing of a first click in order to make sure it's
>>> not a doubleclick is stupid and counterintuitive. In every other
>>> application I've ever seen, a doubleclick functions as additional
>>> behavior on top of what a single click already did...
>>
>> I'd like to keep doubleclick action on the base of singleclick actions
>> also. But, apple remote only have 6 bottons, there are too many common
>> commands users needed. There are only few commands can work together
>> for the doubleclick action base on singleclicks actions. Besides
>> doubleclick for toogle_fullscreen (which can work fine with play/pause
>> commands produced by singleclicks of play button),  only way to
>> support most other commands is to simulate doubleclick, and delay or
>> ignore singleclick. Any idea on this?
>
> while i have not read a single line of code related top this :)
> ive a few comments  ...
>
> IMHO delaying single clicks is wrong
>
> and 6 buttons is alot, double click with delay would only double
> this to 12 and if the single and double click funtions differ widely 
> then
> a little too slow double click could get quite annoying
>
> first how can one give more commands with 6 buttons? well how can i
> write more words than i have keys?
>
> in the most general sense you could think of the thing as a state 
> machine and
> each button press (as well as release if thats suported) could 
> transition into
> another state, although thats a too general view i guess
>
> more simple ones would be for example that 1 or 2 buttons could cycle 
> through
> states (similar to a menu) and completely change the behavior of the 
> other
> buttons this would need some visual feedback though so the user knows 
> in
> which state the thing is
>
> another solution would be a simple 2 level system
> that is
> first the 6 buttons select 6 states
>
> state 0 could be 0->increase volume, 1->decrease volume 
> 2->brightness++,
>                  3->brightness--, 4->return to state selection
> state 1 could be 0->seek forward a little, 1->seek backward a little,
>                  2->seek forward a lot, ...
>                  4->return to state selection
> state 2 could be 0->fullscrean toggle, 1->pause/play, ...
> ...
>
> this would give you 6*5 = 30 functions

This is an interesting idea, but wouldn't this mean that all control 
would have to be done with two button presses then (if you aren't 
already in the state you want)? It would remove a lot of the ease of 
use and would require a lot of memorization for remembering where you 
put each of your 30 controls. I think this would require some sort of 
OSD to show what the choices in the current state is (hopefully not 
centered in the middle of the screen like the current OSD is). I'm not 
sure if you know, but the buttons on the remote are: + and - (usually 
used for volume), |<< and >>| (for forward and backward), pause/play, 
and menu. We might instead use a combination of yours and the current 
form where you would instead use the menu button as a modifier instead 
of using different states. This wouldn't be as many available functions 
but it would preserve single click features with the exception of the 
ones that used the menu button. We might also use this to modify the 
hold button features as well which would give you 10 extra functions in 
total. (We might also hypothetically do something like use states but 
you press the menu button a certain number of times repeatedly to 
select the state, 1 for state one, 2 for state two, etc. Although this 
might be overly complex.)

Ergzay