On Wed, 17 Oct 2007, Franz Korntner wrote:
I'm not sure if this is a private reply or if it gets posted on the
mailinglist.
Private -- I've forwarded your message. You probably want the "reply all"
option in your mail client.
I currently don't have time to look at your patch (it'll probably be next
week when I get time), but 10000 lines is most likely too big to evaluate
in one go. Is there any possibility that you could break it up into more
manageable chunks?
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.
Ok.
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.
This is one for Richard. The tree stuff is mostly black magic from my
perspective ;)
- 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.
James -- have you any comments here?
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.
Ok. That may be feasible. The only immediate issue I can see is that they
may get out of sync.
I'm not sure I understand this. Are you saying that a standalone DOM
component is a good thing or not? Note that a standalone HTML parser and
core DOM implementation is likely to be smaller than a binary of libxml.
Note that both the HTML parser and DOM implementation will be standalone
libraries.
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.
Right. My current plan involves a document language agnostic DOM
implementation with appropriate parser backends (as separate components,
if desired). The vast majority of DOM Level 3 Core is implemented (give or
take implementation bugs). Note that the underlying tree representation is
mostly irrelevant -- implementing the APIs is far more crucial.
If I have time to spare, I prefer to get netsurf though css compliancy
testing.
Ok. That mostly integrates well with our planning -- namely adding dynamic
document support to the layout engine prior to JavaScript work (the DOM is
mostly orthogonal to the layout tree).
John.
