Handling preferences

[Sebastian Geerken]

Hi!

I'm just working on making some values related to hyphenation
configurable via dillorc. A long time ago (before the Fltk port), Dw
directy accessed the prefs module for the value limit_text_width. When
Dw was ported to Fltk (which was largely a rewrite), it was seperated,
so it does not depend on prefs anymore. However, this made it
necessary to pass the value of prefs.limit_text_width to dw::Textblock
in the constructor.

Now, I do not want to extend dw::Textblock::Textblock() by a couple of
new parameters. Instead, I though of storing the values directly in Dw
(initialized by feasable standard values), and the prefs parser must
store them there. This way, Dw is still independent. This could be
adapted in other modules.

Currenty, my code is this:

1. The new values are still stored in DilloPrefs.

2. There is a static method dw::Textblock::init, which called in main,
after the prefs parser:

@@ -50,6 +50,7 @@
#include "auth.h"

#include "dw/fltkcore.hh"
+#include "dw/textblock.hh"

/*
* Command line options structure
@@ -359,6 +360,8 @@
a_Cookies_init();
a_Auth_init();

+ dw::Textblock::init (prefs.penalty_hyphen, prefs.penalty_hyphen_2);
+
/* command line options override preferences */
if (options_got & DILLO_CLI_FULLWINDOW)
prefs.fullwindow_start = TRUE;

Any thoughts/comments?

Sebastian

[Jorge Arellano Cid]

Hi Sebastian,

Post by Sebastian Geerken
Hi!
I'm just working on making some values related to hyphenation
configurable via dillorc. A long time ago (before the Fltk port), Dw
directy accessed the prefs module for the value limit_text_width. When
Dw was ported to Fltk (which was largely a rewrite), it was seperated,
so it does not depend on prefs anymore. However, this made it
necessary to pass the value of prefs.limit_text_width to dw::Textblock
in the constructor.
Now, I do not want to extend dw::Textblock::Textblock() by a couple of
new parameters. Instead, I though of storing the values directly in Dw
(initialized by feasable standard values), and the prefs parser must
store them there. This way, Dw is still independent. This could be
adapted in other modules.
1. The new values are still stored in DilloPrefs.
2. There is a static method dw::Textblock::init, which called in main,
@@ -50,6 +50,7 @@
#include "auth.h"
#include "dw/fltkcore.hh"
+#include "dw/textblock.hh"
/*
* Command line options structure
@@ -359,6 +360,8 @@
a_Cookies_init();
a_Auth_init();
+ dw::Textblock::init (prefs.penalty_hyphen, prefs.penalty_hyphen_2);
+
/* command line options override preferences */
if (options_got & DILLO_CLI_FULLWINDOW)
prefs.fullwindow_start = TRUE;
Any thoughts/comments?

Incidentally, today I was looking into the scrolling step (both
for keyboard and mousewheel/scrollpad), and there's this method:

void FltkViewport::setScrollStep(int step);

also CustomButton has:

void CustomButton::hl_color(Fl_Color col);

etc.

AFAICS an init(p1, p2, ...) function is very good for setting
the whole prefs pack at once, but it doesn't seem as convenient
for changing just one of those vars at run time; which may be
necessary for instance if we ever implement a preferences dpi or
enable a custom UI (as with change panel size).

I'm a bit more inclined towards the separate functions for each
var approach.

BTW, your example also implicitly touches this point: dillorc
may set a certain value, and a CLI parameter override it. In this
case the separate functions approach seems cleaner.

[corvid]

This reminds me that we still have

#define prefs_show_msg 1

in lout/msg.h

[Sebastian Geerken]

Post by Jorge Arellano Cid
Hi Sebastian,

Post by Sebastian Geerken
Hi!
I'm just working on making some values related to hyphenation
configurable via dillorc. A long time ago (before the Fltk port), Dw
directy accessed the prefs module for the value limit_text_width. When
Dw was ported to Fltk (which was largely a rewrite), it was seperated,
so it does not depend on prefs anymore. However, this made it
necessary to pass the value of prefs.limit_text_width to dw::Textblock
in the constructor.
Now, I do not want to extend dw::Textblock::Textblock() by a couple of
new parameters. Instead, I though of storing the values directly in Dw
(initialized by feasable standard values), and the prefs parser must
store them there. This way, Dw is still independent. This could be
adapted in other modules.
1. The new values are still stored in DilloPrefs.
2. There is a static method dw::Textblock::init, which called in main,
@@ -50,6 +50,7 @@
#include "auth.h"
#include "dw/fltkcore.hh"
+#include "dw/textblock.hh"
/*
* Command line options structure
@@ -359,6 +360,8 @@
a_Cookies_init();
a_Auth_init();
+ dw::Textblock::init (prefs.penalty_hyphen, prefs.penalty_hyphen_2);
+
/* command line options override preferences */
if (options_got & DILLO_CLI_FULLWINDOW)
prefs.fullwindow_start = TRUE;
Any thoughts/comments?

Incidentally, today I was looking into the scrolling step (both
void FltkViewport::setScrollStep(int step);
void CustomButton::hl_color(Fl_Color col);
etc.
AFAICS an init(p1, p2, ...) function is very good for setting
the whole prefs pack at once, but it doesn't seem as convenient
for changing just one of those vars at run time; which may be
necessary for instance if we ever implement a preferences dpi or
enable a custom UI (as with change panel size).
I'm a bit more inclined towards the separate functions for each
var approach.

Yes, probably this is a good idea. However, should these methods be
static or not? That is, should it be possible that different instances
of dw::Textblock have different values set?

One problem is that dw::Textblock is instanciated at a couple of
postions, and how configuration looks like eventually is not clear
yet; so I'd like to follow a more pragmatical approach to set the at
one position in the code.

Post by Jorge Arellano Cid
BTW, your example also implicitly touches this point: dillorc
may set a certain value, and a CLI parameter override it. In this
case the separate functions approach seems cleaner.

Does this affect the following arguments? When called

dillo --opt1 url1 --opt2 url2

should --opt2 only affect url2 or also url1? In the former case,
non-static configuration is indeed necessary.

Sebastian

[corvid]

Post by Sebastian Geerken
Does this affect the following arguments? When called
dillo --opt1 url1 --opt2 url2
should --opt2 only affect url2 or also url1? In the former case,
non-static configuration is indeed necessary.

Command line parsing requires all of the arguments before all of the urls.

[Jorge Arellano Cid]

Post by Sebastian Geerken

Post by Jorge Arellano Cid
[...]
AFAICS an init(p1, p2, ...) function is very good for setting
the whole prefs pack at once, but it doesn't seem as convenient
for changing just one of those vars at run time; which may be
necessary for instance if we ever implement a preferences dpi or
enable a custom UI (as with change panel size).
I'm a bit more inclined towards the separate functions for each
var approach.

Yes, probably this is a good idea. However, should these methods be
static or not? That is, should it be possible that different instances
of dw::Textblock have different values set?
One problem is that dw::Textblock is instanciated at a couple of
postions, and how configuration looks like eventually is not clear
yet; so I'd like to follow a more pragmatical approach to set the at
one position in the code.

I'd go for the simple solution now (a global setting).
i.e. a CLI parameter sets the whole browser.

If the need arises in the future we may re-evaluate enabling
the change of a particular textblock var on the fly.