[MPlayer-G2-dev] Re: G2 CLI/GUI

Arpi arpi at thot.banki.hu
Tue May 13 01:58:50 CEST 2003


Hi,

> My last question for today I promise.
> 
> > >     I'm also! :)  But may be anyway we have to scan all available modules
> > > at startup (don't load but check) - I don't think if check only by file
> > > name is enough.
> >
> > Not acceptable. This sort of bloated slow startup nonsense is what I
> > expect from stuff like mozilla and gimp, not mplayer!
> 
> Ok. How are you going to add plugins to g2 without asking/waiting for weeks
> for somebody to commit your plugin to cvs ? You can make patch or fork mplayer 
> too, but distributing a binary (+ source) is IMHO more flexible and 
> convenient. 

runtime loadable plugins aren't a no-no, they are even possible in g1!
(afair it's --enable-dynamic-plugins or so)
it's a bit limited, as you cannot export gloabls and set them using the
config parser, but for most codecs/filters it's ok.

Rich said that loading all available plugins at startup to see they are
there, is nonsense, and i agree.

btw, about your problem, wiht slow patch accepting:
if a patch is good (== well made, clean etc), it will be accepted faster.
remember how messy yoru first demuxer patch was, and how teh final
(accepted/commited) one looks like. if we commit yoru first version, it
would still be that messy unstable buggy code in cvs, in long term resulting
bad code quality.

mplayer is (ok, was) superior to avifile, xine etc, because it was stable,
relative bugfree and always compilable, thanks to much more strict patch
accept policy. even if you're unhappy, i'll be same (or more) strict on g2.


A'rpi / Astral & ESP-team

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



More information about the MPlayer-G2-dev mailing list