[MPlayer-dev-eng] GUI status

[Compn]

On Sun, 6 Apr 2008 20:13:32 +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.


mplayer will never evolve if one part of it is holding
everything back.


>> 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 was going to flame here, but i realize that many users still use
gmplayer.

>
>> One possibility would be to move the GUI code to a separate
>> repository with a dependency on an explicit version of the main
>> MPlayer repository. Then the main repository could be developed
>> independently of the GUI, and the GUI dependency could be updated to
>> a newer version once it has been checked to work with that. Of
>> course this does require that there is a somewhat active GUI
>> maintainer that at least makes sure security fixes appear in the GUI
>> version too etc.
>
>I doubt that this would achieve anything when the root of the problem
>is a lack of maintainer.
>
>	Albeu


has the gui ever been maintained after Zoltan Ponekker (Pontscho)
created it? will it be?

i see a lot of misc code cleanups, some compilation fixes, a win32
port... a bunch of external patches and fixes and vulns.

what is the TODO of the gui code? to be made external and use slave
mode like all other frontends? if we have a defined goal, maybe some
developer will take it up.

maybe arpi wants to maintain it. ping arpi

-compn