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.-