[MPlayer-dev-eng] The future of a GUI

[Reimar Döffinger]

On Tue, Mar 15, 2011 at 12:59:42PM +0100, Ingo Brückl wrote:
> No, not at all. I've already put a lot of time into this and I'm willing to
> continue doing it, but only if it results in something between MPlayer and a
> GUI, not if it's only a permission to play around with code being scheduled
> for removal.

No! If removal was intended anyway I wouldn't have "allowed" you to touch it.
Rather the other way round: Since without you it would be removed (and also
it is quite buggy) I decided to not be as critical about changes to the Gui
and leave it up to you to do things in a more "quick and dirty" way if you so
desire.
However that extra "leeway" stops when code in other parts of MPlayer becomes
involved, and if you want to do something I consider as not improving things
you'll have a good bit discussion in front of you (or you can do it the way
I'd like it done of course :-) ).

> > (note: more about GUI #ifdefs, I am not that much concerned about using
> > things like the stream_ctrl functions, even though I'd prefer if it didn't)
> 
> At the moment, I barely have a complete overview of how all the GUI parts
> work and interact. I surely know nothing about mplayer internals (but am
> willing to learn).

That's absolutely fine, I'll help you with that, just the testing and
other "less exciting" stuff I'll happily leave to you.

> Kevin DeKorte wrote on Mon, 14 Mar 2011 10:26:51 -0600:
> > But this job would be easier if I had a better API to deal with.
> 
> I'm quite sure that starting with the process of seperating the gui code from
> mplayer one's there must be some improvement that'll give benefit to others
> as well. But so far, I'm concentrating on other topics and currently have no
> idea what the interface shall be like. Generally, I like things being simple.

And definitely start with easy things, that "adding a header" thing
was just something that I perceive as "hiding the issue" approach
and I am quite allergic to it.
When the reason for a compiler warning is that the code is bad I'd
rather have the warning stay until the code is fixed.