February 2008 - Dillo-dev - lists.mailman3.com

[patch] fix size of select widgets

by Johannes.Hofmann＠gmx.de

Here is a small patch to compute the size of select widgets similar to the way it is computed for text input widgets. The width is hardcoded to 10 * size of 'M' in the current font. Regards, Johannes PS: The colored widgets are nice! diff -r 68ee0a55704c dw/fltkui.cc --- a/dw/fltkui.cc Sat Feb 02 18:36:32 2008 +0100 +++ b/dw/fltkui.cc Sat Feb 02 19:20:16 2008 +0100 @@ -1048,10 +1048,21 @@ void FltkOptionMenuResource::widgetCallb void FltkOptionMenuResource::sizeRequest (core::Requisition *requisition) { - /** \bug Random values. */ - requisition->width = 100; - requisition->ascent = 18; - requisition->descent = 5; + if (style) { + FltkFont *font = (FltkFont*)style->font; + ::fltk::setfont(font->font,font->size); + requisition->width = + (int)::fltk::getwidth ("M", 1) * 10 + + 2 * RELIEF_X_THICKNESS; + requisition->ascent = + font->ascent + RELIEF_Y_THICKNESS; + requisition->descent = + font->descent + RELIEF_Y_THICKNESS; + } else { + requisition->width = 1; + requisition->ascent = 1; + requisition->descent = 0; + } }

Feb. 2, 2008

a couple of patches: referer and image_off

by jcid＠dillo.org

On Fri, Feb 01, 2008 at 11:18:30PM +0000, place wrote: > Jorge wrote: > > On Fri, Feb 01, 2008 at 07:38:45PM +0000, place wrote: > > > > In brief, using the same URI, the three options offer good > > > > privacy (because no new information is sent), and if we ever > > > > enable using the referring page, the old comments apply. > > > > > > Whew. > > > > > > See, I ran on the equivalent of "host" for > > > at least a year, and then have been using the > > > equivalent of "path" for at least a year, so > > > the idea that I had somehow been doing something > > > wrong was alarming :) > > > > :-) > > > > Well, in that case you can provide good advice on which is > > better as a default. > > Well, I tried "path" one day when "host" didn't work for > some site, and I had the impression that "path" worked more > consistently, but I wasn't being very scientific about it. It looks like we may default to "path". > Nowadays, if I bother to look at why an image doesn't want > to load, it usually turns out that it was a redirection. > I'd been sort of curious why dillo doesn't follow redirections > for non-root urls, but hadn't gotten around to asking... Non-root redirected images are mainly advertising! :-) -- Cheers Jorge.-

Feb. 2, 2008

patch: Re: [Dillo-dev] an experiment in widget coloring (with code)

by jcid＠dillo.org

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

Feb. 2, 2008

patch: Re: [Dillo-dev] an experiment in widget coloring (with code)

by place＠gobigwest.com

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.

Feb. 2, 2008

a couple of patches: referer and image_off

by place＠gobigwest.com

Jorge wrote: > On Fri, Feb 01, 2008 at 07:38:45PM +0000, place wrote: > > > In brief, using the same URI, the three options offer good > > > privacy (because no new information is sent), and if we ever > > > enable using the referring page, the old comments apply. > > > > Whew. > > > > See, I ran on the equivalent of "host" for > > at least a year, and then have been using the > > equivalent of "path" for at least a year, so > > the idea that I had somehow been doing something > > wrong was alarming :) > > :-) > > Well, in that case you can provide good advice on which is > better as a default. Well, I tried "path" one day when "host" didn't work for some site, and I had the impression that "path" worked more consistently, but I wasn't being very scientific about it. Nowadays, if I bother to look at why an image doesn't want to load, it usually turns out that it was a redirection. I'd been sort of curious why dillo doesn't follow redirections for non-root urls, but hadn't gotten around to asking...

Feb. 2, 2008

a couple of patches: referer and image_off

by jcid＠dillo.org

On Fri, Feb 01, 2008 at 07:38:45PM +0000, place wrote: > > In brief, using the same URI, the three options offer good > > privacy (because no new information is sent), and if we ever > > enable using the referring page, the old comments apply. > > Whew. > > See, I ran on the equivalent of "host" for > at least a year, and then have been using the > equivalent of "path" for at least a year, so > the idea that I had somehow been doing something > wrong was alarming :) :-) Well, in that case you can provide good advice on which is better as a default. -- Cheers Jorge.-

Feb. 1, 2008

Re: patch: cookies string leak

by jcid＠dillo.org

On Fri, Feb 01, 2008 at 06:26:56PM +0000, place wrote: > Also, what would you think of me either > > - stuffing the "Cookie2: $Version=\"1\"\r\n" header into a_Cookies_get(url) OK. Basically the same way referer is handled. > or > - adding a function to http.c to accomplish the same thing? > ...with a_Cookies_get() changed to show a distinction between > don't-want-cookies and don't-have-cookies. > > I almost never have any cookies enabled, so I'd prefer not to send > the Cookie2 header all of the time when I don't want their cookies. No problem. Leak patch committed. -- Cheers Jorge.-

Feb. 1, 2008

[PATCH]: Table::apportionRowSpan()

by jcid＠dillo.org

Hi, On Fri, Feb 01, 2008 at 07:49:43PM +0000, Jeremy Henty wrote: > On Fri, Feb 01, 2008 at 03:15:13PM -0300, Jorge Arellano Cid wrote: > > On Fri, Feb 01, 2008 at 06:10:39AM +0000, Jeremy Henty wrote: > > > > > > (BTW, I still think there is a case for reworking Dillo's ROWSPAN > > > algorithms along the lines I suggested, but it's nice to fix bugs > > > without such efforts.) > > > > If you want to go further, please keep in the O(n) realm. > > I will. It is easy to calculate the minimum cumulative depths of the > rows in a single pass over the cells, treating all ROWSPAN values in > the same way. (In fact it needs only a small modification to the > current code: my previous patch was so ridiculously over-engineered > that I'm quite embarrassed by it.) The problem is that if you use > those depths then you squash everything up to the top, so that when a > cell spans several rows all the extra space goes into the bottom row. > That might be mathematically correct but it will look just plain > wrong. > > It is easy to do a second pass from the bottom-up to find the > *maximum* cumulative depths (subject to the total height of the table > being minimal); the challenge is to find a way to average those two > sets of values that (a) does something sensible in all cases, (b) does > the obvious right thing in simple cases, ie. if one cell spans n rows > then any spare space is distributed evenly between those rows, and (c) > takes O(n). I think I can do it, but haven't yet coded it. The "obvious right thing" may vary. For instance, what the algorithm currently does is to proportionally apportion the extra space (just as Firefox). e.g. <table border=1> <tr> <td rowspan=3> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 <td>A <tr><td>A B <tr> <td>A B C </tr> </table> Although most probably you're thinking of a more complex case. -- Cheers Jorge.-

Feb. 1, 2008

[PATCH]: Table::apportionRowSpan()

by onepoint＠starurchin.org

On Fri, Feb 01, 2008 at 03:15:13PM -0300, Jorge Arellano Cid wrote: > On Fri, Feb 01, 2008 at 06:10:39AM +0000, Jeremy Henty wrote: > > > > (BTW, I still think there is a case for reworking Dillo's ROWSPAN > > algorithms along the lines I suggested, but it's nice to fix bugs > > without such efforts.) > > If you want to go further, please keep in the O(n) realm. I will. It is easy to calculate the minimum cumulative depths of the rows in a single pass over the cells, treating all ROWSPAN values in the same way. (In fact it needs only a small modification to the current code: my previous patch was so ridiculously over-engineered that I'm quite embarrassed by it.) The problem is that if you use those depths then you squash everything up to the top, so that when a cell spans several rows all the extra space goes into the bottom row. That might be mathematically correct but it will look just plain wrong. It is easy to do a second pass from the bottom-up to find the *maximum* cumulative depths (subject to the total height of the table being minimal); the challenge is to find a way to average those two sets of values that (a) does something sensible in all cases, (b) does the obvious right thing in simple cases, ie. if one cell spans n rows then any spare space is distributed evenly between those rows, and (c) takes O(n). I think I can do it, but haven't yet coded it. Regards, Jeremy Henty

Feb. 1, 2008

[experimental patch] excessive redraws (again)

by Johannes.Hofmann＠gmx.de

Hello, let's get more agressive regarding these excessive redraws :-) Below are two patches. The first one adds a own run method to FltkPlatform. It is pretty similar to what fltk delivers, but this way we can tweak it as we like. Especially when to call our idle functions. The other patch changes resizeIdle() a bit. As stated in the comments, resizeIdle() can queue a new resizeIdle(). So instead of drawing the preliminary layout, then change it and redraw again, we now wait until the layout is settled and then draw it. Please note, that the provided run method was tuned for my computer, so it may need other values on slower/faster machines. Play around with other strategies! Johannes diff --git a/dw/fltkplatform.cc b/dw/fltkplatform.cc --- a/dw/fltkplatform.cc +++ b/dw/fltkplatform.cc @@ -25,6 +25,7 @@ #include <fltk/draw.h> #include <fltk/run.h> #include <fltk/events.h> +#include <fltk/Window.h> #include <stdio.h> namespace dw { @@ -185,6 +186,9 @@ container::typed::HashTable <dw::core::s new container::typed::HashTable <dw::core::style::ColorAttrs, dw::core::style::Color> (false, false); +container::typed::List <FltkPlatform> *FltkPlatform::idlePlatforms = + new container::typed::List <FltkPlatform> (0); + FltkPlatform::FltkPlatform () { layout = NULL; @@ -200,8 +204,7 @@ FltkPlatform::FltkPlatform () FltkPlatform::~FltkPlatform () { - if(idleFuncRunning) - remove_idle (generalStaticIdle, (void*)this); + idlePlatforms->removeRef(this); delete idleQueue; } @@ -241,11 +244,6 @@ int FltkPlatform::textWidth (core::style FltkFont *ff = (FltkFont*) font; setfont (ff->font, ff->size); return (int) getwidth (text, len); -} - -void FltkPlatform::generalStaticIdle (void *data) -{ - ((FltkPlatform*)data)->generalIdle(); } void FltkPlatform::generalIdle () @@ -263,7 +261,7 @@ void FltkPlatform::generalIdle () if(idleQueue->isEmpty()) { idleFuncRunning = false; - remove_idle (generalStaticIdle, (void*)this); + idlePlatforms->removeRef (this); } } @@ -277,8 +275,9 @@ int FltkPlatform::addIdle (void (core::L * idle function, the passed idle function is put into a queue. */ if(!idleFuncRunning) { - add_idle (generalStaticIdle, (void*)this); idleFuncRunning = true; + idlePlatforms->removeRef (this); + idlePlatforms->append (this); } idleFuncId++; @@ -306,7 +305,7 @@ void FltkPlatform::removeIdle (int idleI } if(idleFuncRunning && idleQueue->isEmpty()) - remove_idle (generalStaticIdle, (void*)this); + idlePlatforms->removeRef (this); } @@ -409,5 +408,30 @@ void FltkPlatform::detachResource (ui::F resources->removeRef (resource); } + +int FltkPlatform::run () { + int skipped = 0; + + while (::fltk::Window::first()) { + int r = fltk::wait (0.01); + + if (r == 0 || skipped >= 50) { + skipped = 0; + + for (container::typed::Iterator <FltkPlatform> it = idlePlatforms->iterator (); + it.hasNext (); ) { + FltkPlatform *p = it.getNext (); + + p->generalIdle (); + } + + } else { + skipped++; + } + } + + return 0; +} + } // namespace fltk } // namespace dw diff --git a/dw/fltkplatform.hh b/dw/fltkplatform.hh --- a/dw/fltkplatform.hh +++ b/dw/fltkplatform.hh @@ -94,7 +94,7 @@ private: bool idleFuncRunning; int idleFuncId; - static void generalStaticIdle(void *data); + static container::typed::List <FltkPlatform> *idlePlatforms; void generalIdle(); container::typed::List <FltkView> *views; @@ -163,6 +163,8 @@ public: void attachResource (ui::FltkResource *resource); void detachResource (ui::FltkResource *resource); + + static int run(); }; } // namespace fltk diff --git a/config.h.in b/config.h.in diff --git a/src/dillo.cc b/src/dillo.cc --- a/src/dillo.cc +++ b/src/dillo.cc @@ -23,6 +23,8 @@ #include <fltk/Window.h> #include <fltk/run.h> + +#include "dw/fltkcore.hh" #include "dir.h" #include "uicmd.hh" @@ -103,5 +105,5 @@ int main(int argc, char **argv) a_Nav_push(bw, prefs.start_page); } - return fltk::run(); + return dw::fltk::FltkPlatform::run(); } diff --git a/dw/layout.cc b/dw/layout.cc --- a/dw/layout.cc +++ b/dw/layout.cc @@ -520,58 +520,61 @@ void Layout::updateBgColor () void Layout::resizeIdle () { - // Reset already here, since in this function, queueResize() may be - // called again. - resizeIdleId = -1; - - if (topLevel) { - Requisition requisition; - Allocation allocation; - - topLevel->sizeRequest (&requisition); - - allocation.x = allocation.y = 0; - allocation.width = requisition.width; - allocation.ascent = requisition.ascent; - allocation.descent = requisition.descent; - topLevel->sizeAllocate (&allocation); - - canvasWidth = requisition.width; - canvasAscent = requisition.ascent; - canvasDescent = requisition.descent; - emitter.emitCanvasSizeChanged (canvasWidth, canvasAscent, canvasDescent); + while (resizeIdleId != -1) { + // Reset already here, since in this function, queueResize() may be + // called again. + resizeIdleId = -1; - // Tell the views about the new world size. - for (typed::Iterator <View> it = views->iterator (); it.hasNext (); ) { - View *view = it.getNext (); - view->setCanvasSize (canvasWidth, canvasAscent, canvasDescent); - view->queueDrawTotal (); - } + if (topLevel) { + Requisition requisition; + Allocation allocation; - if (usesViewport) { - int actualHScrollbarThickness = - (canvasWidth > viewportWidth) ? hScrollbarThickness : 0; - int actualVScrollbarThickness = + topLevel->sizeRequest (&requisition); + + allocation.x = allocation.y = 0; + allocation.width = requisition.width; + allocation.ascent = requisition.ascent; + allocation.descent = requisition.descent; + topLevel->sizeAllocate (&allocation); + + canvasWidth = requisition.width; + canvasAscent = requisition.ascent; + canvasDescent = requisition.descent; + + emitter.emitCanvasSizeChanged (canvasWidth, canvasAscent, canvasDescent); + + // Tell the views about the new world size. + for (typed::Iterator <View> it = views->iterator (); it.hasNext (); ) { + View *view = it.getNext (); + view->setCanvasSize (canvasWidth, canvasAscent, canvasDescent); + view->queueDrawTotal (); + } + + if (usesViewport) { + int actualHScrollbarThickness = + (canvasWidth > viewportWidth) ? hScrollbarThickness : 0; + int actualVScrollbarThickness = (canvasAscent + canvasDescent > viewportWidth) ? vScrollbarThickness : 0; - - if (!canvasHeightGreater && - canvasAscent + canvasDescent - > viewportHeight - actualHScrollbarThickness) { - canvasHeightGreater = true; - setSizeHints (); - /* May queue a new resize. */ - } - // Set viewport sizes. - for (typed::Iterator <View> it = views->iterator (); - it.hasNext (); ) { - View *view = it.getNext (); - if (view->usesViewport ()) - view->setViewportSize (viewportWidth, viewportHeight, - actualHScrollbarThickness, - actualVScrollbarThickness); + if (!canvasHeightGreater && + canvasAscent + canvasDescent + > viewportHeight - actualHScrollbarThickness) { + canvasHeightGreater = true; + setSizeHints (); + /* May queue a new resize. */ + } + + // Set viewport sizes. + for (typed::Iterator <View> it = views->iterator (); + it.hasNext (); ) { + View *view = it.getNext (); + if (view->usesViewport ()) + view->setViewportSize (viewportWidth, viewportHeight, + actualHScrollbarThickness, + actualVScrollbarThickness); + } } }

Feb. 1, 2008