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

Michael Niedermayer michaelni at gmx.at
Sat Sep 29 23:49:37 CEST 2007


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

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
-------------- 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/20070929/f63b68cb/attachment.pgp>


More information about the MPlayer-dev-eng mailing list