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

[Andriy N. Gritsenko]

    Hi, Arpi!

Sometime (on Monday, May 19 at 13:13) I've received something...
>> config_group_info_t* optional subconfig (config_t*).

>why???
>forget subconfig

I meant something like:

config_t global_config[]={
  {"~File", NULL, CONF_TYPE_GROUP, 0, 0, 0, file_config, NULL},
  {"~Video", NULL, CONF_TYPE_GROUP, 0, 0, 0, video_config, NULL},
  {"~Audio", NULL, CONF_TYPE_GROUP, 0, 0, 0, audio_config, NULL},
  {NULL, NULL, 0, 0, 0, 0, NULL, NULL}
}

then we could add optional items (to video_config[] for example) by GUI
not in common config but in any. :)

>> >//*** this is not a valid type, but the number of types:
>> >  CONF_TYPE_MAX
>> >} config_type_t;
>> 
>> Also I'm against of deleting CONF_TYPE_LIST here - it may be very useful
>> in many of cases - I've written examples before. It you will stay only
>> with CONF_TYPE_STRING_LIST then [G]UI has no ways to get hints which
>> choises we have there. If you want to force [G]UI to have __only__ input
>> field for string "any,some,next" then I don't think it's useful because
>> we just deny [G]UI to have selection list box other than filters. If you
>> want extra examples I could find more. And you were agree with me we have
>> to have extended list type. :)

>i don't really understand your problem with gui here.
>guis should implement filter setup dialogs, with filter-dependent configs.

    From one of my previous letters:
-------
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".
-------
    For this sample, without CONF_TYPE_LIST we can only type some string
("below,fullscreen" for example) in some input field. No hints or known
choises are available for GUI, unfortunately. '-fstype' isn't a module
list, is it? If you need other samples, I could find these. Remember that
string list isn't only for modules nor random string. Do you propose to
handle all these items by GUI manually? Then GUI maker has to know _all_
these items and _all_ choises for they forever. It's a much worse than
add a config type. :)

>commandline filter list parsing will be handled by layer 3, as i described
>in the past. actually it's a string list in the first parsing pass, then
>it tries to load each filter in the list and do 2nd pass parsing with its
>param list.

    For filters that is ok since we already know all filter types and can
handle it manually by second pass. But if list isn't a filter list then
we have no second pass for it (not-module items have no ->config fields)
and list will remain just string with.
    BTW, in GUI modules will be processed by other way (not config at
all) since GUI will not get it as string list but as GUI events (add,
move, remove, etc.). :)

>>     CONF_NOSAVE were here for purpose of config save - no other hints we
>> could have for config parser to don't write it in config if we'll request
>> for saving it. Why you removed it?

>ah, it was for config files? sorry, i'll readd then.
>i thought it's remained from g1's config, where it means no save its value
>(in playtree/configtree param saving/restoring mess).

:)

    BTW, I don't think if GUI is only sample of UI so why don't rename
CONF_NOGUI to CONF_NOUI ?

>> (note: not int since size_t is standard type and is _always_ the same
>> size as any pointer - int  may have other size than  void *  on some
>> systems).

>i don't want the mess with size_t definition, it requires varios
>platform-dependent #includes to get it.
>since size_t is thye only non-C type in cfg.h, it's better to leave it and
>use int. i guess we won't have structs bigger than 2 GB :)

    Then at least unsigned int - it's size is at least 16 bit so max
config_size will be 65535 bytes. But anyway compiler will put some type
conversion code then. ;)

    With best wishes.
    Andriy.