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

[Alban Bedel]

Hi Andriy N. Gritsenko,

on Wed, 14 May 2003 23:17:45 +0300 you wrote:

> >> // string as list - must be obsoleted to CONF_TYPE_LIST
> >>   CONF_TYPE_STRING_LIST,
> >Obsolated stuff in a draft ??????
> 
> I've added that only because there are still options of that type. But I
> think you are right and we must remove it as soon we apply new API. :)
Dunno, imho it still have some use. Sure that in most place where it's
currently used it could replaced by smthg better but that doesn't make
it completly unuseful.

> >> // function		cfg_func*	-	-	revert-cfg_func*
> >>   CONF_TYPE_FUNC,
> >>   CONF_TYPE_FUNC_PARAM,
> >>   CONF_TYPE_FUNC_FULL,
> >I think we should avoid callback based stuff. These were nice in the
> >old days for very specific stuff. But now the only place in G1 where
> >they are really needed is for the -aa* options of aalib. But as in G2
> >each module instance have it's own context it doesn't really make
> >sense as options parsing append before instanciation.
> >For options global to a layer that would make some sense but then the
> >callback also need to get the struct/context on wich it should
> >operate. So this context should be static otherwise you can't put
> >it in the config_t->priv field. But we don't want static stuff so
> >for G2 lib that's anyway completly unusefull.
> >We may let that for app level stuff but i doubt it's really usefull.
> 
>     I've added these for the same reason as CONF_TYPE_STRING_LIST. And
> application level stuff of that type still exist and I wonder if we can
> avoid that - see "include" or "help" options.

As discussed in other mails we should keep 1 of those. But for the
example you point out it's not really needed: 'help' can be a simple
print type and 'include' could be internaly implemented by the
config parser.

> >> // text (none)		char**		-	-	-
> >>   CONF_TYPE_PRINT,
> >That's also only usefull at app level.
> 
> Of course, it is for application level.
> 
> >> /*
> >> all below this have
> >>   ->priv as config_t*
> >> */
> >> // subconfig (dialog)	-		-	-	config_t*
> >>   CONF_TYPE_SUBCONFIG,
> >> // choose list		char**		-	length	config_t*
> >>   CONF_TYPE_CHOOSE,
> >> // select list		char***		-	-	config_t*
> >>   CONF_TYPE_LIST,
> >> // config group (sep.)	-		-	-	config_t*
> >>   CONF_TYPE_DUMMY
> >> };
> >Could pls explain these a bit more.
> 
> 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.
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
};

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.

> CONF_TYPE_LIST is string list but you will have subconfig for all
> available choises - it will help you to have subconfigs for these and
> let config parser check it itself. For example - "vo" will have list of
> currently available video drivers and you can get help for it and write
> in the commandline "-vo jpeg:quality=95" and get rid of option "-jpeg".
Ok, but why is the target type char*** ?
Anyway for the example you point out such type is imho not the good way.
For an option wich handle a list of modules instance the option should
have in priv the array of info struct for the corrensponding module type.
Then possible modules names and their options are retrived from the
info struct array.


> >> // This subconfig has unnamed parameters list (i.e. 0.3:-1:-1 for
> >> example)// It looks like a regular subconfig but different in parsing
> >a> bit
> >> #define CONF_SEQUENT		(1<<6)
> >Dunno if that's really usefull as it's possible to have a parser
> >how handle both mode (ie named and unamed suboptions) and even
> >a mix of the 2.
> 
> What do you mean, sorry? I meant if we have that type of subconfig then
> suboptions of that option don't have to have names - it will be checked
> by parser and don't produce an error. Regular subconfigs have no rights
> to have unnamed suboptions (for example, "-info Me:NewFilm" is nonsence
> at least).

These unamed list come from G1 vf where each filter had to parse his
options himself. So Arpi used this simple way in the firsts filters
and it stuck. These unamed list just imply that you know the order of
the suboptions. -info Me:NewFilm make sense if i know that the first
field is author and the second one title.
See -vf in G1, you can write '-vf filter=100:width=500:45' where 100
is the value for the first field, as width is the 12 field i name it
to avoid entering the defaults of the first 11 fields and 45 is
the value for the second field for wich i don't give the name bcs
i'm lazy ;)
This is what i mean with mixing named and unamed suboptions it's
really possible and nice for lazy power users.

	Albeu