[MPlayer-dev-eng] GUI status

[Alban Bedel]

On Sun, 06 Apr 2008 21:28:22 +0300
Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:

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

My phrasing was perhaps a bit direct, but the justification is obvious.
Knowingly breaking compilation is explicitly forbidden, and have always
been one of the most important rule of MPlayer development.
You are right that I haven't been working on MPlayer much lately, but
considering my past work on MPlayer (much of it being closely related
to UI interfacing and cleaner API), I do think I'm qualified to comment
on the topic.

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

It is annoying, but IMHO alienating many users is not an option on a
project as widely used as MPlayer. And it would also break the rules as
removing features is forbidden. In any case no decision to be made
lightly.

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

The properties API can be used instead of most of the ugly hacks
currently used by the GUI. Sadly nobody (and that include myself) took
on making the GUI to use it yet.

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

I agree, the GUI is holding quiet some stuff back, and I don't like it
either. There is only two solution, either we keep it as part of
MPlayer, and it should be treated like any other code, or we drop it in
favor of frontends. I'm no GUI user so I'm not in a position to judge
if there is any frontend as feature full as the GUI.

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

No, you laziness prevent it. You choose this task yourself, if it turn
out you think that you are not up to it, that's your problem. And
honestly, I find it plain arrogant that you consider it acceptable to
break a subsystem just because you don't use it.

To summarize my position: I have no problem with dropping the GUI if
there is frontends up to the task and we all agree. But I have a big
problem with knowingly breaking any of MPlayer's subsystems, even
"temporarily".

	Albeu