[Netsurf-develop] Thoughts and planning (was: Hello there.)

Phil Mellor phil at mellor123.freeuk.com
Mon Jul 29 00:19:28 BST 2002

> All the code I've done so far is in C. I guess non speed critical parts
> could be written in something else, but it might be difficult to integrate
> them.

C is good.  I like C.  At the moment my work involves me writing in
C--, which is C with all the nasty bits like macros and unions and 
taken out, and everything else must be entirely legal.  I'm also a
fan of eXtreme programming, where you keep comments to a minimum,
but use incredibly meaningful variable and function names, in an
attempt to keep the code self-documenting.  There's more to X-P
than that, and it's quite an interesting and effective approach.

I think in attempt to avoid horrible buginess (the sort that will
never get fixed) we should try to follow similar principles.
Highly modular code, each bit black-box tested before being put
in the main program.  And I know it's tedious, and perhaps
inefficient, to keep checking for NULL pointers and things all
over the place, but it does make debugging easier since you can
notice where something goes wrong.  We should aim for greater
stability than Fresco!

That's my software engineering rant over. :*)

> Some of the things that need doing:
> - HTTP implementation (libcurl ?)

Ermm... yes.  Without looking at how this works, I have no idea
how this works.  Could we have some sort of abstraction layer
over the program, so it doesn't matter whether the data comes
from file, http, or even from another application via WIMP

> - image renderers / converters

Now this is interesting, because a lot of it has been done before.
JPEG rendering is built into the OS, which is nice, and doesn't
RISC OS Select include support for PNGs?  Would it be better to
incorporate other formats into the code, or use helper applications
like InterGif, ChangeFSI, which could run in TaskWindows?
What about ImageFS?  Could that be used somehow?

It would be a bit inefficient (memory wise) to convert byte-sized 
GIFs into stonking great sprites before plotting them, but on the
other hand rendering GIFs on the fly would be slow.  Maybe some
combination -- convert small or oft-used images for efficiency,
but leave large ones in native format.

There are also animated and interlaced images to consider.

> - RISC OS wimp interface

I think this needs a lot of thought.  Something innovative needs
to be done, that uses the strengths of RISC OS.  Drag and drop
should be used heavily -- perhaps you could drag images straight
out into a filer window or other application, and do StrongED
style selecting blocks of text and dragging it out.
Dragging with Select could leave the object in native format,
with Adjust could export the most RISC OS-y conversion.

I often read web pages by selecting the text as I read it; the
computer equivalent of running your finger along the lines, and
it would be nice if you could do that in NetSurf.

But all that's putting the cart before the proverbial horse.

We definitely need support for multiple windows, which could
easily be turned into Opera-style tabbed browsing if necessary.
Is it right that most RISC OS browsers don't put scroll bars
in frames?  That needs to be done properly.  If we only support
the nested window manager (which can be softloaded onto any RO3
machine) things should be much easier.

Are we going to use an existing WIMP library, like OSLib, the
Toolbox, or Jason Tribbeck's recent thing?  Or the one on the
Coders Cauldron that I think Phlamethrower was working on?

When I write WIMP applications I don't generally use an
existing library, mainly because the documention is poor and
I don't find I have the nitty-gritty control that I need.
Maybe we only need to write a nice set of functions that sit
over the Wimp_* SWIs.

It might be best to keep the interface as abstract as possible.
Then porting to another platform, or at least altering or
improving the interface, need be as painless as possible.

> - font handling (unicode ?)

I think we need to be future-proofed for Unicode, even if the
Font Manager can't render it.  

Some sort of text string structure which can hold any form
of text:

struct String
  int encoding;   /* String_Latin1, String_Unicode, etc */
  int length;
  void* string;   /* can hold char*, short int* */

and a set of functions:

struct String* String_new(void);
void String_destroy(struct String* s);
int String_setAsChar(struct String* s, const char* text, const int encoding);
int String_setAsUnicode(struct String* s, const int* text);
char* String_getAsChar(const struct String* s);
int* String_getAsUnicode(const struct String* s);
int String_getLength(const struct String* s);
int String_getEncoding(const struct String* s);
int String_changeEncoding(struct String* s, const int newEncoding);

etc... are needed.  Other facilities to concatenate two strings,
perform atoi() style conversions etc, can be done as further
String_... functions.  Anything to do with text should use Strings,
and always via the function interfaces, never with the internal
data.  This should make it possible to mix and match all the
different text formats throughout the program, if necessary.

I've done some work rendering and formatting text using the
Font Manager before; the fun lies in the special RISC OS control
characters that are used to format the text, such as 26 to change
to a different font/size, 18/19 to change colour, 25 to underline.
It's probably best to represent these as something separate,
perhaps an array of attribute+string structures.

I've got some more topics to add to the list.  Most of them aren't
particularly useful at such an early stage, but it would be good
to keep them in mind when writing the code.

* Embeddedness
You know how you keep getting HTML e-mails?  Wouldn't it be nice if
Messenger could render them properly?  If the NetSurf HTML rendering
engine could be used by other applications, that would be nice.
It might be a case of running a copy of NetSurf with the browser
window as a pane within the other application's window, but it
would be nice protocol for the platform to support.

* Rendering
Now, I've seen some snazzy things done on web pages these days, with
things like images that stay in a fixed position when you scroll
the window, and crazy stars that follow the mouse pointer around the
screen.  I know some of that is done with JavaScript, but even so I
don't think that rendering to a DrawFile (which I understand is how
some other browsers, such as Webite, ArcWeb and perhaps Fresco do it)
is going to be enough.

There might be some major plotting done each time the window is
scrolled or redrawn; it might be nice to render to a sprite which is
then plotted on screen.  I know it's memory hungry, particularly
in hi-res deep colour modes, but it would make things look snazzier
with no irritating flicker. Maybe it could be optional.

* Multitasking
Is this important? Probably.  I've seen complaints at how Fresco
freezes for a while when faced with complex table structures.
On the other hand, RISC OS isn't particularly pre-emptive or

There are a number of approaches:

 a) Forget it. Wait until RISC OS Ltd get it sorted.
 b) Try and get the program to work properly with Niall Douglas'
    Wimp2 thing.
 c) Construct the program in such a way that works around it.

> Maybe we should make a quick plan of how things should work?

Here's my first thought on how to do things:

main loop:


  process standard window requests, mouse clicks, etc;
  nb:  clicks in browser windows, redraw request etc, may add
       to stack of Things To Do.

  if (wimp message received)
    if (message is data received)
      copy data to stack of received lumps;
      acknowledge receipt;

  perform any critical actions (eg. redrawing window);

    perform any time specific actions;

    if (stack of received lumps not empty)
      take lump off stack;
      search through list of requests, match lump to request;
      check to see if fulfilling or part-fulfilling request requires action;
      if (action required)
        add to list of actions;

    while (list of actions not empty && time quota not exceeded)
      process action;  <--- this is where all the fun takes place
      remove action if complete;

  } until time quota exceeded;

} until quit;

The process action section is the most important.  I think it's important
to not let any action take too long, and should always keep an eye on
the clock and pause itself if necessary.  Therefore a "render document"
action could immediately break itself down into a number of smaller
actions, a divide and conqueor approach.  Each action could be allocated
a proportion of the overall time quota, or could only do a little of its
task before returning, otherwise one action at the start of
the queue could hog the entire process creating a bottleneck (eg.
converting a GIF in one window could prevent another document from
being formatted).

Anyway, I've probably written enough pointless witterings for now.
I'll let someone else have a turn.


More information about the netsurf-users mailing list