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...
I wrote:
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.
On Sun, Dec 30, 2012 at 03:55:34AM +0000, corvid wrote:
I wrote:
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. -- Cheers Jorge.-
On Sun, Dec 30, 2012 at 10:52:37AM -0300, Jorge Arellano Cid wrote:
On Sun, Dec 30, 2012 at 03:55:34AM +0000, corvid wrote:
I wrote:
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.
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! ;-) -- Cheers Jorge.-
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)... 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.
Finally, @all, please recieve my best wishes for the new year that's about to start! ;-)
:)
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.-
Jorge wrote:
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.
Okay, I'll add a bunch of prefs for us to experiment with.
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...
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...
On Wed, Jan 02, 2013 at 09:23:49PM +0000, corvid wrote:
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. ;-) -- Cheers Jorge.-
On Wed, Jan 02, 2013 at 09:05:16PM +0000, corvid wrote:
Jorge wrote:
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.
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
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. -- Cheers Jorge.-
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...
On Thu, Jan 03, 2013 at 06:42:19AM +0000, corvid wrote:
I added some more to the color choosing stuff:
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,
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 -- Cheers Jorge.-
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.
On Wed, Jan 02, 2013 at 09:05:16PM +0000, corvid wrote:
Jorge wrote:
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.
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 -- Cheers Jorge.-
Jorge wrote:
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
It's nice. Should we regard bare hex as proper and legal? a_Color_parse() currently calls it an error but parses it anyway.
On Thu, Jan 03, 2013 at 08:13:03PM +0000, corvid wrote:
Jorge wrote:
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
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 -- Cheers Jorge.-
On Fri, Jan 04, 2013 at 11:54:20AM +0400, p37sitdu at lavabit.com wrote:
On Thu, Jan 03, 2013 at 11:01:10PM -0300, Jorge Arellano Cid wrote:
My fault, should have been: ... ui_tab_active_fg_color=#white ...
Should be ui_tab_active_fg_color=white
Right (an overworked me). -- Cheers Jorge.-
Jorge wrote:
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.
* 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.
* 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.
PS2: Is good to have the input/dialog backgrounds configurable but the defaults should be voted.
participants (3)
-
corvid＠lavabit.com -
jcid＠dillo.org -
p37sitdu＠lavabit.com