[MPlayer-dev-eng] new gui

[Jason Tackaberry]

On Wed, 2005-12-21 at 19:54 +0100, Jan Volf wrote:
> 2. The slave mode is not all bad but it needs a major facelift. When  
> engaged the direct keyboard control should be disabled so the GUI  
> knows the exact state of player and all keyboard events should be  
> handled by GUI making need of players own event handler unnecessary.

I kluge this by generating an input file that maps all possible keys to
a "noop" command, and specify the file with -input conf=map.  Any key
pressed in mplayer's window will then be ignored.

> 2.1. It needs standardized way of responses, for example in XML or  
> other extendable format so it can be easily parsed but won't need  
> code rewriting each time when output changes.

I don't disagree in principle, but in practice MPlayer's output format
hasn't changed much (or at all) for those things that need to be parsed
to track mplayer's state.  With -identify, certain things are outputted
in a standard format, for example ID_PAUSED.  More needs to be added
(ID_PLAY, ID_SEEK, etc.)

> 2.2.The next one irritating thing in slave modes is paused state of  
> player when it accepts no command but unpause command. It makes  
> impossible to seek in the movie while in paused mode and do other  
> things as well.

Agreed.  I submitted a patch to allow seeking while paused ages ago.
Search the list if you're interested.  It was never merged (or even
commented on IIRC).  Surprise.

> 3. There should be a possibility to output mplayers video to GUI  
> specified window or view. This is a bit tricky and overlay might not  
> work on all OSes. This allows GUI to do the necessary mouse and  
> keyboard event handling instead of mplayer. As long as I know Nicolas  
> Plourde have done this for Mplayer's binary for OS X in vo_macosx  
> using shared buffer.

You can use -wid to embed mplayer into a subwindow of your application
(for example a GtkSocket, if you use gtk+), but this is X11-specific,
and I imagine it doesn't work on Win32.  (Just an educated guess.)  With
your own window, you can handle mouse and keyboard events.

> 4. Another good thing would be a possibility of outputing text  
> subtitles to the standard output to let the GUI to render them using   
> particular OS's text engine. It allows using fonts installed on the  
> OS and other features of the text engine.

Interesting idea.

Cheers,
Jason.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 229 bytes
Desc: This is a digitally signed message part
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20051221/1e9d1719/attachment.pgp>