log in | register | forums
Show:
Go:
Forums
Username:

Password:

User accounts
Register new account
Forgot password
Forum stats
List of members
Search the forums

Advanced search
Recent discussions
- RISC OS Interviews - Andy Marks (Mr RiscOSBits) (News:1)
- upgrading RiscOS on the raspberry Pi 2 (Gen:2)
- ADFFS on the Pi help needed (Games:7)
- Spring Issue of Drag'n'Drop Magazine hits the shelves (News:1)
- AMCS free versions are live! (Gen:8)
- RISC OS FR : The Raspberry Pie contest (News:19)
- ADFFS on the Pi help needed (Gen:1)
- South West Show in Pictures (News:)
- South West Show Report (News:2)
- A7000 Schematics (Gen:5)
Latest postings RSS Feeds
RSS 2.0 | 1.0 | 0.9
Atom 0.3
Misc RDF | CDF
Site Search
 
Article archives
Acorn Arcade forums: General: Web browsers
 
  Web browsers
  This is a long thread. Click here to view the threaded list.
 
mfrissen Message #3994, posted at 13:58, 15/6/2002, in reply to message #3992
Unregistered user
[snipped]

People-wise, I think we have:
Me: Coding
MarcoF: Testing
Monkeyson: Coding
Andrew Poole: GUI Templates
Moss: Testing, Docs

So, to conclude, yes, I am serious, but think we ought to concentrate one thing at a time - a web browser is a big project.<br><br>[Edited by Hertzsprung at 09:20, 19/4/2002]

hmm, if you want perfect HTML rendering. according to the standards out there, I guess a good point to start is to port an open source renderer.. I think w3c has one available (or HAD one?)
but that is then for the standard check, more or less.. not for speed..

i must admit I am quite happy with the way !Oregano handles HTML/CSS, but indeed, there is quite some things left to be desired.

a browser rendered should take into account:
- HTML (4?)
- CSS (2)
- XML (getting more and more popular)
- javascript (version?)

i think those are the 4 fundamentals.. lots of work smile where XML might be lower priority.
then, you need:
- png, gif, jpg, csv (?) renderers
- possibility of plugins
- http, ftp, gopher protocol
- https

whoa.. even *more* work smile

well, I'm in smile

  ^[ Log in to reply ]
 
moss Message #3995, posted at 13:58, 15/6/2002, in reply to message #3994
Unregistered user I don't think Oregano handles font faces, set by CSS, does it? That annoys me unhappy

Correct me if I'm wrong...

  ^[ Log in to reply ]
 
Hertzsprung Message #3996, posted at 13:58, 15/6/2002, in reply to message #3994
Unregistered user :me feels woozy just thinking about it:

w3c do have a browser - I have checked it out - it looked a bit crap to be honest tongue.

HTML 4 is definately a good starting point I think. CSS also needed. XML and JavaScript should be lower priority, I think. Could we pinch PNG/GIF/JPG renderers from another program. There must be some modules we could use to do that bit for us.

I think http would be a good starting point smile There must be some modules on RISC OS to handle the protocols you mention? Like I say, I'm not familiar with the networking side of it - I'm not internetted on my lowly A5000 unhappy

  ^[ Log in to reply ]
 
diomus Message #3997, posted at 13:58, 15/6/2002, in reply to message #3996
Unregistered user Hey, I didn't realise this thread had turned into one about writing a web browser smile

It's no secret that drobe.co.uk was writing a browser ages ago, in fact drobe.co.uk was created as the home page portal for the broswer. In the end, we just stuck to the website wink

I can't remember how far we got, I remember starting to write a html renderer in assembler. If you need any help BASIC or C wise, I'm happy to lend a hand, if you need it. I reckon you'll need more than 2 coders seeing as you'll have to take care of:

- Sockets, ports, proxies, http fetchers, url launchers, cookie manager etc.
- html p4rsing and rendering, dynamic UI to provide forms and (spit) frames, CSS handling, the code to redraw the webpage will be fun
- memory manager to allocate memory to html viewer and fetchers
- plugin manager to launch separate image converters
- javascript fun
- UI system to provide windows, menus, choices windows, hotlists, histories etc.
- I'm sure there's more I've forgotten, like dealing with non Latin character sets (encoding), printing webpages, searching pages, security features, SSL and so on.

I recommend that your write as much as possible in a higher language such as C and leave BASIC to being the glue for smaller bits. Also, please don't fall into the trap of planning the application for 6 months and not actually doing anything: get designing and coding, you can change stuff as you go along.

I think that's it, now I can shut up and wish you luck smile

Chris

  ^[ Log in to reply ]
 
andypoole Message #3998, posted at 13:58, 15/6/2002, in reply to message #3997
Unregistered user when I get home I'll have a go at making some test templates to see what I can come up with..

Any ideas for what windows I will need to make..

browser window
toolbar
choices - what do we want in it
info box
startup banner - leave till last (low priority)
realm auth box
message boxes

anything else?

I reckon that we can get richg to make the twirly thingie that twirls while pages load and possibly some other images...

I'll post later when I have got something there.

Have we got a name yet? for now I'll put Iconbar Web Browser while we think.

  ^[ Log in to reply ]
 
Hertzsprung Message #3999, posted at 13:58, 15/6/2002, in reply to message #3998
Unregistered user smile indiff unhappy :me keels over and faints:

No, I still don't think we have a name.... Cummon people, that's the easy bit!
As soon as we have a name, I'll set up the SForge project grin

We need to get this list down to something more managable:

- Sockets, ports, proxies, http fetchers, url launchers, cookie manager etc.

How much of this has already been written?

- html p4rsing and rendering, dynamic UI to provide forms and (spit) frames, CSS handling, the code to redraw the webpage will be fun

This is the bit I'd like to concentrate on

- memory manager to allocate memory to html viewer and fetchers

unhappy guess there's no avoiding that

- plugin manager to launch separate image converters

that too

- javascript fun

JavaScript is lower priority

- UI system to provide windows, menus, choices windows, hotlists, histories etc.

That's the easy bit tongue

- I'm sure there's more I've forgotten, like dealing with non Latin character sets (encoding), printing webpages, searching pages, security features, SSL and so on.

I think I'll go and have a lie down....

  ^[ Log in to reply ]
 
I don't have tourettes you're just a cun Message #4004, posted by [mentat] at 13:58, 15/6/2002, in reply to message #3976
[mentat]Fear is the mind-killer
Posts: 6266
Oregano, Fresco... Bilco? smile

Phyton, Lynx, PussyCat? indiff

-Faith (as in, have faith, we'll finish it soon - and also a nice sly E.D. ref)

-CROW (cool risc os web) or CROWBAR (cool risc os web browser, ask rich!)

-ARCWB (A Really Cool Web Browswer - hmm, sounds familiar...)

-RWB (RiscOs Web Browser - it could have a Red, White and Blue logo!)

-FishNet (sorry)

-JCB (Javascript Compliant Broswer)

-ROW (RISC OS Web)

-BETHAN (BEtter THAn Netscape)

-!BROWN (Browse RISC OS Web Net)

-ROB (RISC OS Browser)

-!Rib (Riscos Internet Browser)

...more?

You want MORE?!

  ^[ Log in to reply ]
 
I don't have tourettes you're just a cun Message #4007, posted by [mentat] at 13:58, 15/6/2002, in reply to message #4005
[mentat]Fear is the mind-killer
Posts: 6266
Surf is cool. cool

(and you can then rip off oregano's desert island sunny marketing style thing)

  ^[ Log in to reply ]
 
james Message #4008, posted at 13:58, 15/6/2002, in reply to message #3931
Unregistered user I've been experimenting with rendering HTML / CSS. It's not easy unhappy.

Anyway, I've put the C source of what I wrote up at http://www.strcprstskrzkrk.co.uk/browser.zip if anyone's interested. There's simple CSS parsing and the start of a layout algorithm. I'll contribute programming if you set up a project.

James

  ^[ Log in to reply ]
 
moss Message #4009, posted at 13:58, 15/6/2002, in reply to message #4008
Unregistered user This could be good. smile

I'll have plenty of free time over summer - plenty of time for writing documentation, testing, basically anything that doesn't involve actual programming. (I know rudimentary C, but that's hardly enough for this level of programming. I could probably learn quite a bit off you lot!)

  ^[ Log in to reply ]
 
Hertzsprung Message #4010, posted at 13:58, 15/6/2002, in reply to message #4009
Unregistered user grin I will have some time over summer also. Sure we can't entice you into doing some rudimentary C? I haven't done C in aaaaaages - I've been doing Python (seriously cool language) at work. Looking forward to this.

Oh, name change needed because somebody's already nicked surf at sourceforge. Erm. Surfer? NetSurf? Windsurf? I'll have to choose one of those, I think.

  ^[ Log in to reply ]
 
diomus Message #4011, posted at 13:58, 15/6/2002, in reply to message #4002
Unregistered user You worry me. A title is a title. It can be changed. You have bigger things to worry about:

http specs: http://www.ietf.org/rfc/rfc2616.txt
ftp specs: http://www.ietf.org/rfc/rfc959.txt
html specs: http://www.w3.org/TR/html4/
xhtml specs: http://www.w3.org/TR/xhtml1/
css specs: http://www.w3.org/TR/REC-CSS1
tcp/ip info: http://www4.ulpgc.es/tutoriales/tcpip/entrada/3376fm.html
socket intro: http://www.iconbar.com/programming/network/
more sockets: http://www.ecst.csuchico.edu/~beej/guide/net/html/
more sockets: http://www.uwo.ca/its/doc/courses/notes/socket/
server/client examples: http://pont.net/socket/
dillo, small browser, something you'd start off aiming for: http://sourceforge.net/projects/dillo/

Ok, that's enough of links I've found in the past to be quite cool. A lot of bed time reading smile Essentially, the system would be a demand driven system. The browser would own the toolbar and when given a URL to fetch, it would call the fetcher and place it in a queue. The queue is polled until an event occurs, such as the fetcher receiving data. The memory manager allocates chunks of memory to slot the fetched data into. The p4rser is queued so that it translates the html/css/xhtml into a simple binary format for the redraw code to quickly use to reproduce the webpage on the screen. The p4rser also queues up more fetchers to grab images required for the page. The redrawer is also queued to redraw the translated html/css/xhtml as it comes in. When all done, the queue can be used to close the fetcher and inform the memory manager that we're done. When the WIMP tells us to redraw the page, we can use the translated binary to reproduce the webpage.

Also, the fetcher should be configured to work with a cache manager so pages and images are first pulled from disc then from the network. Also, the cache manager is queued to save rendered pages and fetched images to disc. A image manager will be needed to vector jpg/png/gif conversions out to separate applications, these all exist. RISC OS Select includes jpg and png suport as standard. That's just the fetch/render/redraw system. The actual network fetcher and p4rser sub-systems will be mucho complexo than this, although my StatusD software does do a good work of scanning through files, picking out tags and identifying and processing them. That's 2/5ths of the way there.

Then there's the plugin for flash/java/the works system- there's so many protocols to choose from, we don't need to devise our own. The UI is starightforward, the hotlist and history managers will be more interesting. I can see us using linked lists and panes.

Err, that's all I can think of for now. I've got some other work to do. T'will be interesting to see how this pans out.

Chris

  ^[ Log in to reply ]
 
moss Message #4012, posted at 13:58, 15/6/2002, in reply to message #4010
Unregistered user
grin I will have some time over summer also. Sure we can't entice you into doing some rudimentary C? I haven't done C in aaaaaages - I've been doing Python (seriously cool language) at work. Looking forward to this.
Well, if I can contribute anything programming wise, I will - but I honestly don't think I'd be much use in that area.
Oh, name change needed because somebody's already nicked surf at sourceforge. Erm. Surfer? NetSurf? Windsurf? I'll have to choose one of those, I think.
!Surf ?
  ^[ Log in to reply ]
 
mfrissen Message #4014, posted at 13:58, 15/6/2002, in reply to message #4011
Unregistered user see, i told you it wouldn't be easy? grin

now the name is not very important, but what about BROS? (Browser RISC OS)? (yeah, didn't meet the deadline of 2hrs, I just got back to my RPC)

  ^[ Log in to reply ]
 
Hertzsprung Message #4015, posted at 13:58, 15/6/2002, in reply to message #4013
Unregistered user What do you consider to be the basics? *relatively* easy? I'm not too sure about that smile
  ^[ Log in to reply ]
 
moss Message #4016, posted at 13:58, 15/6/2002, in reply to message #4015
Unregistered user
What do you consider to be the basics? *relatively* easy? I'm not too sure about that smile
Well, I would guess that the really hard part of the coding is all the basics - the fetching, basic page rendering, etc... (the user interface should be pretty easy though). As soon as you've got a basic, working web browser, it shouldn't be too hard to add on extras...

IMO, of course! tongue

  ^[ Log in to reply ]
 
diomus Message #4017, posted at 13:58, 15/6/2002, in reply to message #4013
Unregistered user
Err, that's all I can think of for now. I've got some other work to do. T'will be interesting to see how this pans out.

Chris

Looks good Chris. It will be interesting...

Surely the main work here is to get the basics done. Once they are over, it should be *relatively* easy to add CSS stuff, for instance, shouldn't it?

The basics? You could write a basic broswer that just telnetted to the webserver required on port 80, GET <file> and then displayed the returned page. Very cute.

Of course this application would have to be modular. By the time the UI is finished, the renderer and fetcher sub-systems would still be in a very early stage however as they are improved, the newer sub-systems would be able to be built with the existing completed bits with little fuss. Provided the system as a whole is designed well.

Essentially, you'd need: queue manager, simple fetcher, simple text renderer, UI to provide this. Even this is a couple of weeks work for someone in their spare time but it can be easily expanded upon if you think 'modular' smile

Chris

  ^[ Log in to reply ]
 
moss Message #4020, posted at 13:58, 15/6/2002, in reply to message #4018
Unregistered user Yep... modularity is the key grin And who knows, I may learn so much from the project that I could properly contribute to the programming later on.

*moss is fired up*

  ^[ Log in to reply ]
 
Hertzsprung Message #4021, posted at 13:58, 15/6/2002, in reply to message #4018
Unregistered user Sadly, I've been doing all my Python work on Whinedoze unhappy
  ^[ Log in to reply ]
 
Hertzsprung Message #4022, posted at 13:58, 15/6/2002, in reply to message #4021
Unregistered user I have submitted our proposal for NetSurf to SourceForge. Hopefully I will here from them soon. I shall let you know... grin
  ^[ Log in to reply ]
 
diomus Message #4023, posted at 13:58, 15/6/2002, in reply to message #4020
Unregistered user
Yep... modularity is the key grin And who knows, I may learn so much from the project that I could properly contribute to the programming later on.

*moss is fired up*

I don't mean to plug but this is true. Even if the browser doesn't take off, there's so muchyou can learn by getting your hands dirty. I've recently been rewriting EasyGCC in C and I've learnt so much from doing this.

Chris

  ^[ Log in to reply ]
 
diomus Message #4024, posted at 13:58, 15/6/2002, in reply to message #4023
Unregistered user Heh, as your first exercise, write an application that telnets to port 80 at www.drobe.co.uk and fetches the home page using:

GET /index.php HTTP/1.1\r\nConnection: closed\r\nHost: www.drobe.co.uk\r\n\r\n

Bonus points if you get the raw html redrawn in a window smile

Chris

  ^[ Log in to reply ]
 
moss Message #4025, posted at 13:58, 15/6/2002, in reply to message #4023
Unregistered user
I don't mean to plug but this is true. Even if the browser doesn't take off, there's so muchyou can learn by getting your hands dirty. I've recently been rewriting EasyGCC in C and I've learnt so much from doing this.

Chris

You're right. Which (genuinely) reminds me...

*goes off to download EasyGCC* smile

  ^[ Log in to reply ]
 
mfrissen Message #4027, posted at 13:58, 15/6/2002, in reply to message #4022
Unregistered user
I have submitted our proposal for NetSurf to SourceForge. Hopefully I will here from them soon. I shall let you know... grin

Netsurf.. mwa, not bad..

except that it is used *a loT*:
http://www.netsurf.ch/
http://www.netsurf.com
http://www.netsurf.de
http://www.netsurf.net
etc..

grin

  ^[ Log in to reply ]
 
Hertzsprung Message #4028, posted at 13:58, 15/6/2002, in reply to message #4027
Unregistered user http://netsurf.iconbar.com ?

grin

[Edited by Hertzsprung at 13:46, 19/4/2002]

  ^[ Log in to reply ]
 
mfrissen Message #4029, posted at 13:58, 15/6/2002, in reply to message #4028
Unregistered user just to make sure:
is there consensus on:
- language (my bet: c)?
- library (is it going to be a port from *nix -- UnixLib needed)
- compiler set (all developers should use the same suite, otherwise you'll get weird side effects and communication issues regarding switches and such)
- CVS (eh, I guess sf arranges that one)

etc... smile
oh, and anyone interested in writing a decent email client with pop3 protocol built-in (I hate the usage of a seperate pop3 handler..) grin

[Edited by mfrissen at 14:07, 19/4/2002]

  ^[ Log in to reply ]
 
diomus Message #4030, posted at 13:58, 15/6/2002, in reply to message #4029
Unregistered user
just to make sure:
is there consensus on:
- language (my bet: c)?

Sounds good. Encourages logical and structured programming.


- library (is it going to be a port from *nix -- UnixLib needed)

I don't understand what you mean. If you're suggesting that someone ports a web browser from *nix then you need to find out about this little barrier called gtk. All the socket swis/calls are provided by the RISC OS internet stack.


- compiler set (all developers should use the same suite, otherwise you'll get weird side effects and communication issues regarding switches and such)

This is always a problem as some people don't have norcroft and only have GCC -which isn't necessarily bad, you know I'm an advocate for GCC smile


- CVS (eh, I guess sf arranges that one)

You'll still need the client and be proficient in it. It's essential given the likely number of people contributing.

There's a large number of tools that will be required by people. Things like gerph's !Console for debugging to start off with.

Chris

  ^[ Log in to reply ]
 
Mark Quint Message #4034, posted by ToiletDuck at 13:58, 15/6/2002, in reply to message #4033
Ooh ducky!Quack Quack
Posts: 1016
hrm,
dont know why I didnt see this thread before shock
looks very good thou, i shall be keeping an eye on this smile
  ^[ Log in to reply ]
 
arenaman Message #4036, posted at 13:58, 15/6/2002, in reply to message #4020
Unregistered user When there is a product, I am willing to promote it under the Melotech banner - distribute it on melotech.co.uk, offer at-cost CDs for people to get connected and browse using this browser etc etc. Even advertise if the money is there grin

Keep it open source, obviously. I do think it needs proper promotion to make this worth-while. Still, better create the damn thing before we argue on promotion wink

  ^[ Log in to reply ]
 
bluebottle Message #4038, posted at 13:58, 15/6/2002, in reply to message #4029
Unregistered user Hi

just to make sure:
is there consensus on:
- language (my bet: c)?

You could alway borrow bits from Mozilla. I would actually say that web browsers are a prime candidate for C++ rather than C.

- library (is it going to be a port from *nix -- UnixLib needed)

Or netlib. To make life really simple, a port of STLport would help no end. The STL with GCC is not very good to say the least.

- compiler set (all developers should use the same suite, otherwise you'll get weird side effects and communication issues regarding switches and such)

If it's in C++, there is only one compiler up to the job

- CVS (eh, I guess sf arranges that one)

Correct.

etc... smile
oh, and anyone interested in writing a decent email client with pop3 protocol built-in (I hate the usage of a seperate pop3 handler..)

Why duplicate something that is already out there? I would have it simply that you could call up Pluto, MPro or Marcel from within the application rather than have it's own mail software. Mozilla mail sucks big time.


What I would also suggest is that prior to a single line of code getting written, it is fully mapped out with a step through pathway of the main areas of source. Second to that, follow the same sort of setup as GCC. There it is one person (Nick Burett) with overall control and a pile of contributers. All code has to go through him before it's committed to CVS.

There is, of course, one big problem which none of the RISC OS browsers has *really* managed to work out and that's threading (yes, I know there is a partial port of the mozilla pthread library, but it's rather incomplete and there is also the Simtec threading module, but that has, um, problems). WXL does it by starting background tasks via "helper" apps, Browse decodes and places on the fly and Oregano almost gets it right. Fresco is just crap.

Crack pthreads and crack STLport and you're there - the UI can be done via the toolbox (or better still via Desk).

Sorry if that's a bit of a downer, but it's better to be realistic before setting off than getting 5% through and finding it's a turkey due to the libs not being there or are not up to the job.

[Edited by bluebottle at 21:19, 20/4/2002]

  ^[ Log in to reply ]
 
Pages (5): |< < 4 > >|

Acorn Arcade forums: General: Web browsers