[MPlayer-dev-eng] new gui
tack at sault.org
Wed Dec 21 20:07:42 CET 2005
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 229 bytes
Desc: This is a digitally signed message part
More information about the MPlayer-dev-eng