On Thu, Nov 15, Jorge Arellano Cid wrote:

Hi Sebastian,

On Thu, Nov 15, 2012 at 01:42:29PM +0100, Sebastian Geerken wrote:

...

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?

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.

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.

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