[MPlayer-G2-dev] Re: G2 CLI/GUI and config API again - a little request.

[Andriy N. Gritsenko]

    Hi, Arpi!

Sometime (on Tuesday, May 13 at  2:16) I've received something...
>>     Why I want that API? I want to add play_stream* to pl_instance_t so
>> we could have another config context for each stream and any parsing
>> function will know it's context - I mean vf_create_chain() from my
>> previous letter to add new filter in the filter chain. So config belongs
>> to play context and play stream has only one play context.

>no, forget this mess
>it's getting the same cross-dependency everywhere as it was with playtree
>code

    Where did you see cross-dependency? Tell me, please.

>don't mix player contexts (don't even define them yet, it's UI thing for
>sure) with underlaying layers and config api, please!

    Ok. How do you propose to pass what of streams do you want to
configure from UI to vf,etc. ? Using statics for it isn't acceptable -
you are one who wants to avoid statics. You may have many streams (for
example, 3 mixed videos and 2 audios from different files) and you have
to configure each of it. If you want to dislike all I've proposed there
then, please, tell me the other way. But we __have__ to pass some stream
pointer from UI/parser to vf_open_filter(). Or you want to give up the
multistreaming idea, eh?

>>     So with that API we will get what you want and UI will create chain
>> by itself. Each time any UI/parser can parse input in only one stream
>> context, isn't it? Initiating new filter will work in order:
>> 1) parse input in current stream context (directly from Gui or for
>>     current input file/sid from config parser);

    UI/config parser have to parse it's input, isn't it? What's wrong?

>> 2) load loadable plugin if need and get it's config structure;

    If we have that plugin loadable then how we can call open() if we
don't dlopen() it? What's wrong?

>> 3) call vf_create_chain() - it is vf_open_filter() but for plugin API;
>> 3a) vf_open_filter() calling vf->open();
>> 3b) open() creating new params instance with defaults or previous
>>     settings (in depending of config variable alike "persistent_filters",
>>     some people will like one way, some other);
>> 3c) open() calling cfg_parse_config() for that play_stream and own params
>>     instance;
>> 3d) cfg_parse_config() setting parameters for instance;
>> 4) continue parsing... :)

>what a mess

It's what _you_ said before. Cite with comments at right:

----
vf_foobar_open(vf_instance_t* vf, void* args){          <-- 3a)
    vf->priv=calloc(sizeof(priv_st),1);                 <-- 3b)
    if(!cfg_parse_args(vf->priv,config)) return 0;      <-- 3c) 3d)
    ...
    return 1;
}
----

What's wrong when I've written it in words?

>> Runtime change of parameters:
>> some UI calls vf->control(vf,VFCTRL_SET_PARAMS,NULL); that control() call
>> will do:
>> 1) create new copy of vf->priv;

>PLEASE!
>it's called priv (_P_ _R_ _I_ _V_) as it's from _PRIVATE_.
>It means it's not your business, you don't even know what is it. ok???
>forget priv, please.
>priv may contain pluginspecific data types, big arrayes, whatever.
>don't mess it with configure, ok?

OK, OK, I don't mind if we create new type of structure and add it in
vf_instance_t. I've wrote vf->priv since vf->priv _already_ have the
configuration variables _everywere_. So don't blame me for that, please.

>keep config layer separated, as we defined as one of teh main goals.

    Without any API at all? :)))))))  May be we have to forbid any UI or
parsers for G2 at all? :)))))))  Gui is the worst! Commandline deprecated
too! Nothing is the best! :)))))))

>ie. pass a clean, config-variables-only structure to the open() functions,
>and let them decide what and how they will use from it.
>forget messing with priv, forever.

>>     I hope it's the best way that can get rid of statics at all. Arpi,
>i doubt

    I don't doubt, sorry.

>> please, correct all what you don't like in these structs and that scheme
>== rewrite it

    But how? You seem to dislike everything now. ;)

>> (but I hope that scheme is already what you wanted :) and I will apply it
>not really...

>sorry.
>it seems we should (re-)discuss the goals and possible implementation ways
>first. probably all goals cannot be reached at the same time, so we have to
>decide which ones are less important, and remove them.
>then define how and what to implement to reach the rest.
>this ad-hoc coding doesm't seem to perform well...

    Tell all goals you see. I already don't know what you want to see
from config API at all, sorry. I wrote what I read from you - you calling
it a mess, I proposed to have strict API - you say all API is parser
specific. I don't know what you want. Sorry. :(
    I'm afraid we will never get good API that way... :(

    With best regards.
    Andriy.