Re: cfg.h (config layer 0 discussion)

    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.