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

[patch] use CURSOR_MOVE when drag scrolling

by Johannes.Hofmann＠gmx.de

Hi, the patch below disallows drag scrolling over links where the middle mouse button is used to open the link in a new window. It also changes the cursor to CURSOR_MOVE when drag scrolling. Cheers, Johannes diff --git a/dw/fltkviewport.cc b/dw/fltkviewport.cc --- a/dw/fltkviewport.cc +++ b/dw/fltkviewport.cc @@ -233,11 +233,13 @@ int FltkViewport::handle (int event) case ::fltk::PUSH: take_focus(); if (::fltk::event_button() == ::fltk::MiddleButton) { - dragScrolling = 1; - dragX = ::fltk::event_x(); - dragY = ::fltk::event_y(); /* pass event so that middle click can open link in new window */ - FltkWidgetView::handle (event); + if (FltkWidgetView::handle (event) == 0) { + dragScrolling = 1; + dragX = ::fltk::event_x(); + dragY = ::fltk::event_y(); + setCursor (core::style::CURSOR_MOVE); + } return 1; } break; @@ -260,6 +262,7 @@ int FltkViewport::handle (int event) case ::fltk::RELEASE: if (::fltk::event_button() == ::fltk::MiddleButton) { dragScrolling = 0; + setCursor (core::style::CURSOR_DEFAULT); } break;

Feb. 28, 2008

From the FLTK devs: [dejan.lekic@gmail.com: Re: [fltk.development] This year GSOC]

by Johannes.Hofmann＠gmx.de

On Thu, Feb 28, 2008 at 05:32:55PM +0000, Jeremy Henty wrote: > > Just to make sure no-one misses this, some love from the FLTK guys! > > Jeremy Henty > > > ----- Forwarded message from Dejan Lekic <dejan.lekic(a)gmail.com> ----- > > From: Dejan Lekic <dejan.lekic(a)gmail.com> > To: fltk-dev(a)easysw.com > Subject: Re: [fltk.development] This year GSOC > Date: Thu, 28 Feb 2008 08:25:55 -0800 > > > Personally, the thing I most anticipate and would like to see improved, > which is related to FLTK, is the Dillo port to FLTK2. > > Seriously, if Dillo2 could be done as a library, and provide a Group > widget which is directly embeddable into any FLTK2 application, that > would be IMHO a huuuuuge thing. > > So, I hope someone would help Dillo guys either via GSoC, or other way(s). > > More information: http://www.dillo.org . Get the fresh FLTK2 port of > Dillo from CVS: :pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo That's cool! We will need some help from the FLTK guys sooner or later. Cheers, Johannes

Feb. 28, 2008

From the FLTK devs: [dejan.lekic@gmail.com: Re: [fltk.development] This year GSOC]

by onepoint＠starurchin.org

Just to make sure no-one misses this, some love from the FLTK guys! Jeremy Henty ----- Forwarded message from Dejan Lekic <dejan.lekic(a)gmail.com> ----- From: Dejan Lekic <dejan.lekic(a)gmail.com> To: fltk-dev(a)easysw.com Subject: Re: [fltk.development] This year GSOC Date: Thu, 28 Feb 2008 08:25:55 -0800 Personally, the thing I most anticipate and would like to see improved, which is related to FLTK, is the Dillo port to FLTK2. Seriously, if Dillo2 could be done as a library, and provide a Group widget which is directly embeddable into any FLTK2 application, that would be IMHO a huuuuuge thing. So, I hope someone would help Dillo guys either via GSoC, or other way(s). More information: http://www.dillo.org . Get the fresh FLTK2 port of Dillo from CVS: :pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo Kind regards _______________________________________________ fltk-dev mailing list fltk-dev(a)easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev ----- End forwarded message -----

Feb. 28, 2008

patch: multipart/form-data encoding for form submission

by jcid＠dillo.org

On Sun, Feb 10, 2008 at 11:42:10PM +0000, place wrote: > Currently, dillo always submits forms using url encoding regardless of > the encoding specified by the form. Wikipedia, for example, specifies > multipart/form-data because the user may submit huge blocks of text > in languages where url encoding will be very inefficient. OK, committed. > - This patch always uses the same boundary, but a different > one REALLY should be used for every form submission. At > the least, the string should be scrambled up somehow. Yes, please finish that part. Probably checking the boundary string against URL_DATA, with strstr is a good idea too. > - It adds a URL_MultipartEnc flag. > - For the Content-type header, I pull the boundary out of > URL_DATA because I didn't want to clutter up the URL with > a field for something not commonly used. OK. -- Cheers Jorge.-

Feb. 28, 2008

[patch] redraw optimization now including tables

by Johannes.Hofmann＠gmx.de

Hello, below is an improved version of the redraw optimization. It now also covers table based pages - at least to some point. The challenge is to make the already commited optimization work recursively. Other than I originally thought topLevel is always a Textblock. Table based pages simply consist of a Textblock with a huge Table as child widget. Textblock now needs to avoid redrawing the child area when the table size increases. The redrawing is left to the Table-code, which then can be optimized. Please test carefully and report any anomalies you find. Regards, Johannes

Feb. 27, 2008

patch: conditionally sending Cookie2: Re: [Dillo-dev] Re: patch: cookies string leak

by jcid＠dillo.org

On Mon, Feb 04, 2008 at 08:10:25PM +0000, place wrote: > Jorge wrote: > > 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. > > attached. > > I renamed it a_Cookies_get_query() in an effort > to suggest that it now returned more than just > the cookies. > > > Everything looks fine when I watch the headers, > but I don't use dillo for anything that _relies_ > on cookies working properly. Committed. > So...anyone who habitually uses cookies might want > to give this a bit of a test. Now that's on CVS it should get a share of testing... -- Cheers Jorge.- PS: sorry for the long wait.

Feb. 24, 2008

PATCH: small improvement to the "can't start dpid daemon" error message

by jcid＠dillo.org

On Sat, Feb 23, 2008 at 09:27:30PM +0000, Jeremy Henty wrote: > > A common cause of the "can't start dpid daemon" error is clicking on a > link with a typo'ed HREF that has an invalid URL scheme (eg. 'ttp://' > instead of 'http://', to cite the real-life example that prompted this > patch). But the error message gives *no* context that would help to > diagnose the problem. If it cited the URL scheme it would save a lot > of time. (I had to start Firefox before I realised what the problem > was!) Here's a patch to do that. Thanks Jeremy. Committed! -- Cheers Jorge.-

Feb. 24, 2008

[patch] fix redraw problem with findText

by jcid＠dillo.org

On Sat, Feb 23, 2008 at 09:07:30PM +0100, Johannes Hofmann wrote: > Hello, > > the patch below fixes the redraw problem with findText found by > place that was introduced with my textblock optimization. Partial > redraws were interfering with scrolling. The findText method is a > nice test for this code path! Good, committed. > I'm now experimenting with a redraw optimization that covers table > based pages too. It's looking promising, but it needs some more work. Great. I gave this a try, and after several tests, one thing was very clear: I don't yet understand how it works! :-) The test I used is a long table (generated with the attached program), served through a cgi that slows down the transfer rate (code attached for the cgi-program too). After installing the cgi-program, the test can be run like this: ./dillo-fltk "http://localhost/cgi-bin/slow.cgi?1000:/tmp/table3.html" (the number is the transfer rate in Bytes/second). You'll see one unnecessary erase/redraw per each new chunk of data that's out of the screen. With regard to my suggestion of not updating the table when the column sizes weren't changed, I thought of something akin to the attached patch (incomplete, working for AUTO tables, easy to finish, suitable for testing). > [...] > Independent from that, I'm using my last patch regarding the redraws > for quite a while now and it works pretty well here. > Doesn't it make dillo2 much more useable for you, or do you see > negative effects with it? Yes surely more usable. The problem I saw long ago, was that on low CPU machines it requested more redraws, but this will be moot after the textblock/table optimizations. Most probably neither ASAP nor throttling will be needed then, and if the need ever arises I'd favor the idle-function throttling idea, as it looks simpler. Thanks for keeping up the good work! -- Cheers Jorge.-

Feb. 24, 2008

PATCH: small improvement to the "can't start dpid daemon" error message

by onepoint＠starurchin.org

A common cause of the "can't start dpid daemon" error is clicking on a link with a typo'ed HREF that has an invalid URL scheme (eg. 'ttp://' instead of 'http://', to cite the real-life example that prompted this patch). But the error message gives *no* context that would help to diagnose the problem. If it cited the URL scheme it would save a lot of time. (I had to start Firefox before I realised what the problem was!) Here's a patch to do that. Jeremy Henty

Feb. 23, 2008

[patch] fix redraw problem with findText

by Johannes.Hofmann＠gmx.de

Hello, the patch below fixes the redraw problem with findText found by place that was introduced with my textblock optimization. Partial redraws were interfering with scrolling. The findText method is a nice test for this code path! I'm now experimenting with a redraw optimization that covers table based pages too. It's looking promising, but it needs some more work. Cheers, Johannes diff --git a/dw/fltkviewbase.cc b/dw/fltkviewbase.cc --- a/dw/fltkviewbase.cc +++ b/dw/fltkviewbase.cc @@ -85,6 +85,7 @@ void FltkViewBase::draw () } } + drawRegion.clear (); d &= ~DAMAGE_VALUE; } @@ -110,9 +111,12 @@ void FltkViewBase::draw () area.width = rect.w(); area.height = rect.h(); theLayout->expose (this, &area); + + if (! (d & DAMAGE_SCROLL)) { + drawRegion.clear (); + } } - drawRegion.clear (); } void FltkViewBase::drawChildWidgets () { diff --git a/dw/fltkviewport.cc b/dw/fltkviewport.cc --- a/dw/fltkviewport.cc +++ b/dw/fltkviewport.cc @@ -185,6 +185,7 @@ void FltkViewport::draw () int d = damage(); if (d & DAMAGE_SCROLL) { + set_damage (DAMAGE_SCROLL); scrollrect(cr, -scrollDX, -scrollDY, draw_area, this); d &= ~DAMAGE_SCROLL; set_damage (d);

Feb. 23, 2008