- Dillo-dev - lists.mailman3.com

[patch] use CURSOR_MOVE when drag scrolling

by jcid＠dillo.org

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. Committed. -- Cheers Jorge.-

Feb. 29, 2008

Re: patch: not-a-png message

by jcid＠dillo.org

On Fri, Feb 29, 2008 at 04:42:05PM +0000, place wrote: > Just noticed this in my tree while making multipart diffs. I'd forgotten > about it... Committed. -- Cheers Jorge.-

Feb. 29, 2008

[patch] redraw optimization now including tables

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Fri, Feb 29, 2008 at 10:18:45AM -0300, Jorge Arellano Cid wrote: > Hi Johannes, > > On Wed, Feb 27, 2008 at 05:56:36PM +0100, Johannes Hofmann wrote: > > Hello, > > > > below is an improved version of the redraw optimization. It now also > > covers table based pages - at least to some point. > > Yes, in fact it avoids redraws on the test posted in my last email. > If I give that test another page, e.g. www.gnu-darwin.org/update.html, > it can also avoid _some_ redraws. So the partial optimization seems to > be working. Yes, the patch only tries to avoid redraws that change nothing on the screen. For complex tables that get rearranged all the time while loading, there is still a lot of redraws. However there is certainly room for improvement. For the fun of it, you can comment out the lines in table.hh where redrawY gets reset. That saves a lot of redraws at the cost of some anomalies... > > > The challenge is to make the already commited optimization work > > recursively. > > Do you want me to commit this new patch, or to keep the already > committed one? > > > > 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. > > AFAIU textblock draws by lines and as the first line is a huge table > it requests a redraw of it. With this patch it does not. It leaves the drawing of the table to the table code. > > I don't know yet why textblock is requesting a redraw; I assume that > as the table size changed, textblock gets notified and as it doesn't > know better it asks the child widgets for a full redraw. If the resizing does not change anything that is actually drawn by the Textblock (like real text), it does not need to request a redraw. > > From a distance it looks like a conditionalRedraw() may be the needed call > (I don't know well what expose means). I mean if this conditional redraw > sees that nothing has changed in the specified area, it can simply return, > otherwise redraw. Yes, that's the idea of the new virtual method resizeDrawImpl(). Each widget can remember what has already been drawn and what might have changed because of resizes and then draw only the necessary parts. It depends on each widget how careful it is. Tables have the unfortunate property of changing their layout all over when new cells are added thereby requiring complete redraws. > > > > The redrawing is left > > to the Table-code, which then can be optimized. > > Please test carefully and report any anomalies you find. > > I haven't found any anomalies. :-) Excellent. Then please commit this one. I will try to improve upon this. Cheers, Johannes > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Feb. 29, 2008

[patch] add ctrl-f shortcut for findText

by jcid＠dillo.org

On Thu, Feb 28, 2008 at 10:46:40PM +0100, Johannes Hofmann wrote: > Hi, > > patch below adds ctrl-f shortcut for findText. > BTW, shouldn't ctrl-b open the bookmarks page as it did > in dillo1? Yes, both shortcuts committed. -- Cheers Jorge.-

Feb. 29, 2008

[patch] redraw optimization now including tables

by jcid＠dillo.org

Hi Johannes, On Wed, Feb 27, 2008 at 05:56:36PM +0100, Johannes Hofmann wrote: > Hello, > > below is an improved version of the redraw optimization. It now also > covers table based pages - at least to some point. Yes, in fact it avoids redraws on the test posted in my last email. If I give that test another page, e.g. www.gnu-darwin.org/update.html, it can also avoid _some_ redraws. So the partial optimization seems to be working. > The challenge is to make the already commited optimization work > recursively. Do you want me to commit this new patch, or to keep the already committed one? > 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. AFAIU textblock draws by lines and as the first line is a huge table it requests a redraw of it. I don't know yet why textblock is requesting a redraw; I assume that as the table size changed, textblock gets notified and as it doesn't know better it asks the child widgets for a full redraw. From a distance it looks like a conditionalRedraw() may be the needed call (I don't know well what expose means). I mean if this conditional redraw sees that nothing has changed in the specified area, it can simply return, otherwise redraw. > The redrawing is left > to the Table-code, which then can be optimized. > Please test carefully and report any anomalies you find. I haven't found any anomalies. :-) -- Cheers Jorge.-

Feb. 29, 2008

[patch] add ctrl-f shortcut for findText

by Johannes.Hofmann＠gmx.de

Hi, patch below adds ctrl-f shortcut for findText. BTW, shouldn't ctrl-b open the bookmarks page as it did in dillo1? Cheers, Johannes diff -r 44838cc1f38d src/ui.cc --- a/src/ui.cc Sun Feb 24 23:15:53 2008 +0100 +++ b/src/ui.cc Thu Feb 28 22:43:22 2008 +0100 @@ -702,7 +702,10 @@ int UI::handle(int event) // Handle these shortcuts here. if (event == SHORTCUT) { if (event_state(CTRL)) { - if (k == 'l') { + if (k == 'f') { + a_UIcmd_findtext_dialog((BrowserWindow*) user_data ()); + ret = 1; + } else if (k == 'l') { a_UIcmd_open_url_dialog(user_data()); ret = 1; } else if (k == 'n') {

Feb. 28, 2008

[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