| Oregano 3 spotted on a RISC OS desktop |
|
Published: 19th Sep 2007, 05:04:41GMT Source: drobe.co.uk
By the Drobe news desk
|
| Page 1 of 1 |
|
| It looks so shiny |
|
Click for larger image
Here is a rare screenshot of Oregano 3 running on RISC OS, demonstrating the web browser unfortunately canned earlier this year. The NovaTech website shown involves particularly tricky HTML that previous Oregano versions were unable to cope with, although this development build of O3, reportedly version 3.9.12, shows it handles the web page perfectly.
In March 2005, dealer Richard Brown asked for punters who were willing to pay for a new version of Oregano to make themselves known by dropping him an email. The response lead to confirmation that the project would be going ahead. It was eventually cancelled in April this year when the software's developers, Oregan, were unable to find the time to fix issues in the RISC OS port as they were concentrating on producing versions for large corporations - who were paying top dollar to embed the program in their gadgets and STB kit. A new beta version of Oregano 3 was due to be distributed to testers just before the plug was pulled.
Although Oregano 1 was a native RISC OS application written mostly from scratch, versions 2 and 3 use Oregan's TV web browser core, which is designed to be portable across a number of platforms. It is aimed at set-top boxes, games consoles and other so-called consumer electronics.
It's believed that when Oregan and Richard parted ways, Oregan reserved the right to release Oregano for RISC OS directly, rather than through a third party distributor, at a later date. Newer versions of the RISC OS port can still be turned out by the developers as the inner portable browser core can be updated without having to fiddle with the ROS user interface code.
Links
Send us news, pix and viewsRelated articles
Oregano 3 scrapped
Patch released to solve Oregano 2 socket puzzle
Oregano 3 survives user group meeting
This article has been linked to, or is available in the following formats:
|
| |
|
druck (+2.0)
19/9/07 9:01AM |
The core of O3 is a very good browser, its compatibility is websites is second only to Firefox handling the typical broken Javascript thats out there, its CSS compatibility is as good as NetSurf, and dare I say it the TTF font engine looks even nicer than the RISC OS one. The RISC OS user interface is also clean and responsive.
However its always been let down by what should be the simplest part of the browser, the fetcher. This chugs away at a fraction of the speed of anything else, including RISC OS Firefox, continually changing its mind on how many files there are left to go. Usually after viewing a dozen pages or so, it either slows down or bombs out. Of course it might entirely be due the fetcher is the browser is processing the HTML in parallel, but it does seem to be the weak point that it shares with its predecessor Oregano 2.
If only this issue was fixed, it would be the highly capable browser RISC OS users are still crying out for. But as usual I suspect very few would be willing to actually pay for it, particularly as Oregan Ltds development cycle only seems to deliver one major release before throwing it all away and starting again. |
jess (+3.0)
19/9/07 9:39AM |
It's a shame that oregan didn't use RISC OS as a test platform for their browser. (perhaps with a token license fee) It would have got a really thorough testing.
I notice that all the platforms it was aimed at are non GUI based, was integrating it into the desktop a major problem?
If so a version that ran in a single fixed sized window would have been better than nothing. |
Stoppers (+2.0)
19/9/07 9:48AM |
"...handling the typical broken Javascript thats out there."
I wonder if there would be a "market" for a proxy server that did nothing but fix broken webpages before they get to your browser. That way, browser developers could concentrate on features without having to work out what IE would do.
Perhaps it could also expand out those stupid javascript bits that just perform the same function as a normal link. |
druck (+2.0)
19/9/07 10:34AM |
In reply to Stoppers:
if you aren't familiar with the Turing Machine Halting Problem, I suggest you look it up. The only sort of browser proxy that works is how Mobile Opera does it - render the entire page and send the client a bitmap and a button map.
In reply to Jess:
There is a test version of O3 that runs on Windows. It doesn't use the GUI but simulates a set top box frame buffer within a window. |
AW
19/9/07 11:46AM |
So if people wanted to ask about the possibility of an O3 release, theywould contact Oregan?
Why do Oregan need a "five figure sum" to release the browser? GeneSys reportedly pulled out because of uncertaintly whether issues such as redrawing could be resolved. That suggests that they weren't doing the programming or weren't capable of doing the programming. So why doesn't another or more capable company (Castle?) finish it off and do the platform and themselves a big favour? |
flibble (+3.0)
19/9/07 11:53AM |
In reply to AW:
Castle/Genesys have never had access to the source code of of any of the Oreganos and have never contributed any code to any of them. It is entirely the work of Oregan Networks. To license the source code from them would likely be considerably more than a "five figure sum". |
jess (+1.0)
19/9/07 12:11PM |
In reply to druck:
o3 on windows, yes that's what I was thinking of. Running on RISC OS systems would be more similar to an STB in terms of processor power. Presumably a single window approach would be far more likely to work with newer cores, when they throw the whole thing away and start again.
proxy: a 2 stage approach might be best. The proxy either acts as a simple HTMLtidy and javascript replacer or render and imagemap the links, depending on how horrid the site looks. Buttons to switch modes could be added. (A 3rd stage could be to offer a VNC to a browser session) |
CrazyRisc
19/9/07 5:51PM |
I like O2, as it seems to be the most stable, as well as very quick. Sadly, its real limitation on website handle forces me to use an alternative - the not quite stable Netsurf. While Netsurf can handle just about anything thrown at it, O2 still beats it on speed. However, even Netsurf looses its bottle when using Google to browse imiges. After about three pages, Netsurf, seems to fall off the digital wave and into the void of *BLEEP!*. If O3 is brought out, I will be among the first to jump for it! |
rjek
19/9/07 6:08PM |
In reply to CrazyRisc:
Oddly, I can't imagine a web browser slower than O2. On the occasions I had the misfortune to use it, I'd quite often go to put the kettle on while it fetched mildly complex pages - and that's before we consider how slow and clunky its UI is. Could you provide some examples of where O2 is faster than NetSurf? If it really is, there's something we need to fix. |
CrazyRisc
19/9/07 11:31PM |
In reply to rjek:
Entering an image search under google was faster under O2, than Netsurf. But speed was not the main complaint about either of these browsers. Yes, O2 does have issues when it tries to open pages it can't handle, but then Netsurf seems to suffer a memory leak or something, as it can't handle too many searches from Google's image base, before it bomb's out.
Yes I do use Netsurf as my main RiscOS browser, but O2 is on backup. If O3 can deliver, then I'd be interesed in it. |
AW
20/9/07 12:45AM |
A five figure sum was quoted by GeneSys -what are you talking about flibble? |
VinceH
20/9/07 8:48AM |
In reply to AW:
He's talking about the difference between releasing the application, and releasing the sources to the application. |
AW
20/9/07 9:49AM |
So GeneSys would have to pay a "five figure sum" to just /release/ the application? |
flibble
20/9/07 10:35AM |
In reply to AW:
Yes |
Stoppers
20/9/07 10:58AM |
In reply to druck:
It probably cropped up while I was doing my Comp Sci degree all those years ago.
I'm not expecting a general solution, just a system which recognises certain patterns and corrects them to proper HTML. Assuming a large proportion of problems are inserted by software, it should be possible to fix them generically. The proxy could possibly even include a way for the user to request different attempts at a solution.
For example, the new itv.com includes two meta http-equiv content-type entries in the header of each page; one saying utf-8 and the other utf16. The first (utf-16) is wrong and the second is right. Presumably, IE accepts the last value it's given but the RO browsers I tried accept the first and fail to display any pages. Three solutions are possible:
1. Ask ITV.com to fix it (I tried that, didn't hear back from them)
2. Modify all the RO browsers to behave more like IE.
3. Edit each page by hand to remove the utf-16 tag.
4. Write a program which scans the HTML for this and other problems and fix them automatically.
It's not totally easy, but not impossible; it's just a matter of trying to match the behaviour of the main browsers.
I grant you, interpreting general javascript is never going to be complete, but expanding something like this shouldn't be impossible:
function sayfaAc(adres) {
if (adres.substring(0,7) == 'http://')
yenipencere = window.open(adres);
else
location = adres;
} |
jess
20/9/07 11:33AM |
What about a RISC OS like linux offering firefox sessions (limited to one window but using tabs) via VNC as an alternative? |
tlsa
20/9/07 11:37AM |
In reply to Stoppers:
All the text on ITV's site seems to work fine in NetSurf. What's the problem? |
druck (+1.0)
20/9/07 1:45PM |
Any effort expended by a RISC OS developer on some kind of a proxy to filter broken web pages for outdated defunct RISC OS browsers would be a criminal waste of time, even if it wasn't vastly more complex than described above, and absolutely certain to be domed to failure.
If anyone has any spare development time and knowledge of HTML, it should be put towards either the one RISC OS browser still in active development - NetSurf, or alternatively getting FireFox 2 in to a better than barely usable state now PN has seemingly abandoned it again (PN: if that isn't the case please say).
It really does make my bloody boil when time is wasted discussing bodges of top of bodges, when the solution is blindingly obvious; either we develop the software needed by RISC OS users, or we abandon this platform completely. |
Leo (+3.0)
20/9/07 1:47PM |
In reply to druck:
Whilst the fetcher (Or fetchers) are running Oregano can also be busy processing the HTML, decoding images, processing Styles, executing Javascript, fetching frames, processing user input etc. So it can get a little busy. The 'number of items remaining' count can change as the HTML is processed, as if Oregano finds another IMG, SCRIPT, IFRAME or STYLE tag then the total number of items to fetch increases.
Also Oregan has never 'thrown it all away', bits may get replaced but usually for a good reason (e.g. OS specific UI replaced with a generic HTML based one, mostly static HTML3.2/CSS1 layout engine replaced with a dynamic HTML 4/CSS2 one).
In reply to jess:
Most of the platforms the browser runs on has a GUI, its the one Oregan provides... As for integrating into the RISC OS desktop, this was tricky to do whilst still keeping the code portable, but was acheived for Oregano 2. The RISC OS GUI code is mostly the same in Oregano 3, it just required some tweaks to support new platform APIs and to handle changes in how elements are represented on the page (Mostly used to work out what type of element the menu was opened over so it can fill in the appropaite 'save' information.
Couple more screenshots
http://mrdata.mine.nu:15080/O3/GoogleMaps.png
[Link: ]
And introducing OreganoSEVEN... For when SIX just isn't good enough... 
http://mrdata.mine.nu:15080/O3/OreganoSEVEN.png
|
| |
|
|
|
