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

[Andriy N. Gritsenko]

    Hi, Arpi!

    Some words. We must have the concept, which we creating an API for,
in the first place. So we are talking about concept now, aren't we?

Sometime (on Wednesday, May 14 at  0:52) I've received something...
>> 1) Inserting and removing filters is not the job of the config engine,
>>    aside from preparing the config variables for a filter when it's
>>    being added.

>1000% aggree

    Don't argue, it may be the best thing. You didn't understand me. I've
told not about inserting/removing filters as config engine job but about
callback from config engine to core for doing that job by appropriate
engine. Only that and nothing more. :)

>> 2) For initializing a chain, the config system can just take in the
>>    string, and return a chain of config structures. The player then
>>    proceeds to load and initialize the filters along with the codecs.

>1000% aggree

    Ok. I'll try to explain you with an example. You have a Gui encoder.
You didn't started encoding yet. You opened dialog box for filters. Are
you surprised with that? Do you still think if Gui may only have string
input for the filters? If you think so then Gui is just graphic command
line for you and users will call us hellmakers.
    So we are in that dialog box. It consists of two panels: on left we
have created filters chain, on the right we have full filters list. What
I want (I'm there an user)? I want take a filter in the right pane then
drag it in selected place in the left (not only to end of list but in the
some place there), drop, and after that doubleclick on it to configure.
Any other behavior isn't understandable for me.
    So our concept _must_ allow that. We _must_ allow get a command from
UI to insert or delete filter in the any place then return to UI but
don't start encoding yet. Do you understand me?

>> 4) With that in mind, I think it might make more sense for the config
>>    system not to handle filters at all during the initial parsing
>>    phase, but just store filter chain strings provided from the
>>    command line or whatever. Then, when we get to the relevant file in
>>    the playtree, the player can split up the filter chain/tree, load
>>    the appropriate filters and connect them, then call the config code
>>    *again* with the config strings it has for each filter to
>>    initialize them.

>this is what i want, and described in a long mail sent 3 mins ago.

    If we talking about command line interface only then this is ok. For
UI it's bad - why user have to close dialog box to let player create all
chain then open it again to configure filters? It's hell for the user. Do
you want to deny Gui at all or you think Gui isn't like a parser?

>> 5) Perhaps you'll also consider this part of the config code, but it's
>>    very different from the main options parser, IMO: There needs to be
>>    code somewhere to allow interactive editing of the filter tree, so

>it's planned via control()

    How you plan to use that control() if you disallow UI/parser to know
that control() exists?

>but i guess stream path merging/splitting and graphedit cannot be expected
>before g3. first we should cleanup g1 (actually reproduce some parts, port
>the rest) to have something we can play (and not suck) with.

OOPS... we plan to deny API for UI before g3? It's too sad, we can die
before that and don't see API for UI... :(((  All we need is to create an
API function to pass these insert/delete commands to vf or af engine. Is
that too hard? Only one function will solve all problems so UI can do
callback without exiting.

    Andriy.