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
Friday, 31 May 2013
Re: Remember this password
In article <db3c905453.pnyoung@pnyoung.ormail.co.uk>,
Peter Young <pnyoung@ormail.co.uk> wrote:
> On 31 May 2013 cj <chris@chris-johnson.org.uk> wrote:
> > In article <e175865453.wra1th@wra1th.plus.com>,
> > Gavin Wraith <gavin@wra1th.plus.com> wrote:
> >> If not, then maybe some approximation could
> >> be kludged using function keys.
> > There is always FFiller by Kevin Wells. I have found it quite useful
> > in the past. Always use it for eg ROOL forum.
A very useful programme.
See also my article "Macros for Form Filling" - Archive Magazine Vol 22 No 7
Jan 2010 p50
> Or if you are paranoid about having visible passwords on your system,
> CrypStor by Frank de Bruijn will store passwords encrypted. You can
> export these passwords as a text file, then drag and drop the relevant
> one into NetSurf, then delete the export file.
Better than that, you can enter them automatically by clicking on the
relevant button bar
> It's at http://aconet.org/crypstor/
> I didn't find it totally intuitive to start with, but I now find it
> extremely useful.
Wouldn't be without it here.
Regards,
--
Chris
Peter Young <pnyoung@ormail.co.uk> wrote:
> On 31 May 2013 cj <chris@chris-johnson.org.uk> wrote:
> > In article <e175865453.wra1th@wra1th.plus.com>,
> > Gavin Wraith <gavin@wra1th.plus.com> wrote:
> >> If not, then maybe some approximation could
> >> be kludged using function keys.
> > There is always FFiller by Kevin Wells. I have found it quite useful
> > in the past. Always use it for eg ROOL forum.
A very useful programme.
See also my article "Macros for Form Filling" - Archive Magazine Vol 22 No 7
Jan 2010 p50
> Or if you are paranoid about having visible passwords on your system,
> CrypStor by Frank de Bruijn will store passwords encrypted. You can
> export these passwords as a text file, then drag and drop the relevant
> one into NetSurf, then delete the export file.
Better than that, you can enter them automatically by clicking on the
relevant button bar
> It's at http://aconet.org/crypstor/
> I didn't find it totally intuitive to start with, but I now find it
> extremely useful.
Wouldn't be without it here.
Regards,
--
Chris
Re: Options/Choices refactor
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/
> 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/
Re: Remember this password
In article <db3c905453.pnyoung@pnyoung.ormail.co.uk>,
Peter Young <pnyoung@ormail.co.uk> wrote:
> Or if you are paranoid about having visible passwords on your
> system, CrypStor by Frank de Bruijn will store passwords encrypted.
...but if you are paranoid, why would you want the browser to
remember passwords anyway?
--
Chris Johnson
Peter Young <pnyoung@ormail.co.uk> wrote:
> Or if you are paranoid about having visible passwords on your
> system, CrypStor by Frank de Bruijn will store passwords encrypted.
...but if you are paranoid, why would you want the browser to
remember passwords anyway?
--
Chris Johnson
Re: Options/Choices refactor
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.
Chris
> 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.
Chris
Re: Remember this password
On 31 May 2013 cj <chris@chris-johnson.org.uk> wrote:
> In article <e175865453.wra1th@wra1th.plus.com>,
> Gavin Wraith <gavin@wra1th.plus.com> wrote:
>> If not, then maybe some approximation could
>> be kludged using function keys.
> There is always FFiller by Kevin Wells. I have found it quite useful
> in the past. Always use it for eg ROOL forum.
Or if you are paranoid about having visible passwords on your system,
CrypStor by Frank de Bruijn will store passwords encrypted. You can
export these passwords as a text file, then drag and drop the relevant
one into NetSurf, then delete the export file.
It's at http://aconet.org/crypstor/
I didn't find it totally intuitive to start with, but I now find it
extremely useful.
Probably OT here, though.
With best wishes,
Peter.
--
Peter Young (zfc Ta) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
> In article <e175865453.wra1th@wra1th.plus.com>,
> Gavin Wraith <gavin@wra1th.plus.com> wrote:
>> If not, then maybe some approximation could
>> be kludged using function keys.
> There is always FFiller by Kevin Wells. I have found it quite useful
> in the past. Always use it for eg ROOL forum.
Or if you are paranoid about having visible passwords on your system,
CrypStor by Frank de Bruijn will store passwords encrypted. You can
export these passwords as a text file, then drag and drop the relevant
one into NetSurf, then delete the export file.
It's at http://aconet.org/crypstor/
I didn't find it totally intuitive to start with, but I now find it
extremely useful.
Probably OT here, though.
With best wishes,
Peter.
--
Peter Young (zfc Ta) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
Re: Remember this password
In article <e175865453.wra1th@wra1th.plus.com>,
Gavin Wraith <gavin@wra1th.plus.com> wrote:
> If not, then maybe some approximation could
> be kludged using function keys.
There is always FFiller by Kevin Wells. I have found it quite useful
in the past. Always use it for eg ROOL forum.
--
Chris Johnson
Gavin Wraith <gavin@wra1th.plus.com> wrote:
> If not, then maybe some approximation could
> be kludged using function keys.
There is always FFiller by Kevin Wells. I have found it quite useful
in the past. Always use it for eg ROOL forum.
--
Chris Johnson
Subscribe to:
Posts (Atom)