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

[Michael Niedermayer]

Hi

On Sun, Sep 30, 2007 at 12:18:23PM +0800, Ulion wrote:
[...]
> > >
> > > 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? 

one way to avoid the OSD is to have a "reset" button which always returns
you to state 0 (this of course means one button less)
so if one isnt certain of the state in which she is, she can just press the
reset button

example:
state 0 0(do nothing) 1(state 1) 2,3,4,5(whatever you like)
state 1 0(state 0)    1(state 2) 2,3,4,5(whatever you like)
state 2 0(state 0)    1(state 3) 2,3,4,5(whatever you like)
...

here a simple 0 m  would always execute button m in state 0 
and 0 1 m always in state 1 no matter in which state you are
and 0 1 1 m always in state 2 no matter in which state you are
...

and if you know that you are in the right state already then its just a single
button press ...

disadvantage of this is that higher states need more button presses to reach


another example with a reset button would be
state 0 0(do nothing) 1(state 1) 2(state 2) 3(state 3) 4(state 4) 5(state 5)
state 1 0(state 0) 1,2,3,4,5 (whatever you like)
state 2 0(state 0) 1,2,3,4,5 (whatever you like)
state 3 0(state 0) 1,2,3,4,5 (whatever you like)
state 4 0(state 0) 1,2,3,4,5 (whatever you like)
state 5 0(state 0) 1,2,3,4,5 (whatever you like)

so here a 0 n m will always execute fuction m in state n
m will execute function m in the current state

here any of the 25 functions can be executed with 3 button presses and
does not need any knowledge of the current state
and any of the 5 functions of the current state can be executed with a
single button press if you know you are in the right state


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

dont timeout :)


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

but theres no need to delay the clicks ...

also if press as well as release "events" exist than you could extend
the number of available functions by adding long presses

this does not need a delay as the short function could be executed during
button release instead of press

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20070930/816a585a/attachment.pgp>