New messages implementation using utils/hashtable.c
by Rob Kendrick
Hi,
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?
B.
17 years, 3 months
Recent instability
by James Bursa
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):
7 "Trinity"
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.
http://sourceforge.net/tracker/?func=detail&aid=1541899&group_id=51719&at...
James
17 years, 3 months
Framesets, Frames and IFrames
by Richard Wilson
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.
17 years, 4 months
User agent string
by Michael Drake
Hello,
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
1.0.
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
browser string.
Any thoughts on this?
Best regards,
--
Michael Drake (tlsa)
http://www.smoothartist.com/
17 years, 4 months
Menu actions
by James Bursa
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/.
Comments?
James
17 years, 4 months
TODOs
by Michael Drake
Hi,
I've updated the TODO HTML and CSS files. Can someone check over them?
The things I'm not sure about are:
CSS
Is empty-cells done?
Is table-layout done?
Is overflow complete?
Can the outline and outline-* properties be removed?
HTML
Is the disabled attribute for forms done?
Best regards,
--
Michael Drake (tlsa)
http://www.smoothartist.com/
17 years, 4 months
