On Fri, May 31, 2013 at 07:27:42PM +0100, Chris Young wrote:
On Tue, 28 May 2013 19:52:13 +0100, Vincent Sanders wrote:
> This means that user options files will now only contain the options
> which differ from the defaults. This will alow us to alter the
> defaults in future and have everyones choices actually update instead
> of being overidden by old saved default values that might not be useful.
Is there any way to modify the defaults outside of nsoption_init?
I have to open a screen before I can set some of the values, but I
can't open the screen until options are initialised (as the parameters
are in there). So I'd like to set some defaults at a later time which
then get applied, unless of course the user has already set their own
this does sound ass backwards? like you want only some user options
set and then to initialise some defaults then to apply the rest of the
Perhaps a clearer idea of what you are trying to achive might be
useful? you may have to do a second initialisation after the first
user option load and have ther second init use the info from the
The new API is designed to be flexible. The original aim was to
completely abstract access to the options. Due to practical
constraints outlined in utils/nsoption.h this has not been possible.
For now there are no accessor functions for the default values (yeah i
know the current implementation for active options is with macros) but
you can simply use nsoptions_default[NSOPTION_option_name].value.i
directly from within your own code (or perhaps better still crate some
accessor functions(macros) in nsoption.h)
The gtk frontend has a verify_options() function in its main() that
does something similar, just remember that strings must be handled
carefully as defaults may be const and not require freeing (active
options are always allocated from heap) and only options that differ
between the default and active table will be saved.