[MPlayer-dev-eng] An attempt at libmplayer

[Reimar Döffinger]

On Thu, Sep 11, 2008 at 04:48:27PM +0200, Attila Kinali wrote:
> On Thu, 11 Sep 2008 15:30:45 +0200
> Reimar Doeffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> wrote:
> 
> > > BTW: having MPlayer as a library would be a possible solution
> > > to our long outstanding GUI problem.
> > 
> > Huh? Our "GUI problem" is that we have an incredibly badly coded
> > include GUI nobody cares to maintain, I do not see a libmplayer
> > changing that.
> 
> As in "it would allow us to make it a lot easier to create
> an official gui that isn't bound by the problems of the slave
> interface and finaly let us remove that broken shit that calls
> itself gui"

Well, I see the thing that holds that back is the lack of someone
caring, not a libmplayer.

> > Neither do I see it solve the problems that e.g. smplayer has due
> > to the official GUI interface (aka slave mode) not being
> > well-maintained.
> 
> The slave interface has various problems that are hard to
> adress using the current design.

My opinion is that they would need much less work than a libmplayer.
There is a general usage issue due to text parsing etc. (which could
possibly also be "fixed" via an additional e.g. binary, SHM slave mode), but
architecturally, I think a libmplayer needs almost all the changes
to fix the slave mode issues and a big load more.

> > Personally, I find it very funny how there are people who praise
> > the approach of some web browsers to use many different processes
> > as the greatest thing since whenever while here we mostly get
> > people complaining about having to launch a separate process 
> 
> Uhm.. could you calm down a bit? I'm not proposing that we
> go the chrome way and throw away everything that we established
> over the past years to follow a hype created by some people who
> have no technical clue whatsoever.

Hey, I just wanted to point out that I find it quite silly when someone
says "but I don't want to launch it in a separate process" without
giving a real reason. Basically using a separate process is just a
way to make it harder for developers to use stuff that can cause
a deadlock (yes, there are other reasons, but I have the impression
that is the main one, even though it is often expressed nicer).

> What i would like to see adressed here is to have the most
> broken subsystem that we are carrying around for years now
> to be completely removed so that we can easy the burden of
> maintenance on us.

Well, I just do not think it is the best/fastest solution for _that_
problem - and IMHO smplayer is a solution to that problem - as far
as it can be with slave mode being as unstable as it is.
I think I will have to add the disclaimer that I believe that in many
cases having logic and GUI in separate processes is the better solution
technically, and I am only in so far in favour of a libmplayer as it
means someone will clean up some really old and bad code (though for
me, cleanup is a process, not a "throw everything and a dumpster and put
something new there"). Oh well, I'm sure everyone here has heard that
all too often from me by now.

Greetings,
Reimar Doeffinger