Re: ui colors again

On Sun, Dec 30, 2012 at 07:20:54PM +0000, corvid wrote:
> Jorge wrote:
> >   * We may suggest some combinations in the web site or dillorc.
> > 
> >   This way, the traditional look can easily be set, new ones can
> > be created (suggested) and a default scheme voted.
> 
> It would be nice if we had a sort of...minimal covering set of the different
> sorts of color schemes that a person could "sensibly" (whatever that can mean)
> want for the sake of testing. I imagine the world of graphic design must have
> such a thing (if only I knew the right words to find it)...

  Yes,  3  or  four packed themes would be OK (ideally selectable
from  the  UI), but tweakable from dillorc vars (this is a common
solution).

  A set of common "color schemes" is not easy to find though. For
instance,  I  use  LXDE/openbox, and it comes with near a hundred
packed themes!

  In openbox's theme set, sometimes a darker color is used to the
focused window, other themes use the reverse, and there're plenty
which use the same color and a a brighter font to hint focus.

  With  this  state of things, I tend to favor specific variables
in  dillorc  over  trying  to  guess  what  could  be  right. For
instance:

  tab_bg_color tab_fg_color

  instead of a fl_lighter()/fl_darker() combination.

  BTW, the current dillo repo guesses my theme backwards, but it
does great for other colors, and not good on others.

  For instance, adding these vars to the current set:

    tab_bg_color, tab_fg_color,
    tab_text_active_color, tab_text_inactive_color
    ui_button_highlight_color
    menu_active_item_color,

  would allow for huge themability options.

  I  know  it looks like an overkill, but yesterday, playing with
the  "toy"  color  chooser, with colors/themes I never use, found
that  some of our "good defaults" are poor choices for completely
different color schemes.

  The  good  part is that with a detailed color vars set, a theme
becomes a small set of integers. Quite easy to handle.


> Perhaps it would be good to be able to change colors at runtime, especially
> since we already allow the panel size to change. I'll have a look at that
> color chooser that fltk has.

  Ideally  yes.  Now, it needs some care. For instance, the "toy"
chooser changes ui background well, but doesn't update the colors
of  inactive buttons with the new backgrounds (which makes a huge
difference with bluish backgrounds. e.g. ui_main_bg_color=0070c0).

  Of  course  it  should also be able to manage saving the custom
defined theme.

  I'd  first  try with a certain colors var set, then define some
themes,  make  them  UI-selectable,  and finally decide whether a
color  chooser  for  all  of  them  is  worth  (YMMV, the reverse
approach may also fit ;).


-- 
  Cheers
  Jorge.-