Re: Handling preferences

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