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.