an experiment in widget coloring (with code)
With my color settings, my buttons were light grey with unreadable white labels. Well, that's no good. And standard gui widget colors scream "I'm using a Windows Office Productivity Suite!" to me. So here is something to play with. I currently have the widgets using background color and the labels/text either black or white. fltk_black to make black work right widget_colors.dillo to set backgroundColor in Style. widget_colors.dw where you set the widget colors.
On Fri, Jan 25, 2008 at 10:06:58PM +0000, place wrote:
With my color settings, my buttons were light grey with unreadable white labels. Well, that's no good.
And standard gui widget colors scream "I'm using a Windows Office Productivity Suite!" to me.
:-)
So here is something to play with. I currently have the widgets using background color and the labels/text either black or white.
I like the idea, even the look of coloured widgets, but some people may prefer the old look. Would you implement this as a dillorc2 preference? e.g. # When set to yes, form elements follow the color style of the page. widget_colors=YES
fltk_black to make black work right
Will be committed after writing this email.
widget_colors.dillo to set backgroundColor in Style. widget_colors.dw where you set the widget colors.
Will expect your answer. -- Cheers Jorge.-
Jorge wrote:
I like the idea, even the look of coloured widgets, but some people may prefer the old look.
Would you implement this as a dillorc2 preference? e.g.
# When set to yes, form elements follow the color style of the page. widget_colors=YES
I ended up calling the pref standard_widget_colors, which allows the toolkit to use its default colors. old behavior: current text color on light grey. standard_widget_colors=YES: black on light grey. standard_widget_colors=NO: current text color on current background color.
On Sat, Feb 02, 2008 at 02:52:18AM +0000, place wrote:
Jorge wrote:
I like the idea, even the look of coloured widgets, but some people may prefer the old look.
Would you implement this as a dillorc2 preference? e.g.
# When set to yes, form elements follow the color style of the page. widget_colors=YES
I ended up calling the pref standard_widget_colors, which allows the toolkit to use its default colors.
old behavior: current text color on light grey. standard_widget_colors=YES: black on light grey. standard_widget_colors=NO: current text color on current background color.
Good! Committed. I left a default to standard when not present in dillorc2, but set it to use the new colors in the example dillorc2. Those reading the list, please test and comment. BTW, Why when in the bookmarks' modify page, checking a section gives a white mark while checking a URL gives a black one? I prefer the black one. It offers higher contrast. -- Cheers Jorge.-
Jorge wrote:
BTW, Why when in the bookmarks' modify page, checking a section gives a white mark while checking a URL gives a black one?
I prefer the black one. It offers higher contrast.
The int32_t c = bg->colors[FltkColor::SHADING_NORMAL]; int r = (c >> 24) & 0xff, g = (c >> 16) & 0xff, b = (c >> 8) & 0xff; bool light = r + g + b > 0x230; in FltkResource::setWidgetStyle() needs tweaking. Let's see... On my display, a test something like bool light = (r + g >= 0x150) || (r + g + b >= 0x180) might be about right. That's probably not the most mathematically concise way to describe that, but anyway... /* I'm too rusty at scripting languages, so: */ #include <stdio.h> int main(int argc, char **argv) { int red, green, blue; printf("<table>\n\n"); for (red = 0; red < 0x100; red += 0x10) { for (green = 0; green < 0x100; green += 0x10) { for (blue = 0; blue < 0x100; blue += 0x10) { printf("<tr bgcolor=#%02x%02x%02x> <td>\n", red, green, blue); printf("<form>\n"); printf("<input type=\"text\" value=\"%02x%02x%02x 0x%x\">\n", red,green,blue, red+green+blue); printf("</form>\n"); } } } printf("</table>\n"); return 0; }
On Sat, Feb 02, 2008 at 07:59:53PM +0000, place wrote:
Jorge wrote:
BTW, Why when in the bookmarks' modify page, checking a section gives a white mark while checking a URL gives a black one?
I prefer the black one. It offers higher contrast.
The
int32_t c = bg->colors[FltkColor::SHADING_NORMAL]; int r = (c >> 24) & 0xff, g = (c >> 16) & 0xff, b = (c >> 8) & 0xff; bool light = r + g + b > 0x230;
in FltkResource::setWidgetStyle() needs tweaking.
I see.
Let's see... On my display, a test something like bool light = (r + g >= 0x150) || (r + g + b >= 0x180) might be about right. That's probably not the most mathematically concise way to describe that, but anyway...
/* I'm too rusty at scripting languages, so: */
#include <stdio.h> int main(int argc, char **argv) { int red, green, blue; printf("<table>\n\n"); for (red = 0; red < 0x100; red += 0x10) { for (green = 0; green < 0x100; green += 0x10) { for (blue = 0; blue < 0x100; blue += 0x10) { printf("<tr bgcolor=#%02x%02x%02x> <td>\n", red, green, blue); printf("<form>\n"); printf("<input type=\"text\" value=\"%02x%02x%02x 0x%x\">\n", red,green,blue, red+green+blue); printf("</form>\n"); } } } printf("</table>\n"); return 0; }
Funny how with that page I get serious problems with redrawing widgets. If I load the page and left click the non-widget area, the widgets dissapear under the bgcolor. If I click on the widgets, partial redraws are got. I'm not yet testing with the latest drawing patch. Johannes: would you mind checking this? -- Cheers Jorge.-
On Sat, Feb 02, 2008 at 05:37:51PM -0300, Jorge Arellano Cid wrote:
Funny how with that page I get serious problems with redrawing widgets. If I load the page and left click the non-widget area, the widgets dissapear under the bgcolor. If I click on the widgets, partial redraws are got.
I'm not yet testing with the latest drawing patch.
Johannes: would you mind checking this?
I see this as well. I will take a look at that. Here it even crashes with: Core was generated by `dillo-fltk'. Program terminated with signal 11, Segmentation fault. #0 0x08063df5 in Html_submit_form2 (html=0x28540b00, form=0x29865380, e_input_idx=1) at html.cc:3923 3923 if (DataStr->str[DataStr->len - 1] == '&') (gdb) bt #0 0x08063df5 in Html_submit_form2 (html=0x28540b00, form=0x29865380, e_input_idx=1) at html.cc:3923 #1 0x0808a88c in dw::core::ui::ButtonResource::ClickedEmitter::emitToReceiver (this=0x287ea310, receiver=0x287ee520, signalNo=0, argc=2, argv=0xbfbff32c) at ui.cc:165 #2 0x0808f771 in loutsignal::Emitter::emitVoid (this=0x287ea310, signalNo=0, argc=2, argv=0xbfbff32c) at signal.cc:81 #3 0x0808af58 in dw::core::ui::ButtonResource::ClickedEmitter::emitClicked (this=0x287ea310, resource=0x287ea300, buttonNo=1) at ui.cc:175 #4 0x0807d79a in dw::core::ui::ButtonResource::emitClicked (this=0x287ea300, buttonNo=1) at ui.hh:348 #5 0x08052c34 in fltk::Widget::do_callback (this=0x287ea340) at /home/hofmann/include/fltk/Widget.h:125 #6 0x08097e6c in fltk::Button::handle (this=0x287ea340, event=2, rectangle=@0xbfbff3e4) at Button.cxx:121 #7 0x080980d4 in fltk::Button::handle (this=0x287ea340, event=2) at Button.cxx:77 #8 0x080e6c2a in fltk::Widget::send (this=0x287ea340, event=2) at Widget.cxx:805 #9 0x080c44a6 in fltk::handle (event=2, window=0x28541000) at run.cxx:1258 #10 0x080caa68 in fltk::handle () at x11/run.cxx:1947 #11 0x080caaac in do_queued_events () at x11/run.cxx:396 #12 0x080cadc6 in fl_wait (time_to_wait=1.00000002e+20) at x11/run.cxx:456 #13 0x080cae61 in fltk::wait (time_to_wait=1.00000002e+20) at run.cxx:457 #14 0x080caf78 in fltk::run () at run.cxx:393 #15 0x0804eaf1 in main (argc=4096, argv=0xbfbff94c) at dillo.cc:106 (gdb) p DataStr->len $1 = 0 (gdb) Johannes BTW: have you tried opening that page in dillo1 - it takes ages :-)
-- Cheers Jorge.-
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
Johannes wrote:
BTW: have you tried opening that page in dillo1 - it takes ages :-)
Wow... Measuring by clock time: dillo-fltk 0:07 /* clear_double_buffer(); */ dillo-fltk 1:03 clear_double_buffer(); dillo-0.8.1 2:20 firefox 2:35 Paging pretty hard the last 30 seconds. I did not dare to use the page after it finished. This does not count the other 22 seconds it takes just to start up for me.
On Sat, Feb 02, 2008 at 10:03:13PM +0000, place wrote:
Johannes wrote:
BTW: have you tried opening that page in dillo1 - it takes ages :-)
Wow... Measuring by clock time:
dillo-fltk 0:07 /* clear_double_buffer(); */ dillo-fltk 1:03 clear_double_buffer();
dillo-0.8.1 2:20
firefox 2:35 Paging pretty hard the last 30 seconds. I did not dare to use the page after it finished. This does not count the other 22 seconds it takes just to start up for me.
You can try with the new patch. -- Cheers Jorge.-
Jorge wrote:
On Sat, Feb 02, 2008 at 10:03:13PM +0000, place wrote:
Johannes wrote:
BTW: have you tried opening that page in dillo1 - it takes ages :-)
Wow... Measuring by clock time:
dillo-fltk 0:07 /* clear_double_buffer(); */ dillo-fltk 1:03 clear_double_buffer();
dillo-0.8.1 2:20
firefox 2:35 Paging pretty hard the last 30 seconds. I did not dare to use the page after it finished. This does not count the other 22 seconds it takes just to start up for me.
You can try with the new patch.
dillo-fltk immediate /* clear_double_buffer(); */ dillo-fltk 0:06 clear_double_buffer(); A modest improvement :) :) In fact, it takes longer to destroy the page (0:09) than to build it.
Hi, the following patch fixes the problem here: diff -r 4a9e0384d5ca dw/fltkviewbase.cc --- a/dw/fltkviewbase.cc Sat Feb 02 18:35:17 2008 +0100 +++ b/dw/fltkviewbase.cc Sun Feb 03 17:59:04 2008 +0100 @@ -64,7 +64,12 @@ void FltkViewBase::draw () translateCanvasYToViewY (rect->y), rect->width, rect->height); - viewRect.intersect(view); + viewRect.intersect (view); + + rect->x = translateViewXToCanvasX (viewRect.x ()); + rect->y = translateViewYToCanvasY (viewRect.y ()); + rect->width = viewRect.w (); + rect->height = viewRect.h (); if (!viewRect.empty ()) { push_clip (viewRect); It uses the rectangle that has been intersected with the current view area for expose(). But the real bug seems to be hidden somewhere in the table draw code. Without the patch, expose was called with a very high area (height was 106497!). This seems to cause problems. Perhaps some overflowing values? With the patch (which is a good optimization anyway), the height of the area that is passed to expose is limited by the current view size. Regards, Johannes On Sat, Feb 02, 2008 at 05:37:51PM -0300, Jorge Arellano Cid wrote:
On Sat, Feb 02, 2008 at 07:59:53PM +0000, place wrote:
Jorge wrote:
BTW, Why when in the bookmarks' modify page, checking a section gives a white mark while checking a URL gives a black one?
I prefer the black one. It offers higher contrast.
The
int32_t c = bg->colors[FltkColor::SHADING_NORMAL]; int r = (c >> 24) & 0xff, g = (c >> 16) & 0xff, b = (c >> 8) & 0xff; bool light = r + g + b > 0x230;
in FltkResource::setWidgetStyle() needs tweaking.
I see.
Let's see... On my display, a test something like bool light = (r + g >= 0x150) || (r + g + b >= 0x180) might be about right. That's probably not the most mathematically concise way to describe that, but anyway...
/* I'm too rusty at scripting languages, so: */
#include <stdio.h> int main(int argc, char **argv) { int red, green, blue; printf("<table>\n\n"); for (red = 0; red < 0x100; red += 0x10) { for (green = 0; green < 0x100; green += 0x10) { for (blue = 0; blue < 0x100; blue += 0x10) { printf("<tr bgcolor=#%02x%02x%02x> <td>\n", red, green, blue); printf("<form>\n"); printf("<input type=\"text\" value=\"%02x%02x%02x 0x%x\">\n", red,green,blue, red+green+blue); printf("</form>\n"); } } } printf("</table>\n"); return 0; }
Funny how with that page I get serious problems with redrawing widgets. If I load the page and left click the non-widget area, the widgets dissapear under the bgcolor. If I click on the widgets, partial redraws are got.
I'm not yet testing with the latest drawing patch.
Johannes: would you mind checking this?
-- Cheers Jorge.-
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
Hi Johannes, On Sun, Feb 03, 2008 at 06:06:39PM +0100, Johannes Hofmann wrote:
Hi,
the following patch fixes the problem here:
diff -r 4a9e0384d5ca dw/fltkviewbase.cc --- a/dw/fltkviewbase.cc Sat Feb 02 18:35:17 2008 +0100 +++ b/dw/fltkviewbase.cc Sun Feb 03 17:59:04 2008 +0100 @@ -64,7 +64,12 @@ void FltkViewBase::draw () translateCanvasYToViewY (rect->y), rect->width, rect->height);
- viewRect.intersect(view); + viewRect.intersect (view); + + rect->x = translateViewXToCanvasX (viewRect.x ()); + rect->y = translateViewYToCanvasY (viewRect.y ()); + rect->width = viewRect.w (); + rect->height = viewRect.h ();
if (!viewRect.empty ()) { push_clip (viewRect);
It uses the rectangle that has been intersected with the current view area for expose().
Great! BTW, I have also found places where an intersection may be missing...
But the real bug seems to be hidden somewhere in the table draw code. Without the patch, expose was called with a very high area (height was 106497!).
Please try to get to the root of the problem. I'll keep on the too-many-redraws problem. Later we can merge the ideas.
This seems to cause problems. Perhaps some overflowing values? With the patch (which is a good optimization anyway), the height of the area that is passed to expose is limited by the current view size.
OK. It looks like there's no problem to commit this patch. I mean it doesn't hide the other bug, right? -- Cheers Jorge.-
Hi Jorge, On Sun, Feb 03, 2008 at 02:53:59PM -0300, Jorge Arellano Cid wrote:
Hi Johannes,
On Sun, Feb 03, 2008 at 06:06:39PM +0100, Johannes Hofmann wrote:
Hi,
the following patch fixes the problem here:
diff -r 4a9e0384d5ca dw/fltkviewbase.cc --- a/dw/fltkviewbase.cc Sat Feb 02 18:35:17 2008 +0100 +++ b/dw/fltkviewbase.cc Sun Feb 03 17:59:04 2008 +0100 @@ -64,7 +64,12 @@ void FltkViewBase::draw () translateCanvasYToViewY (rect->y), rect->width, rect->height);
- viewRect.intersect(view); + viewRect.intersect (view); + + rect->x = translateViewXToCanvasX (viewRect.x ()); + rect->y = translateViewYToCanvasY (viewRect.y ()); + rect->width = viewRect.w (); + rect->height = viewRect.h ();
if (!viewRect.empty ()) { push_clip (viewRect);
It uses the rectangle that has been intersected with the current view area for expose().
Great!
BTW, I have also found places where an intersection may be missing...
But the real bug seems to be hidden somewhere in the table draw code. Without the patch, expose was called with a very high area (height was 106497!).
Please try to get to the root of the problem. I'll keep on the too-many-redraws problem. Later we can merge the ideas.
This seems to cause problems. Perhaps some overflowing values? With the patch (which is a good optimization anyway), the height of the area that is passed to expose is limited by the current view size.
OK.
It looks like there's no problem to commit this patch. I mean it doesn't hide the other bug, right?
Yes it hides the other bug, but you can commit it anyway. Cheers, Johannes
-- Cheers Jorge.-
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
On Sun, Feb 03, 2008 at 07:31:17PM +0100, Johannes Hofmann wrote:
Hi Jorge,
On Sun, Feb 03, 2008 at 02:53:59PM -0300, Jorge Arellano Cid wrote:
Hi Johannes,
On Sun, Feb 03, 2008 at 06:06:39PM +0100, Johannes Hofmann wrote:
Hi,
the following patch fixes the problem here:
diff -r 4a9e0384d5ca dw/fltkviewbase.cc --- a/dw/fltkviewbase.cc Sat Feb 02 18:35:17 2008 +0100 +++ b/dw/fltkviewbase.cc Sun Feb 03 17:59:04 2008 +0100 @@ -64,7 +64,12 @@ void FltkViewBase::draw () translateCanvasYToViewY (rect->y), rect->width, rect->height);
- viewRect.intersect(view); + viewRect.intersect (view); + + rect->x = translateViewXToCanvasX (viewRect.x ()); + rect->y = translateViewYToCanvasY (viewRect.y ()); + rect->width = viewRect.w (); + rect->height = viewRect.h ();
if (!viewRect.empty ()) { push_clip (viewRect);
It uses the rectangle that has been intersected with the current view area for expose().
Great!
BTW, I have also found places where an intersection may be missing...
But the real bug seems to be hidden somewhere in the table draw code. Without the patch, expose was called with a very high area (height was 106497!).
Please try to get to the root of the problem. I'll keep on the too-many-redraws problem. Later we can merge the ideas.
This seems to cause problems. Perhaps some overflowing values? With the patch (which is a good optimization anyway), the height of the area that is passed to expose is limited by the current view size.
OK.
It looks like there's no problem to commit this patch. I mean it doesn't hide the other bug, right?
Yes it hides the other bug, but you can commit it anyway.
Committed. -- Cheers Jorge.-
Hi Jorge, On Sun, Feb 03, 2008 at 02:53:59PM -0300, Jorge Arellano Cid wrote:
Hi Johannes,
On Sun, Feb 03, 2008 at 06:06:39PM +0100, Johannes Hofmann wrote:
Hi,
the following patch fixes the problem here:
diff -r 4a9e0384d5ca dw/fltkviewbase.cc --- a/dw/fltkviewbase.cc Sat Feb 02 18:35:17 2008 +0100 +++ b/dw/fltkviewbase.cc Sun Feb 03 17:59:04 2008 +0100 @@ -64,7 +64,12 @@ void FltkViewBase::draw () translateCanvasYToViewY (rect->y), rect->width, rect->height);
- viewRect.intersect(view); + viewRect.intersect (view); + + rect->x = translateViewXToCanvasX (viewRect.x ()); + rect->y = translateViewYToCanvasY (viewRect.y ()); + rect->width = viewRect.w (); + rect->height = viewRect.h ();
if (!viewRect.empty ()) { push_clip (viewRect);
It uses the rectangle that has been intersected with the current view area for expose().
Great!
BTW, I have also found places where an intersection may be missing...
But the real bug seems to be hidden somewhere in the table draw code. Without the patch, expose was called with a very high area (height was 106497!).
Please try to get to the root of the problem. I'll keep on the too-many-redraws problem. Later we can merge the ideas.
The root cause seems to be an overflow of X11 coordinates. If you try: #include <stdio.h> #include <fltk/Window.h> #include <fltk/Widget.h> #include <fltk/Button.h> #include <fltk/run.h> #include <fltk/draw.h> #include <fltk/damage.h> using namespace fltk; Widget *test; class Test : public Widget { public: Test(int _x, int _y, int _w, int _h) : Widget(_x, _y, _w, _h) {}; void draw() { for (int y=1000;y < 70000; y +=10) { fillrect(0, y, 10, 10); } } }; int main(int argc, char **argv) { Window *window = new Window(300, 180); window->begin(); test = new Test(20, 40, 260, 100); window->end(); window->show(argc, argv); return run(); } you will see a black bar. If you only count to 60000 instead of 70000, the window stays gray. X11 uses shorts somewhere that can overflow. So the fix in fltkviewbase.cc is sufficient, I think. Cheers, Johannes
This seems to cause problems. Perhaps some overflowing values? With the patch (which is a good optimization anyway), the height of the area that is passed to expose is limited by the current view size.
OK.
It looks like there's no problem to commit this patch. I mean it doesn't hide the other bug, right?
-- Cheers Jorge.-
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
On Sun, Feb 03, 2008 at 08:32:46PM +0100, Johannes Hofmann wrote:
Hi Jorge,
On Sun, Feb 03, 2008 at 02:53:59PM -0300, Jorge Arellano Cid wrote:
Hi Johannes,
On Sun, Feb 03, 2008 at 06:06:39PM +0100, Johannes Hofmann wrote:
Hi,
the following patch fixes the problem here:
diff -r 4a9e0384d5ca dw/fltkviewbase.cc --- a/dw/fltkviewbase.cc Sat Feb 02 18:35:17 2008 +0100 +++ b/dw/fltkviewbase.cc Sun Feb 03 17:59:04 2008 +0100 @@ -64,7 +64,12 @@ void FltkViewBase::draw () translateCanvasYToViewY (rect->y), rect->width, rect->height);
- viewRect.intersect(view); + viewRect.intersect (view); + + rect->x = translateViewXToCanvasX (viewRect.x ()); + rect->y = translateViewYToCanvasY (viewRect.y ()); + rect->width = viewRect.w (); + rect->height = viewRect.h ();
if (!viewRect.empty ()) { push_clip (viewRect);
It uses the rectangle that has been intersected with the current view area for expose().
Great!
BTW, I have also found places where an intersection may be missing...
But the real bug seems to be hidden somewhere in the table draw code. Without the patch, expose was called with a very high area (height was 106497!).
Please try to get to the root of the problem. I'll keep on the too-many-redraws problem. Later we can merge the ideas.
The root cause seems to be an overflow of X11 coordinates. If you try:
#include <stdio.h> #include <fltk/Window.h> #include <fltk/Widget.h> #include <fltk/Button.h> #include <fltk/run.h> #include <fltk/draw.h> #include <fltk/damage.h> using namespace fltk;
Widget *test;
class Test : public Widget { public: Test(int _x, int _y, int _w, int _h) : Widget(_x, _y, _w, _h) {};
void draw() { for (int y=1000;y < 70000; y +=10) { fillrect(0, y, 10, 10); } } };
int main(int argc, char **argv) { Window *window = new Window(300, 180); window->begin(); test = new Test(20, 40, 260, 100); window->end(); window->show(argc, argv); return run(); }
you will see a black bar. If you only count to 60000 instead of 70000, the window stays gray.
X11 uses shorts somewhere that can overflow. So the fix in fltkviewbase.cc is sufficient, I think.
Excellent, I'll leave it as is. -- Cheers Jorge.-
participants (3)
-
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
place＠gobigwest.com