Re: Handling preferences
Jorge Arellano Cid <[email protected]>
| Newsgroups | gmane.comp.web.dillo.devel |
|---|---|
| Message-ID | <[email protected]> |
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.
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.
--
Cheers
Jorge.-