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

[Alban Bedel]

Hi Andriy N. Gritsenko,

on Tue, 13 May 2003 16:34:45 +0300 you wrote:

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

Here are your goals :
1) independency from all other API;
2) independency from any parsers/UI impementation;
3) no global static vars (since all may have many instances);

So what you want is just a fully passive descriptions of the options with
no API provided to set them or what ? It may make sense but for the final
users of the lib it 'may' be nice if they have a way to automatically
convert user input (ie string) to the final c type without having
to know anything from the underlying process.
Anyway don't dream. If an apps should be able setup some struct in an easy
way but without having the definition at compile time you need to
provide some API otherwise it'll be a pain as C isn't provinding any
kind of introspection.

> 
> >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?
Imho we don't need a global list of all options avaible. Just a way to
retrive the options for this or that specific module, no more is needed
in G2 lib.

> How do you plan add or remove options from that list?
As i said imho no list is needed, so no need to add/remove.

> 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.
Pls can you point me to the place where i wrote that my implementation
is the best ? I said this :
> >Concerning the API avaible in G1 i would say that i pretty satisfied
> >with the overall design.
        ^^^^^^^^^^^^^^^^^^
I would never dare to say that it's well implemented, but i'm satisfied
by the fact that now option parsing (ie string 2 C), context saving
(ie m_config) and command line/ config file parsing are well separated
and no more 100% inter dependant as it was before.

> When it ready then (and only then) we will speak about implementation of
> the parsers (your m_* stuff is really only config parser
> implementation). 
Yes and no. It was writed FOR a config parser and G1 design (ie global
vars evrywhere) doesn't help to make multifile settings simple (hence
the whole m_config stuff and too much complexity in m_option).
But i really think that a whole bunch of the idea (and experience) that
are in there can be reused. For example string 2 C conversion in a
generic way is imho a good idea as it would help a lot CLI writers.
On the other hand GUI writers may prefer to know the C type behind
a specific option and directly access the struct field.

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

Pls stop this nonsense. I'm not fighting against you or anything of that
kind. I refused some of your patchs. So what ? Does that mean that i'm
your ennemy now ??
	Albeu