- Dillo-dev - lists.mailman3.com

form.cc: select and option classes

by jcid＠dillo.org

On Tue, Jun 10, 2008 at 03:27:11PM +0100, Jeremy Henty wrote: > > Two patches here. > > The first patch turns DilloHtmlSelect and DilloHtmlOption into classes > and implements their constructors and destructors. It also makes > DilloHtmlInput::DilloHtmlInput() responsible for creating the select > object if necessary (as determined by examining the input type) and > removes the select argumentfrom DilloHtmlInput::DilloHtmlInput() and > DilloHtmlForm::addInput() . Committed. > The second patch is a small followup that simplifies select handling > elsewhere: instead of checking the input type we check if the input's > select is non-NULL. Not committed. The canonical way is more orthogonal. -- Cheers Jorge.-

June 10, 2008

form.cc: select and option classes

by onepoint＠starurchin.org

Two patches here. The first patch turns DilloHtmlSelect and DilloHtmlOption into classes and implements their constructors and destructors. It also makes DilloHtmlInput::DilloHtmlInput() responsible for creating the select object if necessary (as determined by examining the input type) and removes the select argumentfrom DilloHtmlInput::DilloHtmlInput() and DilloHtmlForm::addInput() . The second patch is a small followup that simplifies select handling elsewhere: instead of checking the input type we check if the input's select is non-NULL. Regards, Jeremy Henty

June 10, 2008

form.cc: private form methods

by jcid＠dillo.org

On Mon, Jun 09, 2008 at 04:14:21PM +0100, Jeremy Henty wrote: > > More C++-ification of form.cc . Most of the static functions > implement the internals of DilloHtmlForm::buildQueryUrl() , so let's > turn them into private DilloHtmlForm methods since nothing else calls > them. > > The first patch makes the changes, the second moves the definitions > around (the diff is a little mangled for some reason but it really > does nothing except move things). Committed. -- Cheers Jorge.-

June 9, 2008

form.cc: private form methods

by onepoint＠starurchin.org

More C++-ification of form.cc . Most of the static functions implement the internals of DilloHtmlForm::buildQueryUrl() , so let's turn them into private DilloHtmlForm methods since nothing else calls them. The first patch makes the changes, the second moves the definitions around (the diff is a little mangled for some reason but it really does nothing except move things). Regards, Jeremy Henty

June 9, 2008

Splitting html.cc: what next?

by onepoint＠starurchin.org

On Sun, Jun 08, 2008 at 08:26:37PM +0000, corvid wrote: > Sebastian was once thinking of splitting "general parsing and > tokenizing" from "handling HTML specific stuff" in html.c I see splitting out form.cc , table.cc etc. as a step-by-step way of achieving that. The general parsing and tokenizing code would stay in html.cc , and html_common.h would become the generic parser interface. > Are you planning to do more with form.cc, or are you done with it > for now? There's quite a lot of cleaning up and refactoring of to form.cc still to do. I put it on hold and began splitting html.cc because I was getting bored and felt like a change. None of the form.cc work is urgent so I'd be happy to keep it on hold if others want to work on it without being disrupted. There's plenty other things to work on. Regards, Jeremy Henty

June 8, 2008

Splitting html.cc: what next?

by corvid＠lavabit.com

Sebastian was once thinking of splitting "general parsing and tokenizing" from "handling HTML specific stuff" in html.c (http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-June/000758.html) Whether that didn't turn out well or he got distracted by other things, I don't know... Are you planning to do more with form.cc, or are you done with it for now?

June 8, 2008

Splitting html.cc: what next?

by onepoint＠starurchin.org

Off the top of my head, some suggestions for more files that could usefully be split out from html.cc: - table.cc , handles <table> , <tr> , <td> , <th> - list.cc , handles <ul> , <ol> , <li> , <dl> , <dt> , <dd> - text.cc , handles , , , , <strike> - paragraph.cc , handles , <blockquote> , <center> , <address> - page.cc , handles <html> , <head> , <title> , <meta> , <body> Thoughts? Regards, Jeremy Henty

June 8, 2008

form.cc: make Html_get_input_values a method

by jcid＠dillo.org

On Sun, Jun 08, 2008 at 06:16:45PM +0100, Jeremy Henty wrote: > > Changes Html_get_input_values() to DilloHtmlInput::getInputValues() . > The first patch makes the change, the second moves the definition to > the right place in the file. Committed. -- Cheers Jorge.-

June 8, 2008

form.cc: make Html_get_input_values a method

by onepoint＠starurchin.org

Changes Html_get_input_values() to DilloHtmlInput::getInputValues() . The first patch makes the change, the second moves the definition to the right place in the file. Regards, Jeremy Henty

June 8, 2008

another segfault

by Johannes.Hofmann＠gmx.de

On Sun, Jun 08, 2008 at 11:36:57AM -0400, Jorge Arellano Cid wrote: > On Sun, Jun 08, 2008 at 08:55:52AM +0200, Johannes Hofmann wrote: > > On Sat, Jun 07, 2008 at 06:49:22PM -0400, Jorge Arellano Cid wrote: > > > On Sat, Jun 07, 2008 at 02:24:09PM +0000, corvid wrote: > > > > Johannes wrote: > > > > > now I've got some more info on that problem. The buffer on which > > > > > Html_write_raw is operating (0x285c8000 in this case) is free'd by > > > > > a_Cache_set_content_type(). I don't understand the details though. > > > > > Do you have an idea? > > > > > > > > Ah! Does this help? > > > > > > > > > > > --- dillo2/src/html.cc 2008-06-05 14:06:50.000000000 +0000 > > > > +++ dillo2-cur/src/html.cc 2008-06-07 14:16:37.000000000 +0000 > > > > @@ -5449,6 +5449,9 @@ static void Html_process_tag(DilloHtml * > > > > /* Call the open function for this tag */ > > > > Tags[ni].open (html, tag, tagsize); > > > > > > > > + if (html->stop_parser) > > > > + return; > > > > + > > > > /* Now parse attributes that can appear on any tag */ > > > > if (tagsize >= 8 && /* length of "<t id=i>" */ > > > > (attrbuf = Html_get_attr2(html, tag, tagsize, "id", > > > > > > > > > I tried to simplify the code by avoiding a return point in the middle of > > > the function. It took long to figure a way! > > > > > > Please test the patch in CVS. > > > > Are you sure it's in CVS? Current CVS still shows the bug. > > Yes. > > If you have a switch statement in Html_process_tag(), that's it. > Now I've got it. Works fine. For some reason I got this change only now from CVS. Thanks, Johannes

June 8, 2008