[MPlayer-dev-eng] GUI status

[Benjamin Zores]

Compn a écrit :
> On Sun, 6 Apr 2008 20:13:32 +0200, Alban Bedel wrote:

> mplayer will never evolve if one part of it is holding
> everything back.

Seconded.

Besides that, I see, looking at 
http://www.mplayerhq.hu/design7/projects.html
that there are a couple of MPlayer frontends.

None of them involves hacks, they just use MPlayer's slave-mode.
Having an official GUI is something I may understand but then
it has to go in a dedicated repo and use official's (and only legitime)
slave mode. This way, the GUI may evolve independantly of MPlayer/cli
and the opposite will also be true.

> i was going to flame here, but i realize that many users still use
> gmplayer.

Really ? Cause most of recent distributions include a bunch of frontends
for various players and none of them seem to be gmplayer.

> what is the TODO of the gui code? to be made external and use slave
> mode like all other frontends? if we have a defined goal, maybe some
> developer will take it up.

I really doubt so.
We can't even talk about TODO as there's no maintainer and no one cares 
about it. More than that, I'm pretty sure it'd ease developers life not
having to deal with GUI hacks each time.

FYI, we (at GeeXboX team) have started writing a C wrapper for MPlayer's 
slave mode a few time ago (actually it's a wrapper for various media 
players). Hence we wrote some code to provide an easy way to interact 
with a running MPlayer instance (or to start one) from C programs.
Of course it's far from being complete but can already do much.
It's called libplayer (see http://libplayer.geexbox.org/) and provides 
an common API to handle various players.

Though, it might be possible to extract the MPlayer part from it and 
have an official libmplayer which would be nothing else than a C wrapper
for slave mode. Of course it might probably only works with UNIX-like
(I know nothing about Win32, so can't tell) but also it might provide
an official way to build frontends around MPlayer. It'd also prevent
the various frontends to deal with slave mode and we may change
slave mode internals/controls without breaking frontend's API.

Also, having this libmplayer will ease our work (at geexbox) as more 
people might commit on it and I'd be ok to work on this part (but I'm
no way volonteer for taking care of any GUI around it).

Ben