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

[Andriy N. Gritsenko]

    Hi, Alban Bedel!

Sometime (on Thursday, May 15 at 15:32) I've received something...

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

    But CONF_TYPE_CHOOSE is really _not_ string _but_ subconfig. Just
look at it better. String at ->p is _only_ for reference (and may be
omitted in many cases). All difference between CONF_TYPE_SUBCONFIG and
CONF_TYPE_CHOOSE is that CONF_TYPE_CHOOSE cannot have more than one
subparameter but CONF_TYPE_SUBCONFIG may have as many as need. Did you
understand now? :)

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

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

    Again. Do you have to recongnise if that option has to be parsed
differently and have another types of ->p and ->priv? So CONF_TYPE_* are
created to make that difference, isn't it? I hope I've answered to your
question. :)

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

    There is an option '-fstype' in G1. How do you propose to parse it?
It has _only_ simple C type parameters but these parameters are different
type. Ok, we can change that syntax from "above,stays_on_top,layer=1" to
"above:stays_on_top:layer=1" to have just CONF_TYPE_SUBCONFIG but why we
have to change a current syntax?

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

    What is option value for subconfig? See my comment above.
CONF_TYPE_LIST is also subconfig - it really is combination of
CONF_TYPE_STRING_LIST and CONF_TYPE_SUBCONFIG.
    If you have choises as modules then you are right - we have to have
only list of these with parameters. But if you have choises as list of
some flags or values then why you have to force application parse it by
itself (since you never have subconfig to parse it by config parser)? I
cannot understand that step back.

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

    Are you so spite on users? :)
    But anyway - what's bad with flag CONF_SEQUENT? Other hand it's flag
CONF_MUST_HAVE_A_NAME but with other sign. Why do you after forcing user
to write "opt=value" instead of "value" for some options? Why you want to
allow just "value" always? I didn't get it, sorry.

    Andriy.