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

[Arpi]

Hi,

>     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

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

>     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);
> 2) load loadable plugin if need and get it's config structure;
> 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

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

keep config layer separated, as we defined as one of teh main goals.
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

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

== rewrite it

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


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu