- Dillo-dev - lists.mailman3.com

dillo-3.0 is on site for testing!

by jcid＠dillo.org

Hi there, After a long list of fixes and features: [ok] moveToWidget(). Jorge has code for this. [ok] downloads dpi string escaping. [ok] alt text wrapping (which looks like a nice feature). [ok] remove large panel. [ok] https dialog storm (BUG#868). [ok] The findbar input doesn't know about Ctrl+{a,e,d,k}. [ok] something other than "ctab%d" for initial tab label. [ok] single close tab button with tooltip. [ok] valgrind logs: close window [ok] valgrind logs: cancel expected url [ok] segfault with Ctrl-s (web search) [ok] UI_TEMPORARILY_SHOW_PANELS [ok] leave link into a native FLTK widget [ok] remove pointeronlink(), panelmode_cb_i() [ok] the panel problems when resizing from very small. [ok] resize problems when tabs overflow [ok] URL_ILLEGAL_CHARS [ok] Fixed CustLightButton "light" color deactivation. [ok] hoverTooltip glitch (tooltip linger when going into a child DIV). [ok] tab overflow (code a handler) [ok] valgrind error for first tab close, then resize(). [ok] update the Changelog [ok] update links in splash page [ok] default search engine [ok] new-tab and window title [ok] CSS adjacent sibling selectors [ok] margin-bottom + some margin collapse [ok] fix doctree leak [ok] first click on a link missed after middle-click on a scrollbar [ok] Fix redraw loops and reenable limit_text_width dillorc option dillo-3.0 is available from: http://www.dillo.org/download/ This should be our last release candidate, unless something major appears. Please download, build, test and report how it goes. If there's no show stopper in a couple of days, the announcement to the outside world will be made. ;) -- Cheers Jorge.-

Sept. 6, 2011

dillo_port1.3 only opens so many tabs, then stops opening more tabs

by rogerx.oss＠gmail.com

> On Tue, Sep 06, 2011 at 12:21:18PM -0800, Roger wrote: >I just noticed, pulling a git/svn/cvs copy yesterday, I can only open so many >tabs (screen/display width?) and then Dill will stop opening new tabs after a >link is clicked to open in a new tab. > >The only thing printed within the startx stdout is >"Nav_open_url:(include_clicked_url_here) and no other activity such as >"a_Nav_expect_done: repush!" or "[cookies dpi]:" etc... Well, looks like in the above paragraph, I insinuated Dillo as not loading pages at all, but looks like it was loading from cache instead. Right now, I do see the other tabs after closing some of the tabs. Seems the tabs are falling off the edge of the display and there's no way of knowing there's additional tabs as Dillo/FLTK doesn't resize the tab buttons? -- Roger http://rogerx.freeshell.org/

Sept. 6, 2011

dillo_port1.3 only opens so many tabs, then stops opening more tabs

by rogerx.oss＠gmail.com

I just noticed, pulling a git/svn/cvs copy yesterday, I can only open so many tabs (screen/display width?) and then Dill will stop opening new tabs after a link is clicked to open in a new tab. The only thing printed within the startx stdout is "Nav_open_url:(include_clicked_url_here) and no other activity such as "a_Nav_expect_done: repush!" or "[cookies dpi]:" etc... -- Roger http://rogerx.freeshell.org/

Sept. 6, 2011

page that redraws endlessly

by Johannes.Hofmann＠gmx.de

On Tue, Sep 06, 2011 at 10:20:38AM -0300, Jorge Arellano Cid wrote: > On Mon, Sep 05, 2011 at 09:39:57PM +0200, Johannes Hofmann wrote: > > On Mon, Sep 05, 2011 at 12:41:55PM -0300, Jorge Arellano Cid wrote: > > > On Mon, Sep 05, 2011 at 12:11:24AM +0200, Johannes Hofmann wrote: > > > > > [...] > > > I don't know this part of the code well enough to say whether it > > > is safe to commit before the release or not. > > > > Actually I would suggest to commit attached patch. > > I have to admit that I'm not 100% sure about the ui.cc change, but > > it seems better than just always passing true or false. > > AFAIS, it looks more correct. > > > The form.cc part makes sense, as limitTextWidth in > > textblock.cc seems to matter only if layout->getUsesViewport () > > returns true, which is not the case for FltkFlatView in the > > FltkComplexButton case. > > > > corvid, Jorge, what do you think? > > It works in the testcases (even outside forms), so I'd commit > an release with it. > > > > > > > FWIW, WRT complexity, if you resize the window with the patch, > > > over the testcase, it is quite clear that the last phrase is not > > > measured right. > > > > Yes, there is an issue, but I don't think it's related to the > > ComplexButton stuff. > > Sure, it's related to whitespace handling in the textblock, > which needs a full review. > > > > <table> > > <tr> > > <td> > > <hr/> > > <div> > > words words words words words words words words words words words > > words words words words words words words words words words words > > words words words words words words words words words words words > > words words words words words words words words words words words > > <span style="white-space:nowrap">And words in a span</span> > > </div> > > </td> > > </table> > > > > looks similarily weird here, or am I missing something? > > I'm using an even simpler testcase: > > <table> > <tr> > <td> > words words words words words words words words words words words > words words words words words words words words words words words > <span style="white-space:nowrap">And words in a span</span> > <button></button> > </td> > </table> > > > BTW, with regard to the patch, I'd keep the comment in the code, > something like: > > > + /* BUG: should be "Textblock (prefs.limit_text_width);", > > - * It caused 100% CPU usage with <button> or <input type="image"> > > + * long ago and needs a review before re-enabling it. */ > > - page = new Textblock (prefs.limit_text_width); > > + page = new Textblock (false); > > page->setStyle (html->styleEngine->backgroundStyle ()); > > Committed with slightly different wording in the comment, as I don't think using prefs.limit_text_width is correct in this case. Cheers, Johannes

Sept. 6, 2011

Query dpid or running dillos

by Johannes.Hofmann＠gmx.de

On Tue, Sep 06, 2011 at 12:55:57PM -0400, Dennis Nezic wrote: > Is there a way to query dillo (or dpid?) for the links it currently > has open? (dpidc/dillo don't seem to have such an option :p) Not quite sure what you mean. Are you interested in all URLs a dillo process is currently displaying in all it's windows or tabs? > > "dillo --xid XID" is able to access a specific window... but I guess > there is no way to currently read that "property" (link). Hm, the --xid option is used to embed a dillo window into another one. This needs a program that knows how to do that. We implemented it for use with the claws mail program and I also tested it with tabbed (http://tools.suckless.org/tabbed) In which context are you using the --xid option? > > (Oh, speaking of which, the "--xid XID" feature is buggy here ... it > loads the link, but renders with a wide (200pixel-ish?) margin on the > left, which doesn't match the actual clickable button/link-areas on the > page. Dillo version 2.2.1, fltk-1.3.0.) Again, in which context are you using the --xid option? Cheers, Johannes

Sept. 6, 2011

Query dpid or running dillos

by dennisn＠dennisn.dyndns.org

Is there a way to query dillo (or dpid?) for the links it currently has open? (dpidc/dillo don't seem to have such an option :p) "dillo --xid XID" is able to access a specific window... but I guess there is no way to currently read that "property" (link). (Oh, speaking of which, the "--xid XID" feature is buggy here ... it loads the link, but renders with a wide (200pixel-ish?) margin on the left, which doesn't match the actual clickable button/link-areas on the page. Dillo version 2.2.1, fltk-1.3.0.)

Sept. 6, 2011

page that redraws endlessly

by jcid＠dillo.org

On Mon, Sep 05, 2011 at 09:39:57PM +0200, Johannes Hofmann wrote: > On Mon, Sep 05, 2011 at 12:41:55PM -0300, Jorge Arellano Cid wrote: > > On Mon, Sep 05, 2011 at 12:11:24AM +0200, Johannes Hofmann wrote: > > [...] > > I don't know this part of the code well enough to say whether it > > is safe to commit before the release or not. > > Actually I would suggest to commit attached patch. > I have to admit that I'm not 100% sure about the ui.cc change, but > it seems better than just always passing true or false. AFAIS, it looks more correct. > The form.cc part makes sense, as limitTextWidth in > textblock.cc seems to matter only if layout->getUsesViewport () > returns true, which is not the case for FltkFlatView in the > FltkComplexButton case. > > corvid, Jorge, what do you think? It works in the testcases (even outside forms), so I'd commit an release with it. > > > > FWIW, WRT complexity, if you resize the window with the patch, > > over the testcase, it is quite clear that the last phrase is not > > measured right. > > Yes, there is an issue, but I don't think it's related to the > ComplexButton stuff. Sure, it's related to whitespace handling in the textblock, which needs a full review. > <table> > <tr> > <td> > <hr/> > <div> > words words words words words words words words words words words > words words words words words words words words words words words > words words words words words words words words words words words > words words words words words words words words words words words > <span style="white-space:nowrap">And words in a span</span> > </div> > </td> > </table> > > looks similarily weird here, or am I missing something? I'm using an even simpler testcase: <table> <tr> <td> words words words words words words words words words words words words words words words words words words words words words words <span style="white-space:nowrap">And words in a span</span> <button></button> </td> </table> BTW, with regard to the patch, I'd keep the comment in the code, something like: > + /* BUG: should be "Textblock (prefs.limit_text_width);", > - * It caused 100% CPU usage with <button> or <input type="image"> > + * long ago and needs a review before re-enabling it. */ > - page = new Textblock (prefs.limit_text_width); > + page = new Textblock (false); > page->setStyle (html->styleEngine->backgroundStyle ()); > -- Cheers Jorge.-

Sept. 6, 2011

page that redraws endlessly

by Johannes.Hofmann＠gmx.de

On Mon, Sep 05, 2011 at 12:41:55PM -0300, Jorge Arellano Cid wrote: > On Mon, Sep 05, 2011 at 12:11:24AM +0200, Johannes Hofmann wrote: > > On Sun, Sep 04, 2011 at 10:51:10PM +0200, Johannes Hofmann wrote: > > > On Sun, Sep 04, 2011 at 10:05:22PM +0200, Johannes Hofmann wrote: > > > > On Sun, Sep 04, 2011 at 07:15:09PM +0000, corvid wrote: > > > > > Johannes wrote: > > > > > > Thanks for the cleaned up test case. It's still remarkably complex. > > > > > > I see the issue also with dillo-2.1.1. Nevertheless we should > > > > > > definately try to fix it. I will play with it a bit... > > > > > > > > > > I wonder whether it is just the limit_text_width button problem dressed > > > > > up in more complex clothing. > > > > > > > > As funny as it sounds, hg bisect says it's rev 6a892184d498 where it > > > > starts the redraw loop! > > > > And indeed, if I do > > > > > > > > --- a/src/prefsparser.cc Sat Sep 03 01:15:33 2011 +0000 > > > > +++ b/src/prefsparser.cc Sun Sep 04 22:04:18 2011 +0200 > > > > @@ -219,10 +219,11 @@ > > > > setlocale(LC_NUMERIC, oldLocale); > > > > dFree(oldLocale); > > > > > > > > - > > > > +#if 0 > > > > if (prefs.limit_text_width) { > > > > /* BUG: causes 100% CPU usage with <button> or <input type="image"> */ > > > > MSG_WARN("Disabling limit_text_width preference (currently broken).\n"); > > > > prefs.limit_text_width = FALSE; > > > > } > > > > +#endif > > > > } > > > > > > > > it loops with limit_text_width=NO and doesn't with limit_text_width=YES. > > > > > > Ah wait! With limit_text_width=YES it's just not flickering. CPU is > > > still at 100%. > > > > > > The following test patch seems to stop it: > > > > --- a/dw/ui.cc Sat Sep 03 01:15:33 2011 +0000 > > +++ b/dw/ui.cc Mon Sep 05 00:09:33 2011 +0200 > > @@ -268,7 +268,7 @@ > > /** > > * \todo The argument to queueResize is not always true. (But this works.) > > */ > > - resource->queueResize (true); > > + resource->queueResize (false); > > } > > > > Maybe the comment isn't always right? > > Good shot! > > It also serves for another testcase I found. > > I don't know this part of the code well enough to say whether it > is safe to commit before the release or not. Actually I would suggest to commit attached patch. I have to admit that I'm not 100% sure about the ui.cc change, but it seems better than just always passing true or false. The form.cc part makes sense, as limitTextWidth in textblock.cc seems to matter only if layout->getUsesViewport () returns true, which is not the case for FltkFlatView in the FltkComplexButton case. corvid, Jorge, what do you think? > > FWIW, WRT complexity, if you resize the window with the patch, > over the testcase, it is quite clear that the last phrase is not > measured right. Yes, there is an issue, but I don't think it's related to the ComplexButton stuff. <table> <tr> <td> <hr/> <div> words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words <span style="white-space:nowrap">And words in a span</span> </div> </td> </table> looks similarily weird here, or am I missing something? Cheers, Johannes

Sept. 5, 2011

page that redraws endlessly

by jcid＠dillo.org

On Mon, Sep 05, 2011 at 12:11:24AM +0200, Johannes Hofmann wrote: > On Sun, Sep 04, 2011 at 10:51:10PM +0200, Johannes Hofmann wrote: > > On Sun, Sep 04, 2011 at 10:05:22PM +0200, Johannes Hofmann wrote: > > > On Sun, Sep 04, 2011 at 07:15:09PM +0000, corvid wrote: > > > > Johannes wrote: > > > > > Thanks for the cleaned up test case. It's still remarkably complex. > > > > > I see the issue also with dillo-2.1.1. Nevertheless we should > > > > > definately try to fix it. I will play with it a bit... > > > > > > > > I wonder whether it is just the limit_text_width button problem dressed > > > > up in more complex clothing. > > > > > > As funny as it sounds, hg bisect says it's rev 6a892184d498 where it > > > starts the redraw loop! > > > And indeed, if I do > > > > > > --- a/src/prefsparser.cc Sat Sep 03 01:15:33 2011 +0000 > > > +++ b/src/prefsparser.cc Sun Sep 04 22:04:18 2011 +0200 > > > @@ -219,10 +219,11 @@ > > > setlocale(LC_NUMERIC, oldLocale); > > > dFree(oldLocale); > > > > > > - > > > +#if 0 > > > if (prefs.limit_text_width) { > > > /* BUG: causes 100% CPU usage with <button> or <input type="image"> */ > > > MSG_WARN("Disabling limit_text_width preference (currently broken).\n"); > > > prefs.limit_text_width = FALSE; > > > } > > > +#endif > > > } > > > > > > it loops with limit_text_width=NO and doesn't with limit_text_width=YES. > > > > Ah wait! With limit_text_width=YES it's just not flickering. CPU is > > still at 100%. > > > The following test patch seems to stop it: > > --- a/dw/ui.cc Sat Sep 03 01:15:33 2011 +0000 > +++ b/dw/ui.cc Mon Sep 05 00:09:33 2011 +0200 > @@ -268,7 +268,7 @@ > /** > * \todo The argument to queueResize is not always true. (But this works.) > */ > - resource->queueResize (true); > + resource->queueResize (false); > } > > Maybe the comment isn't always right? Good shot! It also serves for another testcase I found. I don't know this part of the code well enough to say whether it is safe to commit before the release or not. FWIW, WRT complexity, if you resize the window with the patch, over the testcase, it is quite clear that the last phrase is not measured right. -- Cheers Jorge.-

Sept. 5, 2011

page that redraws endlessly

by jcid＠dillo.org

On Sun, Sep 04, 2011 at 09:00:27PM +0200, Johannes Hofmann wrote: > Thanks for the cleaned up test case. It's still remarkably complex. > I see the issue also with dillo-2.1.1. Nevertheless we should > definately try to fix it. I will play with it a bit... After a short review, it looks non-trivial to me. It involves white space handling, which has a design review pending, and also there's this comment in textblock.cc: /* NOTE: Most code relies on that all values of nowrap are equal for all * words within one line. */ And effectively, the 'nowrap' value is taken from the first word of the line: ws = words->getRef(line->firstWord)->style->whiteSpace; nowrap = ws == core::style::WHITE_SPACE_PRE || ws == core::style::WHITE_SPACE_NOWRAP; Given this is a design issue from long ago (dillo-2.2.1 also has it), and all the testing/debugging such a change requires, I'm for leaving this task for the next release. -- Cheers Jorge.-

Sept. 5, 2011