[MPlayer-G2-dev] Re: Data communication between demuxers and UIs

[Andriy N. Gritsenko]

    Hi, Attila Kinali!

Sometime (on Monday, January 19 at 11:59) I've received something...
>On Mon, 19 Jan 2004 01:32:28 +0200
>"Andriy N. Gritsenko" <andrej at lucky.net> wrote:

>> >Yes, it's simple and that is the problem with it, it's too simple.

>> >1) How do you represent the variables, their types and ranges ?

>>     Of course, as usual, via fields of config_t for each variable. All
>> variables are available as NULL-terminated list, as usual but it must be
>> not static structure for module but dynamic list instead.

>That's clear, but how do you set/get the variables itself ?
>how are they exported ?

    I'll try to explain it again. Of course, node has no variables until
node isn't fully inited. After it's done, node set config_t list in some
node->config (note: it must be not static as module->config but only
per-instance config so as I've proposed before we have to have config_t*
and config_data* entries in each node structure not in module only). And
UI knows it's dynamic so it'll do all as usual but after init only. :)

>> >2) How do you avoid inconsistencies (possible sig11) when the node 
>> >   changes the available variables and their ranges.

>>     Each time when UI wants change (select, etc.) something in current
>> tree of chains then it will just build own windows etc. based on current
>> tree of variables. So we agree to don't hash all inside of UI and it's
>> all. :)

>Ok.

>>     If you mean the case when current value is outside of new range then
>> I think filter/codec/etc. anyway will not get that current value from
>> previous filter/codec/etc. but it may do only UI.

>That's something the UI has to handle. 

>> >3) How do you signal changed values. Rechecking all structures
>> >   for changes isn't a good idea.

>>     Let's see - when values may be changed? Only when UI sends some
>> signal to node - play new file, insert new filter, etc. While you play
>> the same file it's silly to change anything by node itself. Then UI will
>> anyway recheck all as I said before in 4). If UI doesn't want change
>> anything then it'll just leave all as before. If UI wants then it'll
>> change it and send some request to node to accept changes.

>Sure there isnt any silly container out there, that needs to change
>the available variables or the variables itself at runtime ?
>I've seen too many stupid designs in the last few months.

    Hmm, it may be a little problem. Anyway there is field flags in
config_t so we may create some CONF_CHANGED flag to notify UI there was
changes in it. And anyway since we agree UI cannot cache config items,
these items will show all changed values when UI will want see them. :)

>Greetings

    With best wishes to you too.
    Andriy.