ui colors again

[corvid]

Today I dug up the old ui colors patch from last September, ripped out the
part that used system colors as defaults that was a problem*, and played
around with it a little. I really like configurable colors, so, since I
haven't heard anyone say anything like feature freeze yet, I'll make another
push for this thing.


One difference from the previous code is that I'm using inactive() on the
images for inactive toolbar buttons because our gray pixmaps tend not to
look so good with different UI colors. It might be good to pull it somewhat
closer to the background color, but I'm not sure yet.


* Under X, FLTK tries to "Read colors that KDE writes to the xrdb database",
which may or may not work fine for those people running KDE, but...

[corvid]

Post by corvid
Today I dug up the old ui colors patch from last September, ripped out the
part that used system colors as defaults that was a problem*, and played
around with it a little. I really like configurable colors, so, since I
haven't heard anyone say anything like feature freeze yet, I'll make another
push for this thing.

Committed.

- I changed the inactive icon appearance some more.
- By default it's using the fltk default colors.
- It might be nice to be able to specify the selection color, too.

[Jorge Arellano Cid]

Post by corvid

Post by corvid
Today I dug up the old ui colors patch from last September, ripped out the
part that used system colors as defaults that was a problem*, and played
around with it a little. I really like configurable colors, so, since I
haven't heard anyone say anything like feature freeze yet, I'll make another
push for this thing.

Committed.
- I changed the inactive icon appearance some more.
- By default it's using the fltk default colors.
- It might be nice to be able to specify the selection color, too.

-1

The default colors or theme are not easy to define, everybody has
his personal preferences, and there's no single scheme that pleases
everyone.

The default theme in dillo is kind of a consensus over the
years. This is, when changes were proposed, the most voted one
(or less objected) got to be the default (same for the website).

This policy works ok for us and is widely used.

Personally I don't like the change, but I do understand that
other users, may find it fits better.

So my points are:

* The default colors should not be changed without consensus.
* The patch should provide a way to keep the previous default
(i.e. How do I get my colors/pixmaps back?)

PS: WRT the second point, I find the inactive pixmaps too
"live" for my taste (and thus prefer the pixmaps).
PS2: Is good to have the input/dialog backgrounds configurable
but the defaults should be voted.

[Jorge Arellano Cid]

Post by Jorge Arellano Cid

Post by corvid

Post by corvid
Today I dug up the old ui colors patch from last September, ripped out the
part that used system colors as defaults that was a problem*, and played
around with it a little. I really like configurable colors, so, since I
haven't heard anyone say anything like feature freeze yet, I'll make another
push for this thing.

Committed.
- I changed the inactive icon appearance some more.
- By default it's using the fltk default colors.
- It might be nice to be able to specify the selection color, too.

-1
The default colors or theme are not easy to define, everybody has
his personal preferences, and there's no single scheme that pleases
everyone.
The default theme in dillo is kind of a consensus over the
years. This is, when changes were proposed, the most voted one
(or less objected) got to be the default (same for the website).
This policy works ok for us and is widely used.
Personally I don't like the change, but I do understand that
other users, may find it fits better.
* The default colors should not be changed without consensus.
* The patch should provide a way to keep the previous default
(i.e. How do I get my colors/pixmaps back?)
PS: WRT the second point, I find the inactive pixmaps too
"live" for my taste (and thus prefer the pixmaps).
PS2: Is good to have the input/dialog backgrounds configurable
but the defaults should be voted.

Just trying to make my points a bit clearer, and after playing
a bit more with the patch:

* +1 to making it configurable (as now)
* +1 to add a dillorc option for the second parameter in
color_average() call (e.g. setting it to 0.1f makes for the
same look as with the handmade pixmaps, so they could be
removed). Adding a parameter for the first one may also
help (although it's not a priority).
* 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.


Finally, @all, please recieve my best wishes for the new year
that's about to start! ;-)

[corvid]

Post by Jorge Arellano Cid
* 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)...

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.

Post by Jorge Arellano Cid
that's about to start! ;-)

:)

[corvid]

Post by corvid
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.

Here's a quick little toy:

[Jorge Arellano Cid]

Post by corvid

Post by Jorge Arellano Cid
* 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.

Post by corvid
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 ;).

[corvid]

Post by Jorge Arellano Cid
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.

Okay, I'll add a bunch of prefs for us to experiment with.

Post by Jorge Arellano Cid
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).

Yeah, I'll put a little more time into the toy later. Background also
needs to update the gray ramp so that box colors work better, for
instance...

[corvid]

BTW, although our John Grantham icons hold up well when the background is
dark, the others don't do as well. It's a pity that I don't have the artistic
background to mimic his...

[Jorge Arellano Cid]

Post by corvid
BTW, although our John Grantham icons hold up well when the background is
dark, the others don't do as well. It's a pity that I don't have the artistic
background to mimic his...

I can try to enhance mine a bit, but as the problem shows,
I'm by no means in the same league as John Grantham. ;-)

[Jorge Arellano Cid]

Post by corvid

Post by Jorge Arellano Cid
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.

Okay, I'll add a bunch of prefs for us to experiment with.

Good.

Attached goes some test code I used to test tab colors. HTH.

FWIW, I get close to the traditional colors with:

ui_fg_color=140040
ui_main_bg_color=c6c6c6
ui_text_bg_color=bfdabf
ui_tab_active_color=87aca7
ui_tab_inactive_color=silver

Post by corvid

Post by Jorge Arellano Cid
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).

Yeah, I'll put a little more time into the toy later. Background also
needs to update the gray ramp so that box colors work better, for
instance...

OK.

[corvid]

I added some more to the color choosing stuff:

http://www.dillo.org/test/choose_colors2.diff

It's not terribly nice, careful code at this point.
It knows about the more recent prefs, and I spent some time making
the menu fancy for some reason.

If we can't get the inactive icons at least nearly for free, I'm
tempted to go back to the old ones instead of adding special code.
(I didn't initially expect us to have much if any of a runtime
mechanism to change colors.)

I suspect the Tabs doesn't want to send the redraw() down to the
tab buttons because of damage bits or something, but I ran out of
steam on this for the night...

[Jorge Arellano Cid]

Post by corvid
http://www.dillo.org/test/choose_colors2.diff

Good. Just this minor fix to compile.

diff -r cc706f9310db src/menu.cc
--- a/src/menu.cc Fri Jan 04 12:13:39 2013 -0300
+++ b/src/menu.cc Fri Jan 04 16:53:20 2013 -0300
@@ -675,7 +675,7 @@ static Fl_Color get_label_color(int32_t

static void Menu_base_color_change_cb(Fl_Widget*, void *user_data)
{
- Fl_Color colornum = (Fl_Color)user_data;
+ Fl_Color colornum = VOIDP2INT(user_data);
int old_rgb = Fl::get_color(colornum);
uchar r = old_rgb >> 24,
g = (old_rgb >> 16) & 0xff,

Post by corvid
It's not terribly nice, careful code at this point.
It knows about the more recent prefs, and I spent some time making
the menu fancy for some reason.

It helps a lot with making themes.
BTW, a greenish one:

ui_fg_color=#100404
ui_main_bg_color=#c8d394
ui_text_bg_color=#bdd8b6
ui_selection_color=#7c5f42
ui_button_highlight_color=#bdbd80
ui_tab_active_bg_color=#b5b679
ui_tab_active_fg_color=#b60907
ui_tab_bg_color=#cac682

[corvid]

http://www.dillo.org/test/color_themes.diff

I was just playing around with making themes selectable. I typed in some
color themes that Jorge has suggested, and typos in them are possible.

I tried using some of the fltk color indices for our tab colors and
button highlight color in order to make the code more uniform, placing
the #defines in prefs for lack of an obviously good location.

It has code to fix the deactivated icons when the background color
changes, but I'm still not very pleased with it.

[Jorge Arellano Cid]

Post by corvid

Post by Jorge Arellano Cid
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.

Okay, I'll add a bunch of prefs for us to experiment with.

FWIW, an earthly theme sample with the new prefs:

ui_fg_color= 100404
ui_main_bg_color=c2a47b
ui_text_bg_color=cdc9a5
ui_selection_color=763024
ui_tab_active_bg_color=af4b3f
ui_tab_active_fg_color=white
ui_tab_bg_color=d2b48c

[corvid]

Post by Jorge Arellano Cid
ui_fg_color= 100404
ui_main_bg_color=c2a47b
ui_text_bg_color=cdc9a5
ui_selection_color=763024
ui_tab_active_bg_color=af4b3f
ui_tab_active_fg_color=white
ui_tab_bg_color=d2b48c

It's nice.

Should we regard bare hex as proper and legal? a_Color_parse() currently
calls it an error but parses it anyway.

[Jorge Arellano Cid]

Post by corvid

Post by Jorge Arellano Cid
ui_fg_color= 100404
ui_main_bg_color=c2a47b
ui_text_bg_color=cdc9a5
ui_selection_color=763024
ui_tab_active_bg_color=af4b3f
ui_tab_active_fg_color=white
ui_tab_bg_color=d2b48c

It's nice.
Should we regard bare hex as proper and legal? a_Color_parse() currently
calls it an error but parses it anyway.

My fault, should have been:

ui_fg_color=#100404
ui_main_bg_color=#c2a47b
ui_text_bg_color=#cdc9a5
ui_selection_color=#763024
ui_tab_active_bg_color=#af4b3f
ui_tab_active_fg_color=#white
ui_tab_bg_color=#d2b48c

[p***@public.gmane.org]

Post by Jorge Arellano Cid
...
ui_tab_active_fg_color=#white
...

Should be
ui_tab_active_fg_color=white

[Jorge Arellano Cid]

Post by p***@public.gmane.org

Post by Jorge Arellano Cid
...
ui_tab_active_fg_color=#white
...

Should be
ui_tab_active_fg_color=white

Right (an overworked me).

[corvid]

Post by Jorge Arellano Cid
Of course it should also be able to manage saving the custom
defined theme.

Do you mean saving things to dillorc?

[corvid]

Post by Jorge Arellano Cid
The default theme in dillo is kind of a consensus over the
years. This is, when changes were proposed, the most voted one
(or less objected) got to be the default (same for the website).

I think we have a strong tendency to defer to you in general and end up
with what Jorge likes, even if that's not your intention particularly.

And of course the community is so tiny these days that we often get one vote
or zero votes on something, dispiritingly enough.

Last year, the opinions presented on the list on ripping out the hardcoded
colors were: Benjamin brought it up, iirc, having done so with his fork. I
liked the idea. Johannes liked the idea.

Post by Jorge Arellano Cid
* The default colors should not be changed without consensus.

It should be quite similar except that there's some white where we
customarily have a greenish color. I'm not too crazy about the white, but
I didn't want to make it the same greenish merely because it's what we had
because then we'd all not notice it and/or accept it as the way it's always
been. (The white of course being fltk's default.)

I'm thinking that we come up with defaults for foreground and the two
backgrounds and maybe selection color, and then put in contrast() and
lighter() and darker() as necessary for visibility and pleasant appearance,
but base everything on that set of colors instead of hardcoding anything
to green or blue or whatever.

Post by Jorge Arellano Cid
* The patch should provide a way to keep the previous default
(i.e. How do I get my colors/pixmaps back?)
PS: WRT the second point, I find the inactive pixmaps too
"live" for my taste (and thus prefer the pixmaps).

I initially wanted to make the inactive pixmaps look better with greyish or
darkish backgrounds, and I used Fl_Image's inactive(), which just dims the
pixmap down with some background color. But they didn't look inactive enough,
so I went the desaturate() route after all, which is rather like using the
pixmaps... So I haven't come up with anything that I'm happy enough with to
really want to _advocate_ for.

Post by Jorge Arellano Cid
PS2: Is good to have the input/dialog backgrounds configurable
but the defaults should be voted.