I would actually say that web browsers are a prime candidate for C++ rather than C.

Why? I'd prefer to use C .

Crack pthreads and crack STLport and you're there

These are important if you're trying to port a browser, but I think we're talking about writing one ourselves.

The thing I'd like to concentrate on first is actually rendering HTML with CSS, because the current browsers aren't very good at that. If we get it working, networking and a UI can be done next, and Javascript, plugins, frames, etc. later. Libxml (ported by Justin Fletcher) contains an HTML par-ser, so we can use that.

The main thing is that it should be fun , and we'll learn from each other and teamwork.

I would actually say that web browsers are a prime candidate for C++ rather than C.

Why? I'd prefer to use C .

Best language for the job. There is nothing wrong writing it in C at all - or a mix of C and C++.

Crack pthreads and crack STLport and you're there

These are important if you're trying to port a browser, but I think we're talking about writing one ourselves.

That would be interesting to say the least. Threading is vitally important unless you want to go the Galeon (another linux browser based on Gecko) route in that you load everything into memory, lay it out in memory and blat it out in one go. Fine for a SA machine, okay for a RiscStation, but crap for everything else out there.

The thing I'd like to concentrate on first is actually rendering HTML with CSS, because the current browsers aren't very good at that.

Get the framework set out and a working HTML pa**er. Look how long it took Arcweb to get to the final state it was (unfortunately) left in - bloody ages and even then it could not handle tables.

Once you have a pa**er capable of (at least) frames and tables, then plan the next move. CSS and DHTML are not simple. JS is forever evolving and getting screwed by M$ - and would definately *not* be a candidate for a plug in, unless you could do it very quickly - or as a sep. process.

The main thing is that it should be fun , and we'll learn from each other and teamwork.

Definately.

I'm afraid I'm not on the internet at weekends, but I've been catching up on the latest. Sourceforge project has been approved, so http://www.sf.net/projects/netsurf/ now exists

I propose C as our language: Is GCC okay for everyone?

Will post some more discussion on here tomorrow

Byeeeeeeeeee!

I'm afraid I'm not on the internet at weekends, but I've been catching up on the latest. Sourceforge project has been approved, so http://www.sf.net/projects/netsurf/ now exists

I propose C as our language: Is GCC okay for everyone?

Some comments:

As Chris says stop worrying about the name. The name will only represent it in sourceforge. You can change the name later and you can always redirect any sourceforge homepage to a proper domain name once the name has been decided.

There are a lot of comments about how to do things and potential structure for the software. I agree with Chris that it should be as modular as possible but I don't agree with anything that does "polling". There's no need for this and it simply wastes processor time. The whole thing should be event driven. This can be tricky in C because it doesn't mesh well with RISC OS' event notification mechanisms. In practise your only realistic option is probably to run everything off the application's message queue and design the architecture so that it can work effectively with one thread.

In order to achieve this you have to bear certain things in mind. Firstly you need to be able to register for network events in a manner so they will get passed into your message queue. Judging by what I've read here I wouldn't even bother trying this one yourselves. Instead track down the socket**tch module and save yourselves a heap of time. Note that you absolutely cannot use blocking network calls because they block the whole OS. What this means is that you'll have to structure your network code in such a way so that it can cope with the fact that it may take several network events to get an entire message. One obvious method for this is to have a state driven message reader which keeps track of how much of each message it has read. Given that HTTP opens a separate connection for each element of a web page you'll probably want to be able to instantiate multiple message readers. They could be C++ objects or abstract handles in C. BTW, having read this does anyone still think pre-emptive multitasking and multi-threading is a bad thing?

Potentially you could use a similar technique to make everything modular - write the core elements as modules and just use the application to coordinate them using the message queue. Then again if you're going to do this you either aren't going to use C or you're using Norcroft.

Rendering is tricky, but I don't agree that multi-threading is a must - in fact I think that a multi-threaded renderer would be a nightmare to implement. I rather suspect that Gecko places complete network messages (read using multi-threading) onto a queue, or page data structure, which is rendered by the renderer when it changes (note, no polling). I suspect you could do something similar providing you create a renderer that can cope with not all elements being present (actually you'll have to do this because the user should have the option to turn off things such as pictures). As each full message is read you shove it in a data structure and redraw the window. Obviously progressive rendering of GIFs and JPEGs will need a bit of thought - I wouldn't claim to know the best of way of dealing with that.

One suggestion has been porting Gecko. From a brief look at the general architecture docs for it you'll probably need some form of pre-emptive multitasking, multi-threading and an implementation of XPCOM which, although I've not 100% sure on this, may at least mean writing a dynamic linker as well.

That'll have to do as I've got to free up the phone line

Hmm plenty of enthusiasm, seemingly little experience

Well, yes unfortunately.

There are a lot of comments about how to do things and potential structure for the software. I agree with Chris that it should be as modular as possible but I don't agree with anything that does "polling". There's no need for this and it simply wastes processor time.

Waste processor time? I don't think so, it's just an extension to Wimp_Poll'ing with the OS. Call Wimp_Poll, decode reason code, perform internal upkeep, call Wimp_Poll etc. I'd suggest using the wimp message system. Either that or write your own threading library, which in itself will be fun.

In order to achieve this you have to bear certain things in mind. Firstly you need to be able to register for network events in a manner so they will get passed into your message queue.

Yes. Network problems. A major headache. I've snipped your renderer comments, I agree with them. The renderer should be able to cope with converting chunks of any incoming html into binary format for the redraw subsystem to use at a later date when the browser window is idle and requiring redraw.

One suggestion has been porting Gecko.

I don't know what will take longer: writing a half decent browser from scratch or porting a feck off huge one from an alien platform.

Chris.

Hmm plenty of enthusiasm, seemingly little experience

Well, yes unfortunately.

This might be true, but, like you said, it will be good fun and I know I'm going to learn a lot from it - even if we don't manage to make a rival to IE

I don't know what will take longer: writing a half decent browser from scratch or porting a feck off huge one from an alien platform.

Porting, I would have thought. At least if you're writing your own you really 'know' the code.

Waste processor time? I don't think so, it's just an extension to Wimp_Poll'ing with the OS. Call Wimp_Poll, decode reason code, perform internal upkeep, call Wimp_Poll etc. I'd suggest using the wimp message system. Either that or write your own threading library, which in itself will be fun.

My apologies I misunderstood your original post. I thought you meant coming off a wimp poll and going round all your modules to see what (if anything) had changed. Obviously you meant that the modules should generate a message across the wimp when done.

No problem. Poll word would be useful here too. Anyway, I have other stuff to do. Good luck with the wbe browser. You'll need it.

Chris

Last night, rather than getting on with my final year project, I came up with a few NetSurf logos.

E-mail: richmackin@ntlworld.com
ICQ: 112431453

Wow - I'm catching up with Mr. Arenaman. How long have you been on TIB, Michael?

A year and a half/two years. I used to have one of the highest posting counts

A year and a half/two years. I used to have one of the highest posting counts

Ooh heck. I've only been here a month!

This April will be NetSurf's 15th birthday.

And this is the thread that started it.

This April will be NetSurf's 15th birthday.

And this is the thread that started it.