- Dillo-dev - lists.mailman3.com

ui colors again

by corvid＠lavabit.com

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.

Jan. 3, 2013

ui colors again

by jcid＠dillo.org

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

Jan. 3, 2013

hanging in textblock

by corvid＠lavabit.com

http://graphicssoft.about.com/od/aboutgraphics/a/bitmapvector.htm #0 0x080929ad in dw::Textblock::findParagraphOfWord (this=0x82268b0, wordIndex=81) at textblock.cc:1228 #1 0x0809a3c7 in dw::Textblock::fillParagraphs (this=0x82268b0) at textblock_linebreaking.cc:1115 #2 0x0809169c in dw::Textblock::getExtremesImpl (this=0x82268b0, extremes=0xbfffe828) at textblock.cc:299 #3 0x080b48cc in dw::core::Widget::getExtremes (this=0x82268b0, extremes=0xbfffe828) at widget.cc:194 #4 0x08098276 in dw::Textblock::accumulateWordExtremes ( this=this at entry=0x822b460, firstWord=firstWord at entry=10, lastWord=lastWord at entry=11, maxOfMinWidth=maxOfMinWidth at entry=0xbfffe898, sumOfMaxWidth=sumOfMaxWidth at entry=0xbfffe89c) at textblock_linebreaking.cc:412 #5 0x08099eab in dw::Textblock::addLine (this=this at entry=0x822b460, firstWord=firstWord at entry=10, lastWord=lastWord at entry=11, temporary=temporary at entry=false) at textblock_linebreaking.cc:328 #6 0x0809aca0 in dw::Textblock::wordWrap (this=0x822b460, wordIndex=11, wrapAll=false) at textblock_linebreaking.cc:596 #7 0x0809a278 in dw::Textblock::rewrap (this=0x822b460) at textblock_linebreaking.cc:1071 #8 0x080914fc in dw::Textblock::sizeRequestImpl (this=0x822b460, requisition=0x8244898) at textblock.cc:217 #9 0x080b483f in dw::core::Widget::sizeRequest (this=0x822b460, requisition=0x8244898) at widget.cc:177 #10 0x08091b92 in dw::Textblock::calcWidgetSize (this=0x82dae38, widget=0x822b460, size=0x8244898) at textblock.cc:768 #11 0x0809a2ba in dw::Textblock::rewrap (this=0x82dae38) at textblock_linebreaking.cc:1069 #12 0x080914fc in dw::Textblock::sizeRequestImpl (this=0x82dae38, requisition=0x8258078) at textblock.cc:217 #13 0x080b483f in dw::core::Widget::sizeRequest (this=0x82dae38, requisition=0x8258078) at widget.cc:177 #14 0x08091b92 in dw::Textblock::calcWidgetSize (this=0x82e1300, widget=0x82dae38, size=0x8258078) at textblock.cc:768 #15 0x0809a2ba in dw::Textblock::rewrap (this=0x82e1300) at textblock_linebreaking.cc:1069 #16 0x080914fc in dw::Textblock::sizeRequestImpl (this=0x82e1300, requisition=0x824bd80) at textblock.cc:217 #17 0x080b483f in dw::core::Widget::sizeRequest (this=0x82e1300, requisition=0x824bd80) at widget.cc:177 #18 0x08091b92 in dw::Textblock::calcWidgetSize (this=0x822d870, widget=0x82e1300, size=0x824bd80) at textblock.cc:768 #19 0x0809a2ba in dw::Textblock::rewrap (this=0x822d870) at textblock_linebreaking.cc:1069 #20 0x080914fc in dw::Textblock::sizeRequestImpl (this=0x822d870, requisition=0x81e64b8) at textblock.cc:217 #21 0x080b483f in dw::core::Widget::sizeRequest (this=0x822d870, requisition=0x81e64b8) at widget.cc:177 #22 0x08091b92 in dw::Textblock::calcWidgetSize (this=0x8278530, widget=0x822d870, size=0x81e64b8) at textblock.cc:768 #23 0x0809a2ba in dw::Textblock::rewrap (this=0x8278530) at textblock_linebreaking.cc:1069 #24 0x080914fc in dw::Textblock::sizeRequestImpl (this=0x8278530, requisition=0xbfffee40) at textblock.cc:217 #25 0x080b483f in dw::core::Widget::sizeRequest (this=0x8278530, requisition=0xbfffee40) at widget.cc:177 #26 0x080ade2c in dw::core::Layout::resizeIdle (this=0x820f448) at layout.cc:667 #27 0x0809faa8 in dw::fltk::FltkPlatform::generalIdle (this=0x820f410) at fltkplatform.cc:630 #28 0x080ef3b1 in call_idle () at Fl_add_idle.cxx:40 #29 0x080b88e4 in Fl::wait (time_to_wait=1e+20) at Fl.cxx:496 #30 0x080b89c0 in Fl::run () at Fl.cxx:529 #31 0x0804f7f9 in main (argc=1, argv=0xbffff044) at dillo.cc:498

Jan. 3, 2013

ui colors again

by corvid＠lavabit.com

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

Jan. 3, 2013

ui colors again

by jcid＠dillo.org

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

Jan. 2, 2013

ui colors again

by corvid＠lavabit.com

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

Jan. 2, 2013

ui colors again

by corvid＠lavabit.com

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

Jan. 2, 2013

wizard, switching between UIs

by jcid＠dillo.org

On Wed, Jan 02, 2013 at 05:55:42PM +0000, corvid wrote: > Jorge wrote: > > On Sat, Dec 29, 2012 at 09:21:31PM +0000, corvid wrote: > > > > > > Yesterday I was playing with ctrl-tab, of course, and I noticed how the > > > state of the focused tab would sometimes change. > > > > What's "the state of the focused tab"? > > Suppose you have two tabs open and you ctrl-tab between them. > - If, in the rightmost one, Location had focus, when it gets focus again, > suddenly the whole location text is highlighted (Fl_Input.cxx:616). > - If the rightmost one has Main focused, when you switch back to it, > Location has focus (Fl_Group.cxx:130, 159). Ah, now I see! Please add a comment like this to either the source or the hg patch upon commit. -- Cheers Jorge.-

Jan. 2, 2013

wizard, switching between UIs

by corvid＠lavabit.com

Jorge wrote: > On Sat, Dec 29, 2012 at 09:21:31PM +0000, corvid wrote: > > > > Yesterday I was playing with ctrl-tab, of course, and I noticed how the > > state of the focused tab would sometimes change. > > What's "the state of the focused tab"? Suppose you have two tabs open and you ctrl-tab between them. - If, in the rightmost one, Location had focus, when it gets focus again, suddenly the whole location text is highlighted (Fl_Input.cxx:616). - If the rightmost one has Main focused, when you switch back to it, Location has focus (Fl_Group.cxx:130, 159).

Jan. 2, 2013

ui colors again

by jcid＠dillo.org

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

Jan. 2, 2013