[MPlayer-dev-eng] [PATCH] vo_macosx: process events with shared_buffer (and patch roundup)

[Adrian Stutz]

On Sat, May 30, 2009 at 8:16 PM, Michael Guntsche <mike at it-loops.com> wrote:
>> (2) The only proper way to inquire if MPlayer (or the frontend) is the
>> frontmost process seems to be in the vo. In case of vo_corevideo it
>> could return the state of its own window or the state of the frontend
>> through the NSConnection.
>
> This would mean to add code that's macosx specific to the x11, corevideo and
> gl vo_s.
> Since people might also use the GL or X11 output on macosx for output.
> What about making this completely separate from the AR and VO code. Have
> generic code (possibe platfrom specific) that checks if
> mplayer is the foreground process and let the AR code and other systems that
> need the information look it up from there?

Macosx-specific, since right now the Apple Remote code would be the
only one using it, yes. But I don't think there would be the need to
e.g. add non-x11-related code to the X11 output. Each vo could use its
framework to inquire the front status of MPlayer (I'm sure there's a
way to to this in X11).

I don't think this could be separated from vo code because the vo is
responsible for creating the video window or in turn use other means
to communicate with the frontend. In this specific case, the corevideo
vo opens and manages the NSConnection that would be needed to inquire
the font status from the frontend.

>> (3) Simply disable MPlayer's Apple Remote support and implement it in
>> the frontend.
>
> This would break remote support for the standalone mplayer.

I didn't mean to disable it for everyone but rather to disable it in
MPlayer OSX (either at compile-time or with the command-line option).

On Sat, May 30, 2009 at 8:28 PM, Reimar Döffinger
<Reimar.Doeffinger at gmx.de> wrote:
> 4) remove the code from ar.c that checks for foreground. If Apple wanted
> the Apple Remote to depend on foreground or not the would have created a
> proper API for it (or more precisely used the normal input handling).
> Users who complain should be redirected to Apple.

The problem I see with this is that the issue is actually quite a
special case. It only affects
- MPlayer used as a background-only application on OSX (with shared_buffer)
- MPlayer running on Leopard (since only the spindump-side-effect is an issue)

That would mean removing a feature only for fixing a really specific
case, affecting only a subset of the users.

--

Thinking more about it, I currently tend towards (3). (2) would be the
most appropriate solution but seems like an overkill to implement for
only the Apple Remote on OSX.

(3) would have the additional benefit that I could use the Apple
Remote code from Martin Kahr, wich also supports the Keyspan RF
FrontRow Remote, a generalized hotkey remote and a facility to
negotiate access to the remotes with other applications.

Greetings
Adrian