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 > preferences.
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 user options? 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 first? 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. -- Regards Vincent http://www.kyllikki.org/
