[MPlayer-dev-eng] new gui

[Paul TT]

On Sat, 10 Dec 2005 22:42:33 +0200
ods15 at ods15.dyndns.org wrote:

> 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...
> 
> > > - Is gtk the only and *best* choice for this?
> > 
> > QT is availble on Unix, Windows, OSX. I don't know about GTK, though
I
> > know it works on Unix and Win.
> > 
> > 
> > > - 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
> 

i vote for the slave mode. if WE have an official mplayer, WE get the
slave mode to do exactly what we want and we don't break compatibilities
around :-)