We've discussed several times on IRC that it would be good to get a
domain name and move all the NetSurf stuff to it.
At the moment we have things on various domains:
semichrome.netsourceforge.netvlists.pepperfish.netSourceforge.net has had reliability problems and their bug tracker is
slow and cumbersome, so it may be worth hosting the project
The ideal domain netsurf.org is taken and netsurf.org.uk is generally
There are two things to decide:
1. Whether we need to get a domain at all
2. What the domain should be if we want one
We could consider renaming NetSurf before 1.0 or we could have a team
name and use netsurf.teamname.org.
Michael Drake (tlsa)
My proposed patch to make the messages file handling using the new
reusable hash table stuff. If people are happy for this to go in, I'll
check it in.
To remind people - I've done this so that we can use message file
handling elsewhere - perhaps for storing the metadata for the new theme
format, and so we can have a single simple hash table implementation
rather than many. Could the CSS code use this hash table, or are its
need more specialist?
Some of the recent bugs are due to Font_FindFont in rufl_width failing.
This causes an assert in the layout code.
The log attached to 1541899 has some clues. The error is:
rufl_paint.c rufl_process_span 355: xfont_find_font: 0x218: \F field not
present in font string
riscos/font.c nsfont_width 259: rufl_width: rufl_FONT_MANAGER_ERROR:
0x218: \F field not present in font string
The dump of rufl data shows that the font name for Trinity.Medium is
corrupted (to an empty string):
0 - -
1 - -
2 - -
3 - -
4 "" "Trinity.Medium.Italic"
5 - -
6 "Trinity.Bold" "Trinity.Bold.Italic"
7 - -
8 - -
I still don't know what's causing this.
> Author: dsilvers
> Date: Wed Aug 9 16:07:28 2006
> New Revision: 2825
> URL: http://svn.semichrome.net?rev=2825&view=rev
> Revert depend change from 2824
It's ok the check in an updated depend file occasionally. It's just there
for people building on RISC OS who can't generate it.
As most of you know, I've been updating the relevant chunks of NetSurf to
allow for a more pleasing frame implemtation using the native window
manager. The basics are complete, but there are still quite a few issues and
suchlike that need to be resolved before it gets anywhere near SVN.
First of all I best explain how things have changed internally. Set your
typeface to fixed width and prepare for some really badly drawn diagrams.
How we now handle <frameset>, <frame> and <iframe>
The diagram below shows the basic manner in which we extract and then later
create the frame when the window is opened, ie when we have a browser_window
to attach the information to.
[Fetch] --> [Box Conversion] --> [Box Tree] --> [Browser Window] -->
[Frame Data Extraction] - - - - - - - ->[Frame
The actual parsing code is much the same as previously except I've added in
parsing of various extra flags that I intend to support (no_resize,
frameborder, border, bordercolor, marginwidth, marginheight.) For IFrames
this also means storing the owning box so that the frame can be positioned
correctly on a reflow -- this is currently not done for a frameset, but this
will eventually be necessary as we could have an <object> pointing to a
frameset (I can't see any real difficulty in doing this.)
The frame name (for targetting) is attached to the browser_window, as are
the parent, children (<frame> withing a <frameset>) and inline frames. One
benefit here is that it allows us to perform targetting exclusively in
browser_* which simplifies things.
Things that have been changed to achieve this
There's actually very little code change that's happened because this code
required it. There are a few notable changes that may benefit other pieces
of code though so I'll briefly mention them here.
* The RISC OS GUI window can be styled a lot more. Everything is read from
the browser_window so this should mean NSGTK can be updated fairly simply.
It also means that if we ever need to make NS run as a plugin to an e-mail
app or suchlike then we have the relevant code already in place.
* Content is layed out again on width and height changes. This fixes
various issues, including background images not extending the full height
until a horizontal resize and the extent being too great in a similar
Things that are currently a bit pants
It's quite obvious that iframes need more work, and by more work I mean
actually properly looking at. The main thing I really really hate is the
fact they get loaded twice (once into the parent tree and once as a child
window.) I'm not entirely sure how to achieve this, so some comments on this
area would really be very helpful.
Frame resizing isn't implemented at all. I got as far as adding a ptr_lr
icon before realising that the w3c spec says pretty much nothing about how
it should work. Given a grid of things specified in relative, percentage and
pixel values, how do you modify the dimensions of the pair? There are 6
basic size pairings, which I think should probably be updated such that:
RELATIVE, RELATIVE *, * => 1.1*, 0.9*
RELATIVE, PIXEL *,200 => *,250
RELATIVE, PERCENT *, 50% => *, 60%
PIXEL, PIXEL 200,200 => 150, 250
PIXEL, PERCENT 200, 50% => 250, 45%
PERCENT, PERCENT 20%, 30% => 21%, 29%
If anyone else has any ideas on how things should move about then now's
probably the best time to start shouting. I'm not especially looking forward
to this code, so if you should too loudly you may get told to write it
Frame margins are read correctly and stored to the browser_window which
then fetches the content. I was thinking that we could create a stylesheet
from these and pass this with go_post so you're flow is basically:
1) Create browser window from frameset
2) Create stylesheet for margins (and possibly other CSS styles later on)
3) Call _go_post with the stylesheet
4) Stylesheet is merged with our default stylesheet and then with the page
By implementing frame margins correctly we would fix quite a few framesets
that we currently cause to have scrollbars.
Things that have got worse
The obvious thing here is history. We need to recursively store the entire
frameset details and then recreate this accordingly. I've vaguely begun this
by moving all the page data associated with a history_entry into a separate
'struct page' which can then be updated accordingly. I'm not too sure about
the best way to handle framed thumbnails though, but creating a thumbnail of
each frame and scaling them/positioning them accordingly wouldn't be /too/
Printing currently works with whichever browser_window the action was
initiated from, or the top level window for the toolbar. This actually
applies to all actions (back, forwards etc), so you can easily view the
source or suchlike from any of the frames quite easily (a Frame-> menu item
may be useful, this is definitely something for Michael to go off and be
creative at rather than me look at it as I'll just do whatever's easiest.)
I'm working away for a while, so don't expect any prompt replies (and I'm
sorry if this post is a bit rubbish and rambling I'm in the middle of a
dozen things at the moment.) There's a copy of a recent-ish version of my
new code on Rob's FTP server, so feel free to take a peek. Anyway, James now
officially owes me a beer for actually beginning to document all this stuff.
I'll wait until you're back from America though as I don't want any of that
I'd like to see NetSurf recognised by AWStats and Webalizer, etc, so I
think it's worth deciding on an UA string before we get to version
Here's my suggestion (based on previous IRC discussion):
For releases: NetSurf/Version (OS)
e.g: NetSurf/1.0 (RISC OS 5.11)
For test builds: NetSurf/test (YYYY-MM; OS)
e.g: NetSurf/test (2006-08; RISC OS 5.11)
The test build has year and month information so that it's possible to
tell if many ancient builds are still in use, but don't have a finer
resolution to prevent identification of individual users by their
Any thoughts on this?
Michael Drake (tlsa)
We talked about moving the menu_action code out of riscos/menus.c before, but
maybe we could even move this out of riscos/ completely so that the gtk build
can share it.
The idea would be to act as a central place for handling menu selections,
toolbar clicks, and keyboard shortcuts. Some of the actions would call code in
desktop/, others would call a function that would have to be implemented in both
riscos/ and gtk/.
I've updated the TODO HTML and CSS files. Can someone check over them?
The things I'm not sure about are:
Is empty-cells done?
Is table-layout done?
Is overflow complete?
Can the outline and outline-* properties be removed?
Is the disabled attribute for forms done?
Michael Drake (tlsa)