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

[Jan Volf]

On 4.1.2005, at 20:31, Attila Kinali wrote:
>
> 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).
>
Ok, it seems that now we are talking about the same thing :).

> 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.
>
I try to do my best, though I have not much time too but since I 
already started, it would be shame not finish it.
My idea is first to rearrange the main function code to several parts. 
The first part will do the player initialization of everything that has 
nothing  to do with the file to be played. The second part takes the 
file and try to open it and get properties of it. The third part is the 
actually the playing code initializing the rest of what is needed and 
then accepting  play, pause and stop commands. The setting and getting 
various parameters will be done independently thru one pair of accessor 
functions to keep the interface simple.
This will be implemented as interface any one can use for it's own UI 
based upon either simple thread player or multithreaded with separated 
thread for each instance of player separated from GUI thread as I plan 
it for MPlayer OS X. For example the command line interface does not 
need multithreaded player but for sophisticated UI it will make 
difference.
This is what I intent to start with.

Your opinions?

Jan Volf