ARGHHHHHHHHH... f***ing netscape crashed before I could hit send....twice

reconstructing memory banks......


I have looked at the code you've written for gum and I think I understand 
what's going on...

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.

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).

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.

Anyway, my original plan was to completely separate the GUI into two
layers.  The GUI would do as little logic as possible---only perhaps
to retrieve or set values in the widgets and formatting these values
for the appropriate functions.  Advantages I think are that we can
separate the work among us by agreeing on this interface.  Downside is
we would probably have to redefine default keymaps and options since
these aren't available in a header file somewhere.


>From: James Cameron <quozl at>
>Reply-To: vanilla-list at
>To: vanilla-list at
>Subject: Re: [Vanilla List] any growth on this?
>Date: Mon, 26 Nov 2001 08:51:09 +1100
>I used a few design rules;
>- widget name had to match the option in the rc file, so that there
>   was no need for code specific to particular options,
>- widget name suffix was used for options with particular set of valid
>   values, so DASHBOARD_0, DASHBOARD_1, DASHBOARD_2 would be the names
>   of radio buttons for the "Dashboard:" option, made the code simple,
>- made use of as much code as possible in the parent project, like the
>   list of option names, descriptions, and data types,
>- each widget had a %s_LABEL widget next to it, so that the name shown
>   on screen for the setting could be managed by the parent project
>   rather than by gum,

Get your FREE download of MSN Explorer at