[MPlayer-G2-dev] Re: cfg.h (config layer 0 discussion)
Andriy N. Gritsenko
andrej at lucky.net
Mon May 19 12:01:01 CEST 2003
Hi, Arpi!
Sometime (on Monday, May 19 at 12:16) I've received something...
>Here's an updated/modified/extended/stipped :) version of Andriy's cfg.h:
>#ifndef __CFG_H
>#define __CFG_H 1
>/* type (menu field) ->p ->min ->max ->priv */
>typedef enum {
>// flag (checkbox) int* reset set -
> CONF_TYPE_FLAG=1,
>// integer (slider) int* min max -
> CONF_TYPE_INT,
>// float (slider) float* min max -
> CONF_TYPE_FLOAT,
>// position (slider) off_t* min max -
> CONF_TYPE_POSITION,
>// string (input box) char** min max - (min/max length)
> CONF_TYPE_STRING,
>// select list (combobox) int* - - config_select_list_t*
> CONF_TYPE_SELECT,
Are you sure if limitation select list to int type only is enough?
>// string list char*** min max - (min/max nr. of strings)
>// (comma-seperated list of strings, to be parsed later or to pass ordered list of strings)
> CONF_TYPE_STRING_LIST,
>// function void* arg1 arg2 (*parser_func)(void*,arg1,arg2)
>// (custom parser func for 3rd party plugins or special applications)
> CONF_TYPE_FUNC,
>// removed option - - - -
>// (removed option, parser should fail with error, with message from *desc, gui should ignore this)
> CONF_TYPE_OBSOLETE,
>// group separator - - - config_group_info_t*
>// (this is NOT a real option, but an option group definition, for gui use)
> CONF_TYPE_GROUP,
It was CONF_TYPE_DUMMY in mine, isn't it? But then we have to add into
config_group_info_t* optional subconfig (config_t*).
>//*** 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. :)
>typedef struct {
> int value;
> char* name;
> char* desc;
>} config_select_list_t;
>typedef struct {
> // TODO!!!!
> int dummy;
>} config_group_info_t;
>/* flags for options */
>// 'min' value is given in config_t
>#define CONF_MIN (1<<0)
>// 'max' value is given in config_t
>#define CONF_MAX (1<<1)
>// both 'min' and 'max' value is given in config_t
>#define CONF_RANGE (CONF_MIN|CONF_MAX)
>// This option cannot be in config file
>#define CONF_NOCFG (1<<2)
>// This option cannot be in command line
>#define CONF_NOCMD (1<<3)
>// This option cannot (shouldn't) be visible in gui:
>#define CONF_NOGUI (1<<4)
>// This option can be used without explicit naming:
>#define CONF_UNNAMED (1<<5)
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?
>typedef struct {
> char *name;
> void *p; /* pointer to variable where store result to, type specific */
> config_type_t type;
> unsigned int flags;
> float min, max; /* valid range */
> void *priv; /* additional pointer, type specific */
> char *desc; /* short description for help and gui */
>} config_t;
>/* note: version has to be first in ModuleInfo struct in loadable module
> to allow us always do validation/version check of module */
>typedef struct {
> unsigned short type, version; // for loadable plugins
I've proposed to have version as unsigned char[] so if we have it as
unsigned short then we will fill it by some macro, will we?
> char *name;
> char *desc; // short description for commandline help and gui
> char *maintainer;
> char *author;
> char *comment;
> config_t *config;
> void *config_defaults;
> int *config_size;
I was mistaken here - not int * but size_t (without '*').
(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).
>// void *handle;
>} module_info_t;
>#endif /* __CFG_H */
>Any questions/suggestions?
>(I've tried to apply the ideas/comments from that thread)
>Problem:
>we should store some reference inside the module_info_t struct to the
>actual module entry point (maybe the addess of the open() func? or the
>functions_t struct? do we need to store dlopen() handle there?)
I've proposed to have open() here. It may be useful to have even
control() pointer here also. :)
With best wishes.
Andriy.
More information about the MPlayer-G2-dev
mailing list