On Tue, Nov 27, 2001 at 04:20:58AM -0500, Gerard Lim wrote:
> Correct me if I'm wrong, but does it rely on having the descriptions,
> keys, and types of options in one file:  sysdefaults.h?  I can see now
> how easy it is to add a new option.

Yes, that's right.  Because the maintainers of the server also maintain
gum, so synchronisation can be easy.  The file sysdefaults.h contains
the procedure for adding new options.

> However such a thing doesn't exist for COW.  The keymap and options are 
> 'hardcoded', as it were, in two files:  input.c and defaults.c (correct me 
> if I'm wrong).

Yes, that's right.  This should change.  Suggest how to change it?

Idea: special compilation mode for COW that causes getdefault() and the
datatype variants to track what is given to them to fetch.  Use the
compiled result to generate a list of parameter names and types that are
placed in a header that is used by defaults.c.  Change getdefault() to
issue a warning when a new parameter is seen that is not in the list.

Audit the code periodically using regular expression searching to
verify that all the defaults are known.

Since the client is in maintenance mode, and no new major features are
being written, the cost of keeping the known parameters in the list
should be low.

My quick guess at the size of the task:
1) files that contain getdefault or variants,

% egrep -l "intDefault|booleanDefault|getdefault" *.c|fmt
audio.c cowmain.c defaults.c defwin.c docwin.c findslot.c gnu_win32.c
input.c main.c newwin.c parsemeta.c playback.c playerlist.c sound.c
winsprite.c x11sprite.c x11window.c

2) total number of files,

% egrep -l "intDefault|booleanDefault|getdefault" *.c|wc --lines

3) number of calls or parameters to investigate,

% egrep "intDefault|booleanDefault|getdefault" *.c|wc --lines
% cat *.c|egrep "intDefault|booleanDefault|getdefault"|sort|uniq|wc --lines
% cat *.c|egrep "intDefault|booleanDefault|getdefault"|cut -f2 -d\"|sort|uniq|more|wc --lines

What might not be caught by an semi-automatic analysis is calls to
getdefault() that are conditional.  One could argue that such calls
are not for important parameters!

> The bottom line is I don't see an easy way of using code in the parent
> project to make setting and getting labels and values for the widgets
> easy for us.

True, but we should be able to improve the parent project as a side-
effect of making it easy for us.

James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/