Website improvements
by James Bursa
The website is due for improvements in content, navigation, and design. I
think we should start by figuring out the aims of visitors of the site:
- a non-user who wants to know what NetSurf is and why he should get it
- a non-user who wants to install NetSurf
- a user who wants to upgrade to the latest version
- a user who wants to report a bug
- a user who wants to contribute in some way
- a user who needs help or documentation
- a webmaster who's seen NetSurf in their log and wants to know what it is
- a user or web designer who wants to know which standards NetSurf supports
- a new developer who would like to get the source and contribute
- a new developer on some device or platform who's looking for a browser to
port
- someone who wants to contact us
Any more that I've missed?
Current content of the site is:
- front page (currently summary, news, links)
- news archive
- screenshots
- downloads
- development information
- documentation
- development progress
- licence
- mailing lists links
- development plan
- themes
James
--
James Bursa, NetSurf developer http://www.netsurf-browser.org/
16 years
Fixed-point arithmetic (fwd)
by John-Mark Bell
Images at:
http://www.ecs.soton.ac.uk/~jmb202/riscos/netsurf/zoom-fixedpoint.gif
http://www.ecs.soton.ac.uk/~jmb202/riscos/netsurf/zoom-integer-floatingpo...
J.
---------- Forwarded message ----------
Date: Wed, 24 Oct 2007 02:23:01 +0200
From: Franz Korntner <franz(a)digital-connectivity.com>
To: John-Mark Bell <jmb(a)netsurf-browser.org>
Subject: Fixed-point arithmetic
Hi John,
I'm posting this one private because it has large attachments and i'm not quite
sure if submitting them will nuke the mailing list.
I've eliminated all floating-point operations from the rendering core and
replaced them with fixed point (i.e. effectively integer operations). It
revealed much in expected and unexpected areas but more of that later. For an
illustration I included 2 animated gifs of a rendered test page consisting of a
10x10 table containing 2 by 2 pixel red images wrapped in alternating
blue/black 2 pixel padding. Goal of this test is to illustrate rounding errors.
The gif animation zooms into the page 100 times.
The first attachment is with the original mixed integer/float code, the second
with fixed point arithmetic.
Franz.
16 years, 1 month
Re: Christmas/Midlands Show stand
by Rob Kendrick
On Tue, 2007-10-30 at 19:49 +0100, rickman(a)argonet.co.uk wrote:
> hi Rob
>
> thanks for your note - we are delighted that you would like to come to
> the Midlands Xmas show and will maake every effort to make it
> possible.
Thanks for inviting us.
> The position at the moment is that all the original tables are booked.
> However, we are looking at putting another four tables in the centre
> of the room. This will entail some re-shuffling as there may be no
> power supply on these tables. Fortunately some exhibitors do not need
> any mains power (eg MUG(R)) so we can move to the middle and free up a
> table with services.
While we may be using a couple of laptops, I'm not sure our batteries
will last the whole show! Certainly having mains power would be very
handy.
> Anyway, assume that we will sort something out for you.
>
> >Is there anything specific we need to do, or give you?
>
> I would advise getting to the show as early as possible on the day as
> it is likely to be tight on space and possibly a bit chaotic - this is
> a first time venue for us.
OK. We usually don't need much more than 30 or 45 minutes to set up, as
our stand is significantly less swish than many others - it mostly
consists of us, a computer, and a large NetSurf banner that we put up or
use as a tablecloth. This is also pretty small on space requirements,
although some of us aren't as small as we used to be. :)
We aim to arrive around an hour before the show opens, however.
If you need to know such things, currently we plan on three of us to
attend to represent NetSurf:
* Daniel Silverstone,
* James Shaw,
* And myself, Rob Kendrick.
> There is no charge for your table.
Thanks for the contribution! We'll see you on the day. If there is any
information you need to post to us, you can reach me at:
19, Wetherall Street,
Levenshulme,
MANCHESTER,
M19 3GE.
B.
16 years, 1 month
Christmas/Midlands Show stand
by Rob Kendrick
Hi,
John-Mark Bell tells me that you have offered the NetSurf project a
stand at your show on the 1st of December.
If it's not too late, I'd like to accept that invitation. Is there
anything specific we need to do, or give you?
Thanks.
B.
16 years, 1 month
Registration of netsurf-browser.org
by Daniel Silverstone
Hi,
I have renewed netsurf-browser.org and am hereby committing to another
year of providing service assuming it's wanted.
I have taken £10 from the kitty to cover the renewal and I'm afraid I'm
keeping the remaining seven pence to help cover the costs of hosting the
site etc :-)
Thanks,
Daniel.
--
Daniel Silverstone http://www.digital-scurf.org/
PGP mail accepted and encouraged. Key Id: 2BC8 4016 2068 7895
16 years, 1 month
SE show feedback
by John-Mark Bell
Hi,
The SE show was reasonably good. It mostly consisted of grateful
users and answering the "when JavaScript?" question.
Three bugs were reported at the show:
1) Alliance and Leicester form input display (jmason argonet.co.uk)
2) Deacon's Nursery -- doesn't render at all (graham daviesclose.co.uk)
3) Window open position -- sometimes staggers, sometimes doesn't.
(ehwild talktalk.net)
One feature request was made:
1) List of common error messages
Someone wanted to buy a CD.
Money matters:
Stand cost: (50 UKP)
Donations : 10 UKP
--------------------
Total : (40 UKP)
J.
16 years, 1 month
Re: Midlands Show (fwd)
by John-Mark Bell
---------- Forwarded message ----------
Date: Sun, 21 Oct 2007 13:18:39 +0100
From: Rob Kendrick <rjek(a)netsurf-browser.org>
To: John-Mark Bell <jmb(a)netsurf-browser.org>
Subject: Re: Midlands Show
On Sun, 2007-10-21 at 00:07 +0100, John-Mark Bell wrote:
> Hi,
>
> I've been asked if we want a stand at the Midlands show this year. The
> show is on Saturday 1st December. Further details at
> http://www.mug.riscos.org/show/. The stand will be free of charge.
>
> I'm not available to attend due to other commitments. Contact John Rickman
> (email address on the contact page of the website) if we're interested.
Myself and Daniel may be able to do this show. I'll discuss it with him
later.
> I can probably arrange for the banner to be delivered to someone if it's
> needed.
If it's a goer, you can post it to us.
B.
16 years, 1 month
Midlands Show
by John-Mark Bell
Hi,
I've been asked if we want a stand at the Midlands show this year. The
show is on Saturday 1st December. Further details at
http://www.mug.riscos.org/show/. The stand will be free of charge.
I'm not available to attend due to other commitments. Contact John Rickman
(email address on the contact page of the website) if we're interested.
I can probably arrange for the banner to be delivered to someone if it's
needed.
J.
16 years, 1 month
Re: Source scrubbing
by John-Mark Bell
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.
16 years, 1 month
Re: Source scrubbing (fwd)
by John-Mark Bell
---------- Forwarded message ----------
Date: Wed, 17 Oct 2007 21:42:38 +0200
From: Franz Korntner <franz(a)digital-connectivity.com>
To: John-Mark Bell <jmb(a)netsurf-browser.org>
Subject: Re: Source scrubbing
John,
I'm not sure if this is a private reply or if it gets posted on the
mailinglist.
> 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.
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.
> Finally I constructed autoconf/automake templates as I require certain
> functionality not delivered by the supplied makefile. I suggest you include
> these files so that package/distribution builders can choose which system to
> use.
>
> Are you suggesting that the existing build system be replaced? If so, that's
> a non-starter as it's highly unlikely that autotools will ever work on RISC
> OS.
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.
> For the same reasons I suggest you include precompiled versions of lemon/re2c
> generated files.
>
> Currently, these are available from
> http://netsurf.strcprstskrzkrk.co.uk/developer/ -- they're recreated
> automatically as needed. The CSS parser is due for a major overhaul at some
> point in the relatively near future. I currently have no idea whether this
> will have an impact on the use of lemon/re2c.
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.
>> Good to know.
>> I have a good feeling that DOM functionality can easily be injected in the
>> current HTML parser.
> The current layout engine cannot cope with the document changing.
>
> That depends; whilst libxml already produces a tree which is fairly close to
> the W3C DOM, its HTML parser is particularly non-robust to real-world web
> content. Additionally, its architecture is not suited to handling injection
> of data into the document source stream (as required by certain scripting
> methods -- namely document.write()).
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 am looking for a small footprint package and get unnervy with the
>> foresight of the introduction of a complete and/or standalone DOM component.
>> This might make things easier.
> 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.
> The two libraries I currently favour are SpiderMonkey (which is what I think
> you meant, not SeaMonkey ;) and libsee. However, JavaScript work is someway
> down the line, so a decision on this hasn't happened yet.
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.
16 years, 1 month
