[MPlayer-G2-dev] Re: About final cfg.h (config layer 0 discussion)

[Andriy N. Gritsenko]

    Hi, Arpi!

Sometime (on Monday, May 26 at 11:54) I've received something...
>> CONF_TYPE_SELECT is to select _one_ option from list of available ones
>> (for example, combobox). CONF_TYPE_LIST is box for selection, remove, and
>> reorder options from list (box with two fields, for example - left is
>> selected list, right is available options list). These are too different
>> and CONF_TYPE_LIST may have items with different type (see my example
>> earlier).

>ah, now i see.
>but why do we need such type? i can't imagine any use.

    See my example about '-fstype' option earlier. I think it's not only
example.

>> >> 4. Let's change unsigned short type, version to unsigned short version,
>> >>   type in module_info_t definition to have compatibility forever. :)
>> >no
>> >i'm thinking about add type-specific versions
>> >so if we change vf API we don't have to force demuxer, stream, vo etc plugin
>> >authors/users to recompile their plugins just to get version number bumped.
>> Is there a difference between
>> unsigned short type, version;
>> and
>> unsigned short version, type;
>> anyway? This is anyway from this new API so I think it's easy. I'm
>> thinkig about module loader only - putting unsigned short version as
>> first member of struct will let us change that structure in the future
>> and still have version check available.

>but as i said, i want type dependant version, so version number without type
>is useless.

    I didn't mean to omit type but just place version first and type
second instead of type first and version second. :)

>> >>     Discussion about CONF_TYPE_GROUP isn't my concern right now since
>> >> that option is application level only and it's marked as TODO anyway. :)
>> 
>> >actually i've added CONF_TYPE_MODULE which does the same as you expected
>> >from CONF_TYPE_GROUP.
>> 
>> no. :)
>> I've explained that by examples earlier - submenus in GUI aren't modules,
>> are they? I'll try to explain a bit more - see the menu for video encoder
>> GUI:
>> 
>>   File  Video  Audio  Tools  About
>> +      ---------+
>> | Open...       |
>> | Save...       |
>> |---------------|+----------+
>> | Save stream...|  Audio... |
>> | File info     |+ Video... |
>> |---------------|| Text...  |
>> | Quit          |+----------+
>> +---------------+
>> 
>> You have menu group 'File' and subgroup in 'Save stream...' option in it.
>> I've explained good now? :)

>not
>this example is not related to config layer at all.
>such menus are built by gui and not by config stuff.

    Yes, you are right, but why we have to discover another special type
by GUI and don't have a reserved type for it? Anyway if we don't preserve
such type then GUI will have to have two configs - one for menu (with
such type), another for config file load/save (if config parser doesn't
support that CONF_TYPE_GROUP option). It's bad and doesn't worth avoiding
of CONF_TYPE_GROUP. :)

>> Another example for using of CONF_TYPE_GROUP:
>> 
>> (*) constant quantizer [   ]
>> ( ) variable quantizer ----------------------------
>> minimum quant [  ]   maximum quant [  ]
>> ...................
>> ---------------------------------------------------
>> 
>> so we have CONF_TYPE_SELECT with two choises:
>> 1) CONF_TYPE_GROUP including 'vqscale' integer.
>> 2) CONG_TYPE_GROUP including 'vqmin', 'vqmax' and other options.
>> 
>> When we select constant quantizer then second group will be disabled,
>> when we select second group then we cannot change value of 'vqscale'.
>> Config of vf_lavc must have hints for that. Simplest way for it is just
>> have "transparent" CONG_TYPE_GROUP type. Did you understand?

>and how would you define the above situation with your types?
>i can't see how you GROUP helps here.

For example, we assume that name of group is group selection flag. Then
if we define all below we will have all hints to form box above but don't
have any changes for CLI syntax:

config_t const_vq_group[]={
 {"vqscale", &vqscale, CONF_TYPE_INT, CONF_RANGE, 1, 31, NULL, ""},
 {NULL, NULL, 0, 0, 0, 0, NULL, NULL}
}

config_t var_vq_group[]={
 {"vqmin", &vqmin, CONF_TYPE_INT, CONF_RANGE, 1, 31, NULL, "minimun quant"},
 {"vqmax", &vqmin, CONF_TYPE_INT, CONF_RANGE, 1, 31, NULL, "maximum quant"},
.........
 {NULL, NULL, 0, 0, 0, 0, NULL, NULL}
}

.....
{"vqscale", NULL, CONF_TYPE_GROUP, 0, 0, 0, const_vq_group, "constant quantizer"},
{"!vqscale", NULL, CONF_TYPE_GROUP, 0, 0, 0, var_vq_group, "variable quantizer"},
.....

    Of course, we could find another GUI hint instead of option name,
I've used it in my example because option name isn't used at all (GUI
will use only top-level menu names so it's useless for it, and CLI will
skip CONF_TYPE_GROUP).
    That scheme is clean and simple, as for me, and based only on config
layer 0 definitions.

>> BTW, this sample explaining why I wanted to have CONF_TYPE_SELECT as
>> subconig type too - config_select_list_t doesn't allow us to have choises
>> as CONG_TYPE_GROUP but these must be available for GUI. ;)

>but it's a mess to allow different tyopes/pointers in each selection

Forget it, I've said "wanted" - that was in the past, now I think we can
avoid subconfig for such option. :)

    With best wishes.
    Andriy.