[MPlayer-dev-eng] new gui

[Jan Volf]

Quite interesting discussion. Although there was not much reactions  
of GUI developers anyway.

So my opinion is that making one universal GUI for all OSes doesn't  
seem to be a good idea. All the OSes are so different. Let the  
developers for the particular OS do the job but offer them a realy  
good player engine that can be perfectly controllable with GUI.

I'll try to express what I (as gui developer) demand from the mplayer:
1. I completely agree with the opinion that the GUI code should be  
separated from the player code. The player code should make no  
assumption of UI actualy used  including CLI. If mplayer team wants  
to make a good user interface then let it be CLI but make it  
completely replaceable with GUI. And I mean COMPLETELY. The slave  
mode in present state does not suffice.
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.
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.
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.
2.3. It may be good to built up a list of commands and divide them  
into actions (play, pause, stepForward, stepBackward, quit) and state  
changing commands (changeRate, changeVolume, chnageOSDmode,  
changeTime - replacing seek command, etc.) where the state changing  
commands must be handled anytime and must allow direct state value  
change not just cycling thru unknown number of values.
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.
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.

All this suppose running the GUI and mplayer as separate tasks. The  
reason is obvious. The GUI will stay responsive and player will  
continue to play while tracking the mouse events. It's even possible  
to run more than one player for only one GUI if it is needed.

That's all for now. I'll be gled to discuss any point mentioned above.
I'm sorry for long post. Hopefully this will make a good image of  
what is needed by GUI developer even for those who never did this  
kind of development.

Best regards

Jan Volf
mplayerosx.sf.net developer