---------- Forwarded message ---------- Date: Wed, 17 Oct 2007 21:42:38 +0200 From: Franz Korntner <franz(a)digital-connectivity.com&gt; To: John-Mark Bell <jmb(a)netsurf-browser.org&gt; Subject: Re: Source scrubbing John, I'm not sure if this is a private reply or if it gets posted on the mailinglist. Nearly all patch snippets are independent. So you can slice it into chunks as large as you like. The smaller patchfile is an extract containing the cherries. The patch consists largely of adding typecasts and layout changes to fix the scope of inner enums. It also contains lots of explicit casts from float to int to mark loss of precision. At some places I uniformed signed/unsigned, int/long and const issues. Other stuff found I'll keep for later as not to make the patch too complicated. What I did bump into - Is some const nasties with regard to tree nodes. This is because the text field are sometimes populated by const strings, sometimes 'shared strings' and sometimes free()able. This make the code very complex and breaks the const attribute. I really suggest that when the node is allocated, you allocate a couple of bytes more and copy the title field into the node itself. This relaxes management and you can drop the related code and be more const strict. - The rendering coordinate system is limping on two legs (ints and floats) and it feels that it's having hidden side-effects. I also believe I found some points (in CSS) where sizes and counts are getting mixed. I am currently looking into getting these two separated. - At some places enums are being used instead of bitfields resulting in lots of warnings. - For example, in css there is the struct css_border_width, it contains css_length and the field percent. Technically is not a length, but it seems mutual-exclusive with css_length. It might seem that broadening the concept of css_length might optimize both code and storage size. No, keep the build system! What I suggest is to include the autoconf/automake templates so that they can be activated on request. The templates by themselves are harmless and do not stand in the way or interfere with the build system. I need them because of my non-standard environment. I also maintain distributions. In general it's a pain to recreate intermediate files and it's annoying if the contents is not effected by the build/hosting environment. I have even encountered massive problems reproducing older packages because the required tools were not (or difficult) reproducible. These files do not require build-time regeneration. I formulated this one really poorly as I actually meant something different. However you did answer a question I had not yet asked. I'll return on this subject later. I meant that libxml seems suitable enough for an implied DOM model. i.e. it seems overdone to maintain a DOM tree separate of libxml. I meant using libxml for the DOM. I just installed a newer version of seamonkey, guess that was echoing in my head. I haven't investigated libsee but I did look at spidermonkey and it felt good. It has a compiler, interpreter and object handling with objects you expect and hooks for DOM. I was surprised about the language capabilities. Seems that js is more mature than I imagined. I was also looking into the parser/scanner. Having separate combos for js and css seems silly. If you are looking for a lemon/re2c substitute, I don't know how well the spidermonker scanner/parser can handle css. But as I said before, this has no high priority as I expect many unexpected nasties. If I have time to spare, I prefer to get netsurf though css compliancy testing. Franz.