[MPlayer-dev-eng] GUI status

[Benjamin Zores]

Ivan Kalvachev a écrit :
> On Mon, Apr 7, 2008 at 2:14 PM, Guillaume LECERF <foxcore at gmail.com> wrote:
>> 2008/4/7, Ivan Kalvachev <ikalvachev at gmail.com>:

> The problem is not that it cannot be synced with the changes, but that
> uau doesn't want to do it, even if it is mechanical replacement of
> variables.

The existence of the GUI has imho nothing to do with latest uau's patch.
It has the side effect of breaking GUI, that's true but the question 
reamins, with or without his patch.

> Geebox libmplayer is like having horse-drawn carriage where you
> replace horses with motorcycles. Sure it works, still there is
> something fundamentally wrong in it.

Because ? All it does is wrapping slave-mode, which is the only way to 
control MPlayer at the moment. It does exactly the same thing that all 
other MPlayer frontends do, except everyone has to reinvent the wheel.

> The ultimate goal of removing the globals and making subsystems in
> hierarchy order, it to isolate the libmplayer from the main.c and
> allow removal of the piped slave interface, replacing it with direct
> library interface.

That's kinda funny.
When I'd suggested a year ago or so the idea of turning MPlayer into
a real library I was flammed so hot, only hell can do.
Not so surprisingly, I was told that the only way to control MPlayer is
to use the slave-mode and that things won't change.
It's interesting to see how you criticizes the _only_ way we currently
have to handle MPlayer (except internal's GUI dirty hack).

>>  Guillaume LECERF
>>  GeeXboX developer - www.geexbox.org
> 
> Hum.. Isn't this conflict of interest. People who create one gui front
> end advocate for removal of another concurrent...

Instead of doing false assumption, just know that GeeXboX is a 
distribution and not a GUI. It's heavily based on MPlayer using libmenu
as its GUI but that's all. So unless you consider libmenu a concurrent
of GTK GUI, your words have no value. Besides, I can't count how many 
geexbox patches related to libmenu have been commited here ...


We currently are in the process of writing libplayer which will 
implement MPlayer control of slave-mode under a C API but that's all.
It's true that a GUI will use it, but that will be the case with or 
without internal GTK GUI. So its life status is absolutely meaningless 
to me, except when it comes with slowing down MPlayer development
or preventing its evolution.

Ben