[MPlayer-dev-eng] GUI

[Ivan Kalvachev]

2007/2/21, Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de>:
> Hello,
> On Wed, Feb 21, 2007 at 08:55:39AM +0200, Uoti Urpala wrote:
> > The GUI is currently broken after the mplayer.c changes. I'm hoping that
> > someone else will fix it. If no one does within a couple of days I'll
> > hack it enough to make it compile.
> >
> > I think the preferred way to fix it would be to change the global
> > variable accesses to use the command/property interface instead,
> > extending/improving that if necessary.
>
> I still can't see why you couldn't just send a patch and wait a few days
> like I suggested on IRC instead of applying a patch that you know would
> break compilation.
> mplayer.c has been a mess since ca. 5 years, why do 3 days matter that
> much???

What the hell is going on in MPlayer.

1. I don't see any kind of discussion about the changes . Just
announce that there is going to be such.

2. I've never got to see the patch that messess with great number of
code lines in mplayer before it got committed.  Just a few days ago in
IRC we were talking about mpctx variable names.

3. The commit is adding new files out of the blue with great number of
new code, that is obviously just moved. It just erases the history of
that code. (Not using svn copy to preserve history).

4. The commit breaks MPlayer. Well it may not break the whole mplayer
completely but it breaks important parts of it. What happened with the
presumption to never break mplayer and fix it immediately if that
happens? Is that part of the history and could everybody break
arbitrary parts and saying he MAY fix it in few months/days.

5. On IRC I wanted to make new release before doing such drastic
change. The Uau answer was that he cannot wait a week for release and
he must commit the code so he could continue working on it. WTF?


All these are even without coming to discussing what the patch.
>From what I see you got everything completely backwards.
The fact that your changes doesn't even touch mencoder is proof of that.

Reading, parsing and looping of many file have always been the
prerogative of the MAIN() program, even if it is broken on subfuctions
and they are exported to another files.

The very basic idea of creating MPContext is that all structure for
playing of SINGLE file should be in one place. The playtree stuff is
supposed to remain in the MAIN calling application.

Well, it looks that this context didn't had that as target, it just
creates structure for the slave interface... And I'd keep some of the
globals in that case (aka the command line and playtree one).


I request revert of the commit until we have proper discussion, proper
patch and proper way to commit it back.