[MPlayer-dev-eng] GUI status

[Uoti Urpala]

On Wed, 2008-04-09 at 19:40 +0200, Diego Biurrun wrote:
> On Sat, Apr 05, 2008 at 08:35:35PM +0300, Uoti Urpala 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.
> 
> What do you mean by "maintain" and how much work do you think your
> latest libvo changes would require to get the GUI back in sync?  One
> day?  One hour?

The libvo changes in isolation aren't the main issue. I intend to do
(and have already partially implemented) further changes such as the
removal of most globals. Those would likely require constant changes to
the GUI as it's currently implemented.

> I have very mixed feelings about removing the internal GUI.
> 
> Without a doubt the GUI is clearly unmaintained, has known bugs, has its
> tentacles all over the codebase where it does not belong and the code is
> ugly.  Nonetheless the GUI has its users who appear to be more or less
> happy with the way it works.

The unmaintained/buggy/ugly parts are not so much a direct reason to
remove/disable it as long as someone still wants to use it. The main
problem is the "tentacles all over the codebase" part (not just parts
directly referring to the GUI in other code, but also assumptions on
other code that the GUI relies on). That makes improving other code
without breaking the GUI harder.

> In the past, several others have voted for or requested removing the
> internal GUI before.  So far I have always opposed this idea because I
> thought that we would be doing our users a disservice by removing it.
> 
> Clearly most people do use a GUI with their player.  And clearly no
> developer uses the GUI.  Who is best served by which course of action?
> Users by keeping the GUI, developers by removing it?  I'm not sure.

Of course the goal is that in the long run users would also benefit from
improvements that are easier to create without the GUI in the way.

I'm not talking about deciding to irreversibly remove the GUI. The main
thing is to avoid the need to consider and possibly fix it at every step
when working on other code. I don't consider it to be unrealistic that
it would be fixed later; but of course that would require that there is
still some developer interest in it.

> So what is the alternative.  Has anybody tested the external GUIs and
> checked if any of them is in good shape?

Disabling the internal GUI would probably increase interest in their
development if they aren't :)

> In any case, removing the GUI before the next release is not acceptable
> IMO.  Which reminds me, what about creating a release soon?

How would the next release be relevant? Because you want to time such
changes after a release and there is "too long" since the last one?