[MPlayer-dev-eng] [PATCH] MacOS X Application Bundle Support

Reimar Döffinger Reimar.Doeffinger at stud.uni-karlsruhe.de
Wed Dec 22 23:41:59 CET 2004


Hi,
> >>>You can be sure that I will vote for _removing_ our current Gui 
> >>>before I
> >>>agree on adding yet another such a permanently broken piece of crap.
> >>>And that's what it will become unless it only uses slave mode and 
> >>>then
> >>>there's no need to have it in MPlayer's cvs dir (a Gui is a lot of 
> >>>code
> >>>to download for people who have no use for it).
> >>>
> >>I agree. But why not removing the current gtk gui?
> >
> >Sidenote: It's a mix of GTK and xlib unfortunately, if it were GTK
> >only it would be easily portable to Windows and Mac OS X and much more
> >useful.
> >
> >I don't see why we should remove the GUI (without a good replacement).
> >Some people do like having a GUI, there's no need to take it away from
> >them.  MPlayer is around 27M uncompressed (4.9M compressed), the Gui
> >dir is about 1.1M (175k compressed).  That's not an unbearable amount
> >of bloat IMO.
> 
> Is it possible to remove all gui (xlib&gtk) code from mplayer and place 
> it all in libgui ?

Posssible? Well, a lot is possible but writing a gui from scratch will
probably be easier. The Gui is really implemented in a very ugly way. It
has its tentacles sticking everywhere in the code :-(

> this way it would be possible to create a dyn library for it and create 
> native gui for other
> platform by using dynamic library.

Please! Take me seriously and don't even think about using anything else
than slave mode (ok, you may _think_ about it but please not more ;-) ).
This is the only way both can develop more or less
independant, and given the small amount of interest in the Gui among the
developers this is the only way it will not be broken all the time.
Not to mention that it will lead to a better slave mode and make things
easier for other Guis (also allowing them to have different license -
although not everyone may see this as an advantage).

Greetings,
Reimar Döffinger




More information about the MPlayer-dev-eng mailing list