(I've read through the mail, and given the patch a brief gander. Here is the reply I sent to Franz. Please excuse any errors in clarifying our policy on some matters - I've never been clear on them myself.)
On Sun, 2007-10-14 at 14:16 +0200, Franz Korntner wrote: > Hi, Hi there. I've forwarded your email onto the developer's mailing list, but I thought I should just acknowledge the receipt of it, and point a few things out. > The process mainly > involves checking type hinting, prototyping, scoping, const usage, > signedness, use of floatingpoint and the c89 standard. NetSurf is written in C99, no C89. I notice your patch includes casting void *s to other pointer types - this isn't necessary, and just comlicates the code. The casts of ints etc is something I've been planning on doing for some time - good work there. (The issue is almost all the chars etc on RISC OS are of the same signedness, but under UNIX they tend not to be, so you get a great deal more warnings.) > I would hereby like to contribute the applied changes. I have also > included automake/autoconf templates. However as I am developing under > linux and have no access to riscos, I am not sure about the > desirability. To enable autoconf/automake, just issue the commands > 'automake -c -a --foreign; autoconf'. Otherwise just drop configure.ac, > aclocal.m4 and all the Makefile.am. Autoconf/automake/libtool will never make it into the official version. Almost all of the developers are extremely against it. Also, NetSurf builds on most UNIXes out of the box assuming the dependencies are installed. If it doesn't, there's a bug that needs fixing, not autoconf adding. > The patch also contains many casts to int. This is because the source > are floats and the operation causes loss of precision. I sometimes get > the impression that the effect might cascade (especially when scaling) > and I feel that it might be wiser to use floats throughout the whole > renderer and convert to ints in the backend. This not only maximizes > precision, but will most likely run faster. I'm not entirely sure why we mix things here. We use floats where we actually want them, but due to NetSurf's native platform almost always lacking an FPU, we've historically avoided using them everywhere. > I also very strongly suggest that you include copies of the generated > files css/parser.c css/parser.h css/scanner.c in the distribution. It > relaxes the need to install lemon and re2c. The templates rarely change > and most people just compile and run without wanting a full development > environment. We've considered this. It feels unclean. Certainly, lemon and re2c are packaged in most distributions. The obvious counter-example to this is Red Hat, which doesn't ship Lemon, either separately or with SQLite. A friend in Red Hat is sorting this out as we speak. I don't see any advantage of including them, given the list of build dependencies are clearly stated, and you're going to have to fetch some things anyway as they're not all that widely-used. > I needed to rename css/css_enums css_enum.enum for makefile dependency > reasons. Hope you don't mind. Can you clarify? > Finally... I might just be tempted to get a javascript engine running. > But i'm not sure whether to use spidermonkey or ecmascript. Both have > pro's and con's and besides, I still need a better 'feeling' on how > changes to css/xml propagate through the system. I'm easier tempted to > pass certain validations such as acid2 and the complexspiral (perhaps > even more) as rendering of certain sites has things left desired. The current layout engine cannot cope with the document changing. There's also no DOM support to speak of. John Mark Bell has recently been writing a new HTML parser and a DOM library that should hopefully be complete with a few months. That would make JavaScript somewhat easier. We've looked at several JavaScript libraries in the past. The choices are narrow when you have the requirements that it be linkable to C, compilable on RISC OS, and have a GPL2-compatible licence. Performance is also an issue: Many users of NetSurf use it on machines with CPUs less than 500MHz, and with no FPU. I've looked into using Lua, which is a very very fast interpreter and language which is also lightweight. Many of JavaScript's features can be easily mapped onto Lua, but I've not examined the possibility in any depth. Thanks again for your patch. Alas, it's not my decision if any of it should go in, but I have forwarded it for the perusal of the other developers. You can expect a reply from them. You might want to join the developer's mailing list and continue the discussion there - there's a link from our website (http://www.netsurf-browser.org/) B.
