[MPlayer-dev-eng] MPlayer GUI

[Alban Bedel]

Hi David Holm,

on 17 Feb 2002 15:25:33 +0100 you wrote:

> On Sun, 2002-02-17 at 15:30, Arpi wrote:
> > Hi,
> > 
> > argh... threads sux, mplayer is not threadsafe at all and won't be...
> > 
> > why don't split the gui from mplayer core? as a frontend, using the improved
> > slave_mode to control it?
> > 
> > the only reason why gui was built into the core was controlling the libvo
> > window. it is a mess.
> > 
> > with -windowid we can pass window id to mplayer and it will render video to
> > that window. so i see no sense of keeping them in the same binary.
> > 
> 
> Sounds like a great idea... Although reusing some gui code would be
> favourable so we can still use all the nice skins available ;).
> 
I thougth about using an extended slave mode, in this case we should put the
config inside mplayer and the playtree stuff on the client side. It's require to add
a layer to allow transparent remote control of the config stuff because the 
playtree need  to access it in order to do per-entry setup. In this case mplayer
should init and then just wait to have a file to play, play it, wait the next one, etc.
All the config are done on the remote side.
Also I think we should split file loading and playing (ie.  load the file, then wait we are 
asked to play it) so the controlling app can easily check if a file is recognised.
If do all right we can have full remote control even over the network :)
The only thing wich really need shm is for realtime info such as time, cpu usage,
cache status, etc.
Final point, do it as lib then make the gui using the lib, so other ppl can write their own
GUI, do perl binding and I don't know what ;)
	Albeu