On Fri, 31 May 2013 21:29:16 +0100, Vincent Sanders wrote: > > 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?
Sort of I guess, but I want them all set, but then I want to change the defaults so any that aren't set get the new defaults instead of the old ones (not sure that is any cleaerer actually) > 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 primary example are the system colours settings. At the moment they aren't being set because the screen my code looks at to pick the colours off of, hasn't been opened by the time the options are initialised. What I need is something like: 1. Options initialised and read This gives my screen_modeid and a couple of other options required for opening NetSurf on the correct screen. 2. Open screen 3. Set default options relating to the screen being used This includes system colours, window size etc. They should not be overriding any user specified options. 4. Optionally support re-doing step 3 if the screen being used changes during program execution (actually the frontend doesn't support this yet but may do one day) btw a "screen" in AmigaOS terms is more like a "desktop" in X11, but can be a different resolution and theme to what is being used for the desktop (hence the requirement to set the default system colours and window size after the screen has been determined) > 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) I did try running the colour_option_from_pen functions through with nsoptions_default parameter, but about:config shows the system colours options are then "user" settings (for some reason). That's no good as they get written back to Choices, which puts us back to square 1. > 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. I don't think I need to deal with any strings at the moment. I'll have a look at it. Thanks Chris
