[MPlayer-dev-eng] Re: new gui

[Matthias Wieser]

Am Samstag, 10. Dezember 2005 21:42 schrieb ods15 at ods15.dyndns.org:
> On Sat, Dec 10, 2005 at 08:43:27PM +0100, Guillaume POIRIER wrote:
> > Hi,
> >
> > On 12/10/05, Reynaldo H. Verdejo Pinochet <reynaldo at opendot.cl> wrote:
> > > - Is this needed at all, or is just me thinking the actual code
> > >   is far from perfect?
> >
> > There are several 3rd party front-ends available... Why not pick one
> > that would be "good enough" and make it the official one? Why
> > re-invent the wheel?
> >
> > I don't use any of them, but this one looks okay on the screenshots:
> > http://kmplayer.kde.org/screenshots.php
>
> KMPlayer I believe is the best available MPlayer frontend, although tbh
> I've never tried it or just about any other mplayer frontend. But I
> still don't really like it as the "official" MPlayer frontend, as it's
> KDE... Having GTK as official frontend is bad enough, KDE IMO is even
> worse...

It should be possible to make kmplayer a Qt application, the KDE 
integration could be kept as an compile-time option. Compared to gtk, qt 
has nearly no dependencies. Additionally qt is *native* on windows, too.


> > > - Is there any good reason why not to make the new gui use
> > >   slave mode for most of his tasks?
> >
> > The only sane way is to use slave mode you mean!
>
> Actually, the main reason most MPlayer frontends suck, is because the
> use slave mode! There is no (stable) "slave mode" API, and just about
> all IPC in general suck, the best way is from within the same code, it
> has most control and responsiveness from the player. So I vote for a
> new gui to be done WITHIN mplayer, not with slave mode

If you want the "new gui to be done WITHIN mplayer" you in return get 
exactly one GUI. If you improve slave-mode all available GUIs will 
benefit.

The question is: Do you want to have one single GUI (which has to fit all 
needs) - or do you want to create an infrastructure for a multitude of 
external GUIs.

Regards,
  Matthias