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

[Andriy N. Gritsenko]

    Hi, Alban Bedel!

Sometime (on Tuesday, May 13 at 16:08) I've received something...
>> 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
                                        ^^^^^^ it's the keyword

    Albeu, I'm sorry for all, but you don't get the main goal. Main goal
is don't use any tricks and don't create too much API calls, it's very
unwanted behavior. Just count number of structs and functions in your m_*
stuff and you'll understand what I mean. And read my demands that I wrote
here before, please.

>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.

    Where you can find all options list? How do you plan add or remove
options from that list? I could ask these questions more and more and
your implementation doesn't solve any of these problems. Please, don't
tell us your implementation is the best, we are about to create an API
which will satisfy all our demands and allow us reach all our goals. When
it ready then (and only then) we will speak about implementation of the
parsers (your m_* stuff is really only config parser implementation). You
can write own (based on that API, of course), I can write own - only Arpi
will decide which is better anyway. ;)
    All you can do for now - say your demands and goals, we all will
discuss these. So I did.

    With best regards.
    Andriy.