[MPlayer-dev-eng] Re: [MPlayerOSX-devel] MPlayerOSX and the sources

[Attila Kinali]

On Tue, 4 Jan 2005 19:02:41 +0100
Jan Volf <javol at seznam.cz> wrote:

> On 1.1.2005, at 14:39, Attila Kinali wrote:
> 
> > On Sat, 1 Jan 2005 13:44:16 +0100
> > devros <devros at seznam.cz> wrote:
> >
> >> Gui was writen in cocoa.
> >> Yes it's all slave mod, but it's really limited and it's very hard to
> >> improve it.
> >> Sometimes is slave mod buggy and some things not work perfect (progres
> >> bar, volume control...)
> >
> > I know, slave is quite a hack.
> >
> Slave mode is actually slow, complicated and mplayer output is subject 
> to change from version to version making it difficult to parse. Using 
> slave mode I've tried to present convenient user interface the Mac 
> users are used to and it was really hard work and still it has few 
> glitches.
> >>   but mplayer osx is usable.
> >> You can check mplayer osx statistic on SF page 1,554,016 downloads :)
> >> that's maybe every second mac user.....
> >
> > Yeah, we know it's popular.
> >
> It is, but thanks to mplayer project :).
> >
> >> Main mplayer osx autor Javol is trying to write real mplayer gui.
> >> But he will need a lot of time :)
> >
> > How about joining forces ?
> Your idea is welcome. It will probably help both sides.
> 
> > We want to replace the gui for a long time now (it's just the most
> > hacky part of MPlayer) but never got around to do a real design.
> I don't think it's about the GUI design itself (if you mean it this 
> way). It's about the design of code behind. Let the creative people do 
> the job of designing GUI but we can help them by making the code more 
> accessible to external GUI. Then we can do some kind of mplayer's 
> reference GUI, but the more the mplayer code will be simpler and free 
> from the not-so-essential parts the more time could be spent upon 
> implementing even wider media format support and optimizing playback.

What i meant is not the GUI design, that's something what everyone
has a different idea. I'm talking about the interface between the
MPlayer core and any UI (may it be graphical or not).


> > Together we could redesign the whole shit and do it right from the 
> > beginning.
> Definitely I agree, especially with the starting from beginning :), but 
> it is so much work.
> Honestly, I will be glad to help you but it depends on what do you 
> expect from me.
>  From my point of view as of developer of GUI it would be good to 
> completely separate the GUI code and write simple interface the GUI 
> will use to communicate with so it can be compiled as a static or 
> dynamic library the GUI code  will be linked against while preserving 
> posibility of compiling it as the CLI application. This is my idea in 
> basic and that I'm working on now for MPlayer OS X project. The result 
> of my work might be useful for mplayer project too. Definitely I can 
> post the result when it is finished.
> I would like to know your opinions too so let me know what do you think.

Yes, seperating GUI and control is the basic idea. What we now need is
people doing it. I know that quite a few of the MPlayer developers
would like to see such a separation which would clean up a lot of
mess and also solve some problems we have. But very few of them have
actualy the time to do something like this. Now, we would like from
you (ok, make that an "I", as i don't know what the other developers
think) to help us to get the UI code of MPlayer out of it's main
functions and make a clean interface. This could be done gradualy
by moving functionality by functionality to a different file, then
cleaning this up and convert it to an interface which could be used
by other projects too.
So, to sumarize it, what we basicly need is people who help us coding
and who have some experiance what UIs need.


				Attila Kinali