Guildford show
by James Bursa
The show is in three weeks from today.
Who's planning to be there? We can set up our stand from 8:00 (doors open
10:00). It would be good to get some posters and maybe handouts. We could
even give out CDs.
James
16 years, 5 months
Re: r2940 phlamethrower - in /trunk/netsurf: depend desktop/textinput.c render/box_construct.c render/layout.c
by James Bursa
What was the change below to layout.c for? The width of the inline container
shouldn't depend on the contents, and I don't think this is correct for
right-justified or centred text.
Sorry about the delay, I only noticed this today.
James
/**
* Layout lines of text or inline boxes with floats.
*
* \param box inline container
* \param width horizontal space available
* \param cont ancestor box which defines horizontal space, for
floats
* \param cx box position relative to cont
* \param cy box position relative to cont
* \param content memory pool for any new boxes
* \return true on success, false on memory exhaustion
*/
bool layout_inline_container(struct box *inline_container, int width,
struct box *cont, int cx, int cy, struct content *content)
{
bool first_line = true;
bool has_text_children;
struct box *c, *next;
int y = 0;
+ int curwidth,maxwidth = width;
assert(inline_container->type == BOX_INLINE_CONTAINER);
LOG(("inline_container %p, width %i, cont %p, cx %i, cy %i",
inline_container, width, cont, cx, cy));
has_text_children = false;
for (c = inline_container->children; c; c = c->next)
if ((!c->object && c->text && c->length) || c->type == BOX_BR)
has_text_children = true;
-
+
+ /** \todo fix wrapping so that a box with horizontal scrollbar will
shrink back to 'width' if no word is wider than 'width' (Or just set curwidth
= width and have the multiword lines wrap to the min width) */
for (c = inline_container->children; c; ) {
LOG(("c %p", c));
- if (!layout_line(c, width, &y, cx, cy + y, cont, first_line,
+ curwidth = inline_container->width;
+ if (!layout_line(c, &curwidth, &y, cx, cy + y, cont,
first_line,
has_text_children, content, &next))
return false;
+ maxwidth = max(maxwidth,curwidth);
c = next;
first_line = false;
}
- inline_container->width = width;
+ inline_container->width = maxwidth;
inline_container->height = y;
return true;
}
16 years, 5 months
Simplistic JavaScript support?
by Rob Kendrick
I had a thought earlier: It aught to be possible to support
non-document-manipulating functionality of JavaScript reasonably easily
in NetSurf. While some of the functionality we could implement is
arguably evil, it might keep some people quite, and make some sites more
usable. He's a short list of some possibilities that should be
'reasonably' easy to implement if we embedded SpiderMonkey:
* alert(), confirm() and prompt() for bringing up message boxes
* close() for closing windows
* print() for brining up the print dialogue
* defaultStatus variable for default value of the status bar
* The Navigator objection which contains things like the user agent
(Perhaps provide the ability to lie for sites that check which
browser you're using in JavaScript)
* Any processing, callbacks, etc, that scripts in <script> tags might
want to use in combination with the above.
* All sorts of other things that don't manipulate the document object
or DOM tree.
Comments? I'll take a look at the SpiderMonkey API this afternoon if I
have a chance to see how easily these simple objects could be exposed to
NetSurf.
B.
16 years, 5 months
Netsurf acting as plugin for HTML rendering in other applications (fwd)
by John-Mark Bell
Received today. Please discuss, then someone can reply appropriately ;)
J.
---------- Forwarded message ----------
Date: Tue, 26 Sep 2006 12:42:53 +0100
From: R-Comp <rcomp(a)rcomp.demon.co.uk>
To: jmb202(a)ecs.soton.ac.uk
Subject: Netsurf acting as plugin for HTML rendering in other applications
Hi there!
I hope I'm writing to the right person regarding Netsurf.
For a long time, WXL has offered itself as a "plugin" via Acorn's
Plugin API to allow other applications to render HTML if required -
indeed, it uses the API itself to do iFrames.
At the moment, if an application wants to render HTML content, it
needs to create its own HTML renderer, which (as we both know) is a
crazy undertaking. As a result, programs like Messenger don't have
much in the way HTML email facilities.
But of course, it isn't just Messenger - I was reading today about one
of the main new features in FileMaker database on the Mac - a database
object that showed web content. Yep, you guessed it, it was basically
an embedded browser object (presumably using whatever HTML renderer is
default on OS-X). A nice feature for DataPower 3, I thought.
And it goes beyond that - with plugin-based HTML rendering
applications could offer HTML-based content (eg. config screens or
other dynamic interface objects) as needed.
Assuming the Acorn Plugin-API meets with your approval, I suspect it
wouldn't be too hard to make NetSurf act as a plugin that other apps
could call to do HTML rendering. Support for this in the main free
browser would make it far more acceptable in terms of use, as everyone
would have access to a plugin-based HTML renderer.
Any thoughts?
Andrew
PS, the other reason I think this would be a great addition to Netsurf
is that for plugin-based rendering, lack of Javascript is actually a
benefit (fewer security issues), and speed is very important - again a
Netsurf strength.
--
R-Comp
22 Robert Moffat, High Legh, Knutsford, Cheshire WA16 6PS
Tel: (+44) 01925 755043 Fax: (+44) 01925 757377
http://www.rcomp.co.uk/
16 years, 5 months
Pseudo Selectors, Generated Content and Lists
by John-Mark Bell
Hi,
As you probably know, these are the major outstanding items on the 1.0
development plan (in terms of additional features, anyhow). What follows
is my thoughts on some of this stuff, along with a number of the issues
involved in implementing these features. If anything's not clear or you
have any bright ideas as to how to go about solving some of the problems,
then please say so. Equally, if I appear to be exhibiting signs of
madness, then don't hesitate to tell me ;)
Pseudo Selectors
----------------
I've spent a little time looking at these and have a very hacky, not very
efficient, proof-of-concept implementation of the :link, :visited, :hover
and :active pseudo classes. This has highlighted a number of things:
1) Matching of pseudo selectors is a bit tricky, as it's based upon
information external to the document tree. In some cases (e.g. dynamic
pseudo classes) information as to whether a selector matches an
element is unknown until the user interacts with the document, which
is well after we've generated the style information for any given box.
2) As styles are cascaded, it would appear that it's necessary to create
style structs for each permutation of pseudo classes for matching
later. This is a) hideously expensive in both computation time and
memory requirements and b) just not nice ;)
3) Dynamic changes to the box tree (i.e. after tree creation time) are
incompatible with the way the layout engine is designed to work. We
currently have some limited support for later changes to the box tree
in the form of object fallback processing. I suspect, however, that
this simply isn't rich enough to support all the things that fully
dynamic transformation of the box tree will require.
My current implementation does the following things:
1) The css_get_style API has been extended to allow the user to specify a
mask of the acceptable pseudo selectors to be merged into the provided
style struct. [Pseudo selectors are treated as always matching when
matching a rule's selector and then post-processed to prevent merging
of rules with undesireable pseudo selectors]. This permits extraction
of style information for various permutations of pseudo selectors.
2) Each box in the tree gets allocated 5 style structs over and above the
base style struct. This allows for storing dynamic pseudo class styles
for later matching. [After extracting an auxiliary style struct from
the CSS code, the box generation mechanism compares the auxiliary
struct with the base one. If they match, the auxiliary is discarded]
3) :link and :visited may be trivially determined by considering the
current href parameter to box_construct_*. If it is non-NULL, then the
:link pseudo class must be in operation; it is then simply a question
of determining if the link has been visited before. For this, urldb is
queried. Any match results in the :visited pseudo class being used.
As :link and :visited are mutually exclusive, we can simply incorporate
the appropriate style information into the base style struct. This
does, unfortunately, cause visiting a link and then clicking back to
not react to the changed visited state.
4) Dynamic pseudo classes (currently only :hover and :active) are
processed later in the core browser's mouse handling code. When a mouse
event occurs, an attempt is made to match the dynamic pseudo classes by
manipulating the style of any box under the current mouse position. The
changed boxes are inserted into a list for restoring to their default
state at a later point. The boxes in question are then forcibly
redrawn.
The outcome of this test code is this:
1) Static pseudo classes (i.e. :link, :visited and :first-child) are
relatively simple to support. First-child has already been supported
for some time (as this information can be trivially determined from the
XML tree). :link and :visited have very little impact upon box tree
generation if they are incorporated into each box's style struct as
appropriate. Dynamic updating of the visited state wouldn't be possible
in this scheme, however.
2) Dynamic pseudo classes are out. There's no way to support them without
some major work on the layout engine and CSS code. This won't happen
before 1.0, so I suggest postponing these until then.
3) The language pseudo class is also something I suggest ignoring until
after 1.0.
4) The :first-line and :first-letter pseudo elements would be possible
with a small amount of effort but I'm not sure that this is desireable
before 1.0.
5) The :before and :after pseudo elements would be possible to implement
(and are required for generated content). As these elements would be
processed at box tree creation time it would be a case of generating
the required boxes and inserting them into the tree; the style
information could then be discarded.
Generated Content and Lists
---------------------------
The reason that generated content is on the plan for 1.0 is mainly my
fault. I've always believed that the simplest way to get proper list
support is to implement content generation and then put together some
default stylesheet rules to produce the right kind of output. Some time
ago, Richard produced some code to do counter generation. This is sat in
the render/ directory of the source tree, but is currently unused. Lists
will obviously require something of this kind of functionality.
The CSS specification also contains a display property value of
"list-item" which, if implemented, would provide the appropriate content
and marker separation that lists expect but would not, alone, provide all
the required features for lists. For ordered lists, we would require some
internal usage of the counter code, too. The 3 list properties would also
need implementing.
Generated content, on the other hand, is rather more generic but does not
necessarily cater for the specific semantics of lists.
The question is; which is the one to go for? [NB: if we choose
display: list-item and friends, all the nonsense about pseudo selectors
can probably be postponed until after 1.0. Whether this has any bearing on
the situation, I don't know].
John.
16 years, 6 months