Re: dillo-3.0-rc2 is out

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:
> > > > On Fri, Sep 09, 2011 at 12:00:31AM +0000, corvid wrote:
> > > > > higuita wrote:
> > > > > > I even like more the FL_PLASTIC_UP_BOX look :)
> > > > > 
> > > > > I think I do too...
> > > > 
> > > > 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?

-- 
  Cheers
  Jorge.-