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

[Ulion]

2007/9/30, Ergzay <ergzay at gmail.com>:
>
> 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  ...

First of all, I should say I like such idea reply such as this one from Michael.

> >
> > 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

Yes a little too slow doubleclick did get some annoying. In my current
key-command mappings:
1. Doubleclick play/pause make toogle_fullscreen, a slow doubleclick
just fail the click, it's ok.
2. Doubleclick prev, next buttons just make a bigger forward or
backward, slow doubleclicks get acceptable actions.
3. Doubleclick '-' make toogle_mute, normally a slow doubleclick is
annoying. Except when we already in mute, if we make a toogle_mute,
the volume will be restored to the original value. But a slow
doubleclick seems will set the saved original volume value to zero
then after unmute the volume will be zero. This's a little annoying,
but it's fixable in the volume adjust and mute part of code. Just
ignore all volume adjust in mute state will fix it.
4. Doubleclick '+' make toogle_ontop, that's not annoying for a slow
doubleclick.
5. Doubleclick menu make command sub_select, that's a little annoying
for a slow doubleclick make osd level change twice, but still
acceptable.

> >
> > 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.)

Sounds interesting, one menu click before other input to get 10 extra
functions, this state of modify should better keep for several seconds
so we need not repeat to press the menu to got modifier. One more menu
click reset the modifier state back to normal state for the default
actions.
That's a good idea to extend buttons' functions, but it definitately
need some kind of osd to notify users it's in a modifier state? Any
idea how to do this? And if the momdifier state will timeout after
seconds, at the moment of the state go away, inputs may cause wrong
result, any idea to overcome this problem?

Although we extended functions by menu modifier, there still can have
doubleclick support, at least for toogle_fullscreen, I can not find
another input method better than doubleclick play/pause button.


-- 
Ulion