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

Splitting html.cc: common functions, part 1

by onepoint＠starurchin.org

<headslap> Here's the patch. The followup to *this* will complete the renaming. Jeremy Henty

June 5, 2008

Splitting html.cc: common functions, part 1

by onepoint＠starurchin.org

This patch moves some function declarations from html.cc to html_common.hh . It only does *some* of the renaming because the full patch breaks the list's moderation limit. I'll follow up to this message with the rest of the renaming. You may want to batch this patch and the followup together as a single commit. Please comment! Jeremy Henty

June 5, 2008

Re: Splitting html.cc

by jcid＠dillo.org

On Thu, Jun 05, 2008 at 03:48:53PM +0100, Jeremy Henty wrote: > On Thu, Jun 05, 2008 at 09:02:28AM -0400, Jorge Arellano Cid wrote: > > On Wed, Jun 04, 2008 at 03:38:38PM +0100, Jeremy Henty wrote: > > > > > The next step is to move some of the function declarations across, > > > but that depends on deciding what to do with the function names. > > > Should I rename "Html_*" to "a_Html_*"? > > > > I'd prefer to have C functions called from other sources as > > a_Html_*. > > OK, but how does that rule apply to Html_tag_{open,close}_*() ? They > aren't explicitly called anywhere, They are called by the parser from inside html.cc. > just referenced from the Tags array > in html.cc . The split will move some of them into form.cc . It > would be ugly to rename some of them but not others. If the plan is > to move most or all of them to separate files like form.cc (which I > think would be a good way to split up html.cc) then perhaps we should > rename them all to a_Html_tag_{open,close}_*() in advance? As the Html_tag_{open,close}_*() functions are closely related to the parser, I'd prefer to have them not renamed. If there's a need, these functions could call a_Form_*() functions. Something like: Html_open_form () { [...] a_Form_do_something() [...] } -- Cheers Jorge.-

June 5, 2008

Re: Splitting html.cc

by onepoint＠starurchin.org

On Thu, Jun 05, 2008 at 09:02:28AM -0400, Jorge Arellano Cid wrote: > On Wed, Jun 04, 2008 at 03:38:38PM +0100, Jeremy Henty wrote: > > > The next step is to move some of the function declarations across, > > but that depends on deciding what to do with the function names. > > Should I rename "Html_*" to "a_Html_*"? > > I'd prefer to have C functions called from other sources as > a_Html_*. OK, but how does that rule apply to Html_tag_{open,close}_*() ? They aren't explicitly called anywhere, just referenced from the Tags array in html.cc . The split will move some of them into form.cc . It would be ugly to rename some of them but not others. If the plan is to move most or all of them to separate files like form.cc (which I think would be a good way to split up html.cc) then perhaps we should rename them all to a_Html_tag_{open,close}_*() in advance? I'll submit more patches as soon as this is decided. Regards, Jeremy Henty

June 5, 2008

Re: Splitting html.cc

by jcid＠dillo.org

On Wed, Jun 04, 2008 at 03:38:38PM +0100, Jeremy Henty wrote: > > The first patch in this set creates stubs for the new files and adds > them to the build. Developers should run " make maintainer-clean ; > ./autogen.sh " after checking this out so that the new source file is > compiled. > > The other patches move some macros, typedefs, structs and class > definitions from html.cc into the new headers. Committed. > The next step is to move some of the function declarations across, but > that depends on deciding what to do with the function names. Should I > rename "Html_*" to "a_Html_*"? In other words, do functions in > form.hh count as part of the Html module API or part of its internals. > I am inclined to say they are internal and so not rename them. > Comments? I'd prefer to have C functions called from other sources as a_Html_*. -- Cheers Jorge.-

June 5, 2008

Re: Splitting html.cc

by onepoint＠starurchin.org

The first patch in this set creates stubs for the new files and adds them to the build. Developers should run " make maintainer-clean ; ./autogen.sh " after checking this out so that the new source file is compiled. The other patches move some macros, typedefs, structs and class definitions from html.cc into the new headers. The next step is to move some of the function declarations across, but that depends on deciding what to do with the function names. Should I rename "Html_*" to "a_Html_*"? In other words, do functions in form.hh count as part of the Html module API or part of its internals. I am inclined to say they are internal and so not rename them. Comments? Regards, Jeremy Henty

June 4, 2008

fltk2 snapshot update

by jcid＠dillo.org

On Mon, Jun 02, 2008 at 04:26:55PM +0200, Johannes Hofmann wrote: > 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. Done. As the latest FLTK2 has worked OK for us the last months. -- Cheers Jorge.-

June 4, 2008

Re: Splitting html.cc

by jcid＠dillo.org

On Mon, Jun 02, 2008 at 09:23:44PM +0100, Jeremy Henty wrote: > > 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. Committed. > 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 . form.cc > The form header: form.hh or html_form.hh . form.hh > The shared API for Html module internals: html_common.hh , > html_shared.hh , html_internal.hh or html_internals.hh . html_common.hh -- Cheers Jorge.-

June 4, 2008

Re: Splitting html.cc

by onepoint＠starurchin.org

D'oh, patch attached! Jeremy Henty

June 2, 2008

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