Hi Everyone! 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. +--------------------------------------------------------------------------- -----\ | | v | [Fetch] --> [Box Conversion] --> [Box Tree] --> [Browser Window] --> [Rendering] | | | | v v | [Frame Data Extraction] - - - - - - - ->[Frame Creation]-------------------/ 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 manner. 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 yourself... 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 stylesheet etc 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/ tricky. 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.) Feedback? ========= 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 watery rubbish... R.