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

[Andriy N. Gritsenko]

    Hi, Rich!

Sometime (on Tuesday, May 13 at 18:41) I've received something...

>Arrg, stop and think for a moment before saying more such nonsense!!!

>This is a limitation of the particular (TEST!!) player, not the API.
>There's no reason your config code should know or care if the calling
>program is using a static pointer to a single chain, or some sort of
>multi-chain multi-context approach.

    Yes, you agree with me - we have to don't use static pointer but some
pointer in the structure for some stream and create a good API. :)))))))

>> >why do you want to call its open() in config level?

>>     See what I've said above. Only parser can tell you if you need to
>> load that plugin or not. Anyway I've described then _not config_ work but
>> all plugin load sequence - no difference who will call it in details, or
>> test-play.c, or something else.

>Yes, there is a difference. The config code should just set variables,
>not load/initialize plugins. You're getting delusions of godhood
>here... The config code is not the centerpiece of mplayer!

    Config code does the full control of mplayer as well - your mplayer
without that config code cannot play anything because it doesn't know
what it has to play. :)
    Ok, it seems you still don't understand what I meant. That behavior
is just exception for af/vf since plugin list is very specific sort of
config objects. I'll try to explain it with example.

    For example, you have at some time filter chain:
vf_a -> vf_b(1) -> vf_c -> vf_b(2)

CLI or GUI has found that it must be rebuilded by inserting vf_n after
vf_a. Tell me, what will you do: exit from commandline parser with some
exit code or just insert this filter into chain by standard core API
call? I think if you exit then you will get a big headache to implement
all possible exitcodes support in the mplayer (remember - your condition
was to don't call anything from parser), and you have to return into
commandline parser to continue after that, it isn't implemented also.
Also remember - we have CONF_TYPE_FUNC_FULL already, it's backward call
to some core or application function also with standard API.

Another examples of similar tasks are:
- delete filter vf_c from that chain;
- move filter vf_b(2) after vf_a and before vf_b(1);

Do you have any suggestions to do it without management of plugins by
UI/parser? I want to hear it, tell me, please.

    With best wishes.
    Andriy.