Re: dillo-3.0-rc2 is out

Jorge wrote:
> On Tue, Sep 13, 2011 at 03:31:14AM +0000, corvid wrote:
> > I wrote:
> > > Jorge wrote:
> > > > On Fri, Sep 09, 2011 at 10:03:29AM +0200, Johannes Hofmann wrote:
> > > > > BTW, what about not specifying the box type at all and having a 
> > > > > Fl::scheme("plastic") call in main()?
> > > > > Or even better having an option in dillorc to specify the scheme.
> > > > 
> > > >   Long ago, after searching for a window manager theme that suits
> > > > my  needs,  in  specialized  sites,  it  became  quite clear it's
> > > > impossible to get something that pleases everybody.
> > > > 
> > > >   WRT   dillo,  there're  several  buttton  variants  for  either
> > > > "plastic"  and  "gtk+",  so  I'm  more inclined to have a dillorc
> > > > option for the tab button style.
> > > > 
> > > >   A gtk+/plastic selector may also help (I have vague memories of
> > > > some  form widgets being less clear to read, but this is personal
> > > > taste anyway :).
> > > 
> > > The code in Fl_get_system_colors.cxx goes:
> > > 
> > > int Fl::scheme(const char *s) {
> > >   if (!s) {
> > >     if ((s = getenv("FLTK_SCHEME")) == NULL) {
> > > #if !defined(WIN32) && !defined(__APPLE__)
> > >       const char* key = 0;
> > >       if (Fl::first_window()) key = Fl::first_window()->xclass();
> > >       if (!key) key = "fltk";
> > >       fl_open_display();
> > >       s = XGetDefault(fl_display, key, "scheme");
> > > #endif // !WIN32 && !__APPLE__
> > >     }
> > >   }
> > > [...]
> > > }
> > > 
> > > so if we stick a Fl::scheme(NULL) into dillo.cc, then
> > > $ export FLTK_SCHEME=plastic
> > > $ dillo
> > > works (Why doesn't "FLTK_SCHEME=plastic dillo" work?)
> > > 
> > > and
> > > 
> > > "dillo*scheme: gtk+"
> > > in .Xdefaults works.
> > 
> > I was having a look around the web to see what reaction there was
> > to the 3.0 release, and the Puppy Linux folks were having a thread
> > that went something like "Pity it's so ugly" "Here, try these other
> > FLTK schemes" "Hey, that's great!" -- which is evidence that adding
> > a preference would be welcomed by users.
> 
>   The  canonical  solution  to this problem seems to be to pack a
> few  "themes"  selectable  from  preferences, and also allow some
> fine tunning via rc preferences or so.
> 
>   I also read a good sign on this because people usually start to
> customize the look of an app only after they find it useful.
> 
>   Would you mind handling this task?

Added a theme preference.
For now, you can specify an arbitrary string and get whatever weird
mixture fltk gives you in that case. I asked on fltk.general whether
it should do that rather than treat an unknown scheme as the default
scheme. Obviously it would be trivial to deal with for ourselves.

If anyone gets ambitious enough or bored enough one day to want to
make additional themes, you can look in fltk's Fl_get_system_colors.cxx
at Fl::reload_scheme(). It mostly amounts to defining frame and box
types.