In message <4bda595d4b%phil(a)mellor123.freeuk.com>
Phil Mellor <phil(a)mellor123.freeuk.com> wrote:
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. :*)
OK, we're agreed on C. I think you're right that we should program
defensively, with lots of assert()s etc. We need to keep security in mind
too, and not trust anything from the net. Shame we can't do pair
> - 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
Sounds like a good idea. I've managed to get libcurl to fetch a page on
RISC OS, so at least we could start by using it.
> - 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?
Definitely incorporate into the code for speed. Apparently launching helper
applications is one of the things that makes Webster slow.
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.
I guess we could try direct rendering, and if it's too slow convert
instead. I find the OS JPEG renderer slow when I'm using Browse.
> - 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.
For me, frames are low priority, since few good websites use them anymore.
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.
I've used OSLib so far. OSLib is just a C interface to RISC OS SWIs, not a
WIMP library. I think we should use the WIMP directly through OSLib.
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.
Sure, all the platform-dependent code should be separate.
> - 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
int encoding; /* String_Latin1, String_Unicode, etc */
void* string; /* can hold char*, short int* */
and a set of functions:
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.
Libxml converts other encodings to UTF-8 when it parses HTML files, so
maybe it would be better to use that or another Unicode encoding
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.
At the moment the layout code makes a separate text box for each change in
font or style, so we wouldn't need this.
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.
Lots of apps could find this useful. It would need an option to disable
fetching external stuff.
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
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.
I think direct rendering is best, not DrawFiles. We could do the sprite
thing if it's too slow.
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'
c) Construct the program in such a way that works around it.
Here's my first thought on how to do things:
} 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
Looks complicated. I'd prefer to avoid splitting up code if possible,
because things like the layout code are very recursive. It would be
possible to add Wimp_Polls which only handle urgent events and queue the
rest at places in it though, to give other apps CPU time. Ideally it'll be
so fast that it won't be necessary ;->.
I guess the first priority is making sure you can compile it. You'll need
libxml, oslib, and libcurl. I could upload compiled libxml and libcurl if
you want. I think the RO CVS port can download from SourceForge CVS.