[MPlayer-G2-dev] Re: g2 config - restart...

[Alban Bedel]

Hi Andriy N. Gritsenko,

on Thu, 15 May 2003 13:16:51 +0300 you wrote:

>     Hi, Alban Bedel!
> 

> >> CONF_TYPE_CHOOSE is string that could have only few fixed choises (in
> >> Gui it will be combobox). For example - oac:lame:mode may have values
> >> "1","2", "3", "4" or "stereo", "joint", "dual", "mono".
> >Ok i think i get it. But then i don't get why you define the possible
> >values with a config_t array.
> 
>     Because parameters of that may have different types.
That's pure non-sense !!! An option is related to a C variable and
afaik a C var can't have sevral type. So if the option is an integer
it can't be a string at the same time !!!! We can provide different
representations for the user (ie if 1==stereo then -oac lame=mode=1
is equivalent to -oac lame=mode=stereo). But an single option
can't set both an int and/or a string.

> See example
> below. Anyway if we have only string parameter but choises are just
> flags then module have to parse that string by itself and set these
> flags. In case of Gui it's even worse - Gui must allocate that string
> then pass it to module so we have two conversions - from Gui internal
> into string then from string into flag by module. Remember that Gui will
> not use option->name for own (because that field is for commandline or
> config parser) but use option->desc instead.

Again no app is forced to use more than the layer0. If you don't want
to deal with strings in your GUI just stick with layer0. Then you can
handle each option type in the way that you want.

> >I thought to something more general but as useal with generalized
> >stuff it's overkill for the simple case. It would be some kind
> >of list of anything with name attached to all possible values.
> >->p would point to the target array to fill. And ->priv would be
> >smthg like this :
> 
> >struct {
> > int type; // Type of the elements in the array
> > struct {
> >  char* name; // Name of this value like "stereo"
> >  union { // The value
> >   int i;
> >   float f;
> >   size_t s;
> >   void* p;
> >  } val; // There i don't know wich is better union or simple void*
> > } *values; // contain all possible value and their names
> >};
> 
> You are going to add one more struct definition to layer 0? I think that
> extra struct definition is unnecessary. Sorry but it may be done by all
> we have already (I mean config_t) and that struct is overkill.

This is just a proposal of an option type. Advanced option type will need
to define such kind of stuff, after all that's why there is a priv field.
So complex option type can take some more parameters than a few flags.

> >As i said it's overkill for the simple case like string list. For
> >string case we could reduce that to:
> >->p : char**
> >->priv : char**
> >where priv contain all possible values.
> 
>     We cannot, unfortunately. For example, we have an option '-fstype'.
> It's string list. It may have only few choises - "none","layer","above",
> "below","fullscreen", and "stays_on_top". All except "layer" are flag
> type options but layer must have integer parameter.
????????
Again an option value must be of a well defined type. You can't shouldn't
mix different value types. Also "none","layer","above", etc aren't flags,
they are modules (wich can optionaly take parameters) like vf, af, etc
are.

[ ... ]

>     So you still can do this anyway - flag CONF_SEQUENT (may be, rename
> it to CONF_UNNAMED?) don't deny you have named parameters but contrary,
> allow you have unnamed ones. :)  I hope, you understood me now. I don't
> like to be forced to type names for all filter options but I don't like
> to allow stupid user type "-info Me:NewFilm" also.

I will NEVER do smthg that arm power users just for the shake of stupid
users.
	Albeu