[MPlayer-dev-eng] GUI status

[Ivan Kalvachev]

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 whole MPlayer is rotting. The whole audio system is also left
>  >  completely unmaintained. It doesn't mean we should remove it at first
>  >  sign of trouble.
>
>  Come on!
>  Comparing the audio system, a root functionality for a media _player_,
>  with the GUI, which is 1. unmaintained 2. hackish 3. deprecated by
>  many external projects, is not doable.

It is bold lie that the GUI is not maintained. There is no official
single maintener, but bugs in GUI are fixed and it is kept it
perfectly working state.
Indeed, there are a lot of things that could be done properly, but
this applies for the whole mplayer.

>  For people who cares about the gui (whom i'm not part of), some effort
>  have to be made IMHO to add an abstraction layer between the actual
>  gui code and the functionalities it needs, which then will have to be
>  made available through slave mode.
>  Then, the slave mode will be enhanced with new functionnalities, and
>  cleaning/reviewing/rewriting the slave mode to act as the famous
>  "libmplayer" idea won't be unfeasible.

Actually the changes uau is supposed to do should help the goal, not harden it.
I hardly find anything in his changes that would fundamentally break
the way current GUI works.

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.

He made same thing around year ago, claiming he had same goal. And for
over a year his changes have been sitting without any beneficial side
effects, just making the code bigger.


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.

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.
If the internal GUI cannot use it, then no other gui could use it
either. This means that the changes are pointless and self serving.


>  --
>  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...