[MPlayer-G2-dev] Re: G2 CLI/GUI

[Alban Bedel]

Hi Arpi,

on Mon, 12 May 2003 20:25:46 +0200 you wrote:


> Albeu? :))))))))

Until now all i read here don't seems really new. What you describe with
passing struct is alredy possible with the API avaible in G1 (m_struct_t).
I know that you don't like the stuff i putted in for the vf. To be honest
i don't find it so good either. The problem with G1 vf's atm is to get
away from the old method (ie passimg string to the vf) to the new method
(passing struct with the data in 'C format').
I intend to improve that in G1 so that no more string are passed to
libmpcodec and that it doesn't touch priv anymore. Atm string 2 struct
is done in vf.c wich is BAD, this should be moved up to the config
parser.

Now for G2 imho you are right that 'objects' (or module or whatever)
should export a description of the struct they need as param. But imho
'objects' should also put the definition of this struct in a public
header so they are fully useable without needing to use the
'option API' (for those who don't want to).

For the dlopened stuff it's a bit more tricky. A GUI could load the
objects as needed, no problem. But for a CLI you need to know all
parameters when parsing the command line otherwise you can't
check if the parameters are valid or not. It would still be possible
to load the stuff as they are needed but that would be more a pain
than anything else. Anyway i think we should stay away from the idea
of registering and just have the 'objects' export the definition
(wich then may or may not be used by the user of the objects).

Concerning the API avaible in G1 i would say that i pretty satisfied
with the overall design. By this i mean having the options parser
completly independent of the rest. But the m_option implementation
is tailored for the m_config system wich is bad for G2.
Imho options parser (ie string 2 C value) should be rewriten with
a better (ie simpler, cleaner) API for general use. Then writing
something like m_struct to setup struct instead of vars is really
easy.

So in short my pov is that we don't need something really new. The
concepts needed are all alredy avaible in G1 but their implementation
herit the whole G1 history (ie backward compat. needs, etc) wich
make the code unusable for G2 but a good part of it could be resused
to create a better, cleaner API wich don't have all the m_config crap.
After all if each instance of a module get his own struct their is really
no need for the 'context saving' (ie m_config) wich is required by G1.

	Albeu