Re: Options/Choices refactor

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