- Dillo-dev - lists.mailman3.com

Re: Splitting html.cc

by onepoint＠starurchin.org

OK, I'll kick this off with a small patch that wraps the DilloHtmlForm constructor and destructor in an API that doesn't need the class declaration. The next stage will be to create stubs for the new files and hook them into the existing source and build system. That depends on deciding what the new file names should be. My thoughts: The form implementation: form.cc or html_form.cc . The form header: form.hh or html_form.hh . The shared API for Html module internals: html_common.hh , html_shared.hh , html_internal.hh or html_internals.hh . Please comment! Regards, Jeremy Henty

June 2, 2008

fltk2 snapshot update

by onepoint＠starurchin.org

On Mon, Jun 02, 2008 at 08:07:45PM +0100, Jeremy Henty wrote: > On Mon, Jun 02, 2008 at 08:48:57PM +0200, Johannes Hofmann wrote: > > > > Please let me know, if that problem still exists on your test > > page. > > Unfortunately the bug had disappeared again just before I upgraded > FLTK so I can't tell if it made any difference. And after a small refactoring it's back (albeit without the unpleasant green, so I guess that's something)! When I've cleared my other ToDos I'll valgrind it. Regards, Jeremy Henty

June 2, 2008

fltk2 snapshot update

by onepoint＠starurchin.org

On Mon, Jun 02, 2008 at 08:48:57PM +0200, Johannes Hofmann wrote: > On Mon, Jun 02, 2008 at 05:24:57PM +0100, Jeremy Henty wrote: > > On Mon, Jun 02, 2008 at 04:26:55PM +0200, Johannes Hofmann wrote: > > > > > It contains a bugfix for the weird green artifacts in the > > > FileChooser. > > > > By the way, when I was refactoring the form parsing code recently > > I saw those same artifacts on my form test page. > > Please let me know, if that problem still exists on your test page. Unfortunately the bug had disappeared again just before I upgraded FLTK so I can't tell if it made any difference. I'll keep an eye out for it. When I've finished the form code split and refactoring I plan to valgrind dillo2 again. Regards, Jeremy Henty

June 2, 2008

fltk2 snapshot update

by Johannes.Hofmann＠gmx.de

On Mon, Jun 02, 2008 at 05:24:57PM +0100, Jeremy Henty wrote: > On Mon, Jun 02, 2008 at 04:26:55PM +0200, Johannes Hofmann wrote: > > > ... there is a new fltk2 snaphot (r6132) available. > > Thanks, I just upgraded. A nice change: the build now completes > successfully without X windows running (it used to build the library > but fail to build some of the apps, which was annoying). > > > It contains a bugfix for the weird green artifacts in the > > FileChooser. > > By the way, when I was refactoring the form parsing code recently I > saw those same artifacts on my form test page. They came and went as > I changed the code: sometimes they didn't appear at all, sometimes a > reload would get rid of them, sometimes I had to go back and forward > in the navigation history to get rid of them. Since I was not > touching any widget code I assumed I was triggering some sporadic bug > in Dillo or FLTK. Let's see if the new FLTK behaves any better! > This may well have been the same bug. UpBox was accessing uninitialized memory. Please let me know, if that problem still exists on your test page. Regards, Johannes

June 2, 2008

fltk2 snapshot update

by corvid＠lavabit.com

Jeremy wrote: > On Mon, Jun 02, 2008 at 04:26:55PM +0200, Johannes Hofmann wrote: > > BTW, shouldn't we point users directly to fltk.org for downloading > > fltk2? Otherwise people might think that dillo2 needs a modified > > version of fltk2. > > +1 . We shouldn't let anything discourage people from trying dillo2, > so anything that suggests they might need to patch other software is a > bad idea. Along these lines, I've been wondering whether it might be a good idea to list the required and optional libraries on the CVS page.

June 2, 2008

fltk2 snapshot update

by onepoint＠starurchin.org

On Mon, Jun 02, 2008 at 04:26:55PM +0200, Johannes Hofmann wrote: > ... there is a new fltk2 snaphot (r6132) available. Thanks, I just upgraded. A nice change: the build now completes successfully without X windows running (it used to build the library but fail to build some of the apps, which was annoying). > It contains a bugfix for the weird green artifacts in the > FileChooser. By the way, when I was refactoring the form parsing code recently I saw those same artifacts on my form test page. They came and went as I changed the code: sometimes they didn't appear at all, sometimes a reload would get rid of them, sometimes I had to go back and forward in the navigation history to get rid of them. Since I was not touching any widget code I assumed I was triggering some sporadic bug in Dillo or FLTK. Let's see if the new FLTK behaves any better! > I think we should update the download instructions. +1 > BTW, shouldn't we point users directly to fltk.org for downloading > fltk2? Otherwise people might think that dillo2 needs a modified > version of fltk2. +1 . We shouldn't let anything discourage people from trying dillo2, so anything that suggests they might need to patch other software is a bad idea. Regards, Jeremy Henty

June 2, 2008

fltk2 snapshot update

by Johannes.Hofmann＠gmx.de

Hi, at fltk.org there is a new fltk2 snaphot (r6132) available. It contains a bugfix for the weird green artifacts in the FileChooser. I think we should update the download instructions. BTW, shouldn't we point users directly to fltk.org for downloading fltk2? Otherwise people might think that dillo2 needs a modified version of fltk2. Cheers, Johannes

June 2, 2008

why is SELECT a block container in Tags[]?

by corvid＠lavabit.com

Jorge wrote: > > > On Sat, May 31, 2008 at 07:02:02PM +0000, corvid wrote: > > > > <form> > > > > <select> > > > > <font color=red>segfault</font> > > > > </select> > > > > </form> > Patch committed (funny rendering sometimes, no segfault with > the above example). Justus got that sort of segfault because he must have standard_widget_colors set.

June 2, 2008

why is SELECT a block container in Tags[]?

by jcid＠dillo.org

On Sun, Jun 01, 2008 at 08:16:49PM +0000, corvid wrote: > Jorge wrote: > > On Sat, May 31, 2008 at 07:02:02PM +0000, corvid wrote: > > > Jorge wrote: > > > > On Sat, May 31, 2008 at 03:26:50PM +0000, corvid wrote: > > > > > Why is SELECT a block container rather than an inline container in Tags[]? > > > > > > > > Most probably by mistake! > > > > > > > > Given that the DTD says: > > > > > > > > <!ELEMENT SELECT - - (OPTGROUP|OPTION)+ -- option selector --> > > > > [...] > > > > <!ELEMENT OPTGROUP - - (OPTION)+ -- option group --> > > > > [...] > > > > <!ELEMENT OPTION - O (#PCDATA) -- selectable choice --> > > > > > > > > it looks like inline container would fit better. > > > > (and stop some segfaults Justus detected). > > > > > > Well, it would still provide him with new segfaults for inline stuff like > > > > > > <form> > > > <select> > > > <font color=red>segfault</font> > > > </select> > > > </form> > > > > BTW, patch committed (now SELECT is an inline container). > > Now dillo can't deal with multiple <option>s without </option> in between, > e.g., http://www.dillo.org/bugtrack/Dquery.html Oh, yes. Patch committed (funny rendering sometimes, no segfault with the above example). It looks simpler to have SELECT as a block container, but I prefer this simple patch because it _is_ an inline container. The decision on what to do with unallowed elements is yet to be made (ignore & warn or close the open container for instance). -- Cheers Jorge.-

June 2, 2008

why is SELECT a block container in Tags[]?

by corvid＠lavabit.com

Jorge wrote: > On Sat, May 31, 2008 at 07:02:02PM +0000, corvid wrote: > > Jorge wrote: > > > On Sat, May 31, 2008 at 03:26:50PM +0000, corvid wrote: > > > > Why is SELECT a block container rather than an inline container in Tags[]? > > > > > > Most probably by mistake! > > > > > > Given that the DTD says: > > > > > > <!ELEMENT SELECT - - (OPTGROUP|OPTION)+ -- option selector --> > > > [...] > > > <!ELEMENT OPTGROUP - - (OPTION)+ -- option group --> > > > [...] > > > <!ELEMENT OPTION - O (#PCDATA) -- selectable choice --> > > > > > > it looks like inline container would fit better. > > > (and stop some segfaults Justus detected). > > > > Well, it would still provide him with new segfaults for inline stuff like > > > > <form> > > <select> > > <font color=red>segfault</font> > > </select> > > </form> > > BTW, patch committed (now SELECT is an inline container). Now dillo can't deal with multiple <option>s without </option> in between, e.g., http://www.dillo.org/bugtrack/Dquery.html

June 1, 2008