This document is in response to a variety of discussions and perennial questions on RISC OS related forums. Some of the content isn't new or even that interesting; however it is the first time it has all been brought together at once. It is hoped that this document might serve as a basis for informed decision.
Information about my Firefox port
RISC OS has had a long progression of browsers - too many perhaps - something that is typical particularly of internet software. The same can be seen in IRC clients, FTP clients, even arguably terminal and email clients.
The list of graphical browsers currently includes: ArcWeb, Webite, WebsterXL, Fresco, Browse and Oregano (1 and 2), NetSurf along with a variety of variations.
For completeness, I also mention the textual browsers available as part of my unix ports: Lynx, Links and W3M, although these will concern us no further in this discussion.
The problem is that none of these browsers is able to keep up with the constant development of web technologies on other platforms, simply because of the resources available to RISC OS development.
My proposal is, as an extension of my Unix ports scheme, to attempt to port one or more of the unix browsers to RISC OS. To see how this proposal came about, read the further discussion below.
I also suggest reading one of the Usenet threads which started this issue here on Google, which further discusses some of the points.
To make this possible, both technically and finanically I require help from RISC OS users. The help I require is one of these options:
You can read more about it on the Unix Ports Page.
I would also assure existing Unix Porting Project subscribers that their existing situation would not be negatively affected if they wished to stay with their current arrangement. If anything, it would likely be improved.
Some people have mentioned another amounts; I am happy to discuss this further.
If you read the discussion at the bottom of the page, you can see the rationale in my choices. Currently, my intention is to port FireFox.
If at some time this proves to be impractical, or an easier option presents itself, I will pursue that. It is worth noting that most of the work which helps one browser also helps every other browser, and has significiant secondary effects for helping other Unix applictions. This means additions to ability to convert Unix programs to RISC OS, and output that can easily be updated by all interested parties.
This project needs your financial and technical support to succeed, for me to be able to justify the time spent. Although the initial timescales I had in mind for a usable browser for this project have been somewhat overtaken by other events (such as the need for the move to 32-bit), the time has been well spent and will still help RISC OS and serve as a foundation for this project.
I intend to update this page as progress is made, and where sensible, make downloads available as part of the Unix Porting Project.
The table below gives an overview of status of various browsers under consideration. This table will be kept up to date, and may be expanded.
There are a number of issues which are possibly implied in what has been written, but are worth stating clearly:
These browsers do not include Java functionality; instead they rely upon a plugin to provide it. If the technology exists for the browsers, then a port of Kaffe is not out of the question, although it's outside the scope of porting a browser per se.
A problem faced by browser developers is users expecting browsers to act like Internet Explorer. Clearly this is a sweeping statement, but one that is nevertheless useful to consider. Many recent browsers (notably, Oregano) are strongly influenced by this expectation, as are probably a number of the Unix browsers.
In practice, what this means is that any browser that doesn't conform to all or most of the same things that either IE or Netscape (or Mozilla) do is likely to disappoint or fail on accessing various websites.
Because of the above, and the relatively slow development of RISC OS Browsers (or no development at all), even competent browsers such as Oregano can fail to produce desirable results, and bug fixes can take a long time.
In order that this issue might be addressed, I consider some of the possibilities. I will stress that the only option that doesn't involve financial support is that of simply doing nothing. Progress in this case means opening your wallet.
It's no suprise that these browsers are best suited to RISC OS. They were specifically written for it, and act in ways consistent with the RISC OS GUI by people who know RISC OS well. Much as we might like to support them, WebsterXL development is slow (and its implementation in Basic leaves much to be desired), and although Oregano 2 is still being developed, there has not been a RISC OS for quite some time.
You may be familiar with the NetSurf project to bring a new browser, from scratch, to RISC OS. I talk regularly to the NetSurf developers, and although the progress that is being made is excellent and in areas like CSS has better support than any other RISC OS browser, it lacks all important JavaScript support and adding this is at least again as much effort as has already gone into it. Additionally, it ultimately suffers the same problem as other RISC OS browsers in terms of overall effort that can be given to it.
At one point there was mistaken belief that Opera might possibly be ported to RISC OS. The developers have made it clear that this is not going to happen unless RISC OS has a significantly larger userbase. Opera is of course a proprietary browser, which means less freedom of development, and not ideal. This issue has been discussed extensively in the past, and I don't believe it is worth considering further.
These include browsers such as Chimera, Dillo, Amaya, etc. Even though these are complex programs, I label them "simple" in comparison to other larger browsers. Although I already have a working (in an X Server) version of Chimera, and a nearly working version of Amaya, I don't consider any of these contenders serious. They all lack Javascript which is so important in complex websites. Nevertheless, I do intend to port as many of these as a matter of course.
Having researched all available open source browsers, it's clear that there really are only four groups of choices when considering this option. Significant developments in UnixLib and related technologies over the last few years have seen the possibility of porting any these browsers move from near impossible to tantalisingly close.
But many technical issues remain to be solved, as anyone who has looked closely at any of the following options will tell you. Without futher ado:
However, Firefox does mostly compile for RISC OS. Once these obstacles are overcome, it can be tested with XLib, to determine what issues there are in running it. After that, it can be linked with ChoX11.
There is a possibilty here - a RISC OS browser based around Gecko. This is by far the most labour intensive of these options, but holds certainappeal, as the GUI can be properly designed for RISC OS.
Apart from the RISC OS browser around Gecko option, the significant disadvantage of these browsers is that they will not (initially) look anything like a typical RISC OS application. They will appear in a RISC OS window, but at that point the RISC OS features vanish.
The main Unix Porting Project shows a picture of a port of Dillo, which demonstrates this point. The interfaces will be distinctly Unix in nature. Even so, there remains the possibility of later converting them to have a RISC OS GUI. This work is of course considerable.
There are large secondary benefits from carrying out such work - due to side effects, libraries and so forth, many other programs become much easier to convert to RISC OS - even to the point of making more than one of these options available. These benefits are not to be taken lightly.
Maintenance is an imporant issue too. If the browser contains very little RISC OS code, this is likely to be very easy. Regular updates and recompiles are often sufficient. However, a solution with significiant RISC OS code could be a large amount of work. Problems such as interfaces to non-RISC OS code changing, and bugs in the RISC OS code itself have to be dealt with.