[MPlayer-dev-eng] GUI status

[Uoti Urpala]

On Sun, 2008-04-06 at 20:13 +0200, Alban Bedel wrote:
> On Sat, 05 Apr 2008 20:35:35 +0300
> Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:
> 
> > The GUI won't compile after the libvo changes I posted, and I plan to
> > make several more changes that break assumptions the GUI code
> > currently relies on (especially removing globals that the GUI
> > currently accesses). I'm not willing to maintain the GUI myself to
> > keep it working.
> 
> That would be really great to get rid of all the hacks that are there
> just for the GUI. But ...
> 
> > Is someone else willing to maintain the GUI even if it requires
> > nontrivial changes?
> 
> Nobody is AFAIK.
> 
> > If it is basically maintained but not always kept
> > up to date with incompatible changes elsewhere how to deal with that?
> 
> You don't do changes that break the GUI if you are not willing to fix
> the GUI side. That's as simple as that.

Your phrasing is unnecessarily confrontational IMO, attempting to
dictate what must be done when you aren't even working on anything
relevant, and with no justification for your view.

> > Do we want to have "last version known to support internal GUI"
> > available to users?
> 
> In other words forking the GUI and leaving it behind. I expect the wide
> majority of users would be delighted by such a move.

I do agree that the GUI still has value and it does have users (though I
don't know enough statistics about the portion of people who use no GUI
or use an external frontend to judge whether a "majority" would care at
all or not). However it seems hard in practice to keep it constantly
working without preventing the development of the rest of MPlayer.

The basic problem is that MPlayer has no API that would allow
implementing a GUI. So instead the current GUI has been implemented with
hacks that rely on internal details of other code. That means it breaks
when internal details change. And as a consequence it's pretty
impossible to do large architectural changes without breaking the GUI.
If the GUI had a proper API to the rest of MPlayer I'd keep that
working. But it does not.

I'm willing to improve the architecture of MPlayer, but that is in
itself a fairly large task. If I'd have to become the GUI maintainer at
the same time to keep it constantly working the task would become
impractically large.

I believe it's worth it to improve MPlayer's architecture even if that
does mean losing the internal GUI at least for a while. Without doing
that I see little alternative but overall stagnation with mainly minor
tweaks to improve details. And there are still external frontends so
that people who want a GUI will not be completely unable to use the
newest MPlayer code.

So, as a summary: saying "you must yourself fix the GUI if you make any
changes to other code after which it breaks" effectively prevents doing
large-scale changes. And I believe such changes are needed and useful
even if they do break the GUI (at least temporarily).