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

[Andriy N. Gritsenko]

    Hi, Alban Bedel!

Sometime (on Tuesday, May 13 at 18:12) I've received something...
>>     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.

    I don't dreaming. All I want is really reachable. And by more that
one way. API will solve all possible problems. It's why we speak about
it. :)

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

    All options must be available. For Gui, for example, and for config
parser, for other example. Or you want create for each application its
own option list? You have that a mess in G1's Gui. Thank you but I don't
like it at all. Just read the thread - all want have all options to be
available at certain point. Unfortunately, cfg_t (aka struct config) is
auto or static so we cannot reallocate it to manage it's child pointer.
Another way may be to have some list of configs to scan it all but it's
a bad way.

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

    Disagree, and not only me but others too - see the thread.

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

    I'm sorry if you misunderstood me. I don't have you as enemy. Just I
have other point of view to config means so we could not get a consent.
We are just kind of competitors and I hope it will make our work much
better. :)

    With the best wishes.
    Andriy.