[MPlayer-dev-eng] Re: stupid option handling.. again???

[Anders Johansson]

Hi Alban and Andriy,

Hope you don't mind me entering your discussion.

> >I'm sorry if you take that against you but that's rather against your
> >patch. I wrote the first version of the config system (so most of the code
> >in cfgparser.[ch]). In the first system i wanted to let each part of
> >mplayer register his options in order to minimize the number of global
> >vars. In your patch you also use registering quiet a lot.
> 
>     I did that to let each filter register itself so it can be visible as
> soon as it developed. No changes need at filters at all, exempt config
> structure (but you did it too, isn't it?). Changes for new config scheme
> are even less than yours.
>     Ok, we can let filters be undefined and parsed on run. But then we
> cannot reach and configure them from Gui. One way to do it is to describe
> it in Gui explicitly. Another point of registering filters is to allow
> set its parameters in config file. Now you can (I didn't chacked if even
> that is possible, may be not) only describe full -vf (or -vop) line
> there. It's bad for me, I don't like that way. You can solve both these
> problems (and don't mentioned yet a problem with modularized filters that
> may come in the near future) by registering from vf.c. What's wrong with
> it?
>     BTW, I wonder where is that registering stuff you mentioned above? I
> couldn't find it, point me, please. May be it was in too old version of
> mplayer/mencoder so i din't see it?
> 
> >Later it turned out to be a bad idea as by registering you introduce an
> >uneeded dependency. It's just the same (and is better) to simply have a
> >config variable wich is used by the main part of mplayer.
> 
> Ok. I think just as developer. My reasons:
> 1) when I add new filter/etc. then why I want to know every point where
>   that filter is mentioned? I want just add the file and include it in
>   main list. It's a little problem and that is why some filters are
>   missed in documentation yet. Sorry, but it's inconvenient.
> 2) let's think if I want to modularize that stuff. In current project I
>   cannot do it at all - I have all my code linked. If I do anything like
>   a loader then I cannot get any configuration for any modules since it
>   needs static links to main config.
> 

I just wanted to point out that there is an alternative approach to
defining the options available for a module. I found it in alsa-lib,
they are using a config file for each device driver that describes the
available options for that driver. Once the config file is parsed
(builds a tree of structs) the settings are scanned from the driver
and filled in. It seems quite flexible.


> >Another thing that i don't like is all the changes you did in
> >m_config.c.

It is funny how we give away or source and then try to protect it :)
just kidding, but please contact me when you port the new config
system to af I really want to be a part of it.

Cheers,
//Anders