[MPlayer-dev-eng] MPlayer GUI

[Arpi]

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.

> Hi David Holm,
> 
> on 17 Feb 2002 13:59:02 +0100 you wrote:
> 
> > Hi,
> > is anyone working on mplayers gui or is it free for anyone to pick it
> > up? It's starting to annoy me that we are loosing users to xine which
> > imho is mostly ripoffs of others sources (I've found numerous files
> > there with mplayer headers ;).
> > 
> > I'm not saying that I will pick up the gui but if noone is working on it
> > I might have a look at it.
> About this my opinion is that the GUI should go threaded. One thread for the
>  GUI and
> one wich is the actual main. I know mixing fork and thread is not recommende
> d, but
> once I STFW about this and found nothing intersting. The only thing I found 
> is 
> that POSIX complient implementations must allow fork from a thread (only the
>  calling
> thread should be forked, not the whole process). The only limitation I know 
> is that
> only the thread wich forked can safly send signal to the child. In other wor
> ds
> only the thread who create a child can deal with. This shouldn't be problem 
> for us.
> 
> Using a threaded approch we can resuse the whole config/playtree stuff and m
> uch
> more, if we use an _intelligent_ locking system (ie no lock in the playing l
> oop).
> 	Albeu
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
> 
> 


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu