[MPlayer-dev-eng] GUI status

[Uoti Urpala]

On Sun, 2008-04-06 at 23:36 +0200, Alban Bedel wrote:
> On Sun, 06 Apr 2008 21:28:22 +0300
> Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:
> > 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.

Obviously I wanted to handle things better than just let people with GUI
enabled get compilation errors.

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

I don't have anything against you commenting, I just don't think you're
in a position to dictate what must be done.

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

What is the alternative? Just let it stagnate? As things are now I see
no reason to expect that the GUI situation would improve.

And things like keeping a version with working GUI available could
reduce the number of "alienated" users.

>  And it would also break the rules as
> removing features is forbidden.

Given the track record of "traditional" MPlayer development practices
I'm not sure whether this would be an argument for or against removing
features :)

> In any case no decision to be made
> lightly.

That I agree with. The GUI does have enough users that disabling it does
have significant downsides.

> 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 don't see why it would have to be such a 100% black or white decision.
IMO it seems quite reasonable to disable the GUI "for now" so it doesn't
hold back other development but could possibly be re-enabled later. Of
course if it becomes clear that no one is ever going to fix it then it
could as well be dropped at once.

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

Nobody else is "non-lazy" enough to do the changes even without GUI
support...

>  You choose this task yourself, if it turn
> out you think that you are not up to it, that's your problem.

I believe I am up to the task I chose. The task does not include
becoming GUI maintainer.

>  And
> honestly, I find it plain arrogant that you consider it acceptable to
> break a subsystem just because you don't use it.

I don't consider it acceptable "just because I don't use it". I did keep
video drivers I don't myself use working in the libvo changes. I
consider it acceptable because I consider the benefits to be greater
than the harm.