Welcome to the MacNN Forums.

undotwa · May 28, 2002, 12:29 AM

I really love OmniWeb, except it's rendering engine really puts me off. Why can't the OmniGroup just implement the opensource Gecko engine instead? Chimera uses it, and I would use Chimera except that it's a new browser and quite buggy.

Instead of making your own rendering engine, which is slower, less compatible etc. why not use the Mozilla one which is simply superior?

Please tell me if I'm wrong about this.

Parvulesco · May 28, 2002, 12:35 AM

<blockquote>quote:<hr />Originally posted by undotwa:
I really love OmniWeb, except it's rendering engine really puts me off. Why can't the OmniGroup just implement the opensource Gecko engine instead? Chimera uses it, and I would use Chimera except that it's a new browser and quite buggy.

Instead of making your own rendering engine, which is slower, less compatible etc. why not use the Mozilla one which is simply superior?

Please tell me if I'm wrong about this.<hr /></blockquote>This has been discussed at length in both the OmniWeb Sneakypeeks thread and on the OmniWeb users mailing list.

Try searching there for an answer.

godzookie2k · May 28, 2002, 12:38 AM

Simple, because then it wouldn't be omniweb. It'd be chimera. (or the more boring description: "Another-Netscape-Derivative�"

me · May 28, 2002, 12:57 AM

Also Mozilla has taken, what, 4 or 5 years? I'd bet money we see OmniWeb 5 far sooner than Mozilla 2.0, and with far fewer devs.

undotwa · May 28, 2002, 08:08 AM

The rendering engine is finished, they are just fine tuning the interface.

godzookie2k · May 28, 2002, 08:17 AM

No, the rendering engine is going to be undergoing a major overhaul for Omniweb 5 according to Mr. Roe in that Omniweb Uber-thread.

ROFL · May 28, 2002, 08:41 AM

<blockquote>quote:<hr />Originally posted by godzookie2k:
No, the rendering engine is going to be undergoing a major overhaul for Omniweb 5 according to Mr. Roe in that Omniweb Uber-thread.<hr /></blockquote>He was talking about mozilla, foolio.

Omniweb using gecko would not make it chimera. It would still be omniweb, its just that it would have a rendering engine that didnt blow ass. Omniweb has a lot of great features, but with such a crappy engine I could never use it fulltime. Everytime a new beta comes out, I get it and use it for about 3 minutes until I hit a site that it chokes on. It really is too bad because its the most feature rich browser for OSX right now.

Gecko is the best engine out there, and omni not using it is just dumb. They really should put it in for omniweb 5. But really, I dont care that much. Mozilla works just fine for me, and when chimera gets more mature, I'll probably use that.

Gul Banana · May 28, 2002, 09:11 AM

No, he was talking about Omniweb 5; the new engine is already in development. There are many, many issues with the idea of using Gecko for Omniweb, and it is not 'just dumb' to not do so. This has been discussed extensively before; see those earlier discscussions for why it would be a bad idea.

Fotek2001 · May 28, 2002, 09:19 AM

I think the original argument against using the Gecko engine was that it was written in C/C++ and OmniGroup didn't see the point in writing an object oriented Objective C wrapper for a non object oriented rendering core. I'm not sure that this argument holds so much water anymore because:

1) There is already an Objective C wrapper for Gecko called Cocoazilla which is based on the Mach-O Fizilla rendering engine which in turn is based on Gecko.

2) Chimera is written in Objective C and although it's very immature, it performs better than OmniWeb's rendering engine in terms of speed and compliance with basic formatting elements like CSS and HTML 4.0.

3) Multithreading isn't everything. Omniweb is very multithreaded but this doesn't always translate to better performance. For example modem user of OW get the worst performance of almost any browser because OW is too multithreaded and tries to download everything at once.

To be honest, I'd be happy to see Omni take on the challenge to integrate Gecko into their browser. The whole point with programming in Objective C is that it's supposed to be simple to modularise functionality by building it into frameworks that can be linked to as required. I don't buy the argument that it's too difficult or that it would result in a bloated and inefficient product, I think it has more to do with pride...

[ 05-28-2002, 09:21 AM: Message edited by: Fotek2001 ]

ROFL · May 28, 2002, 11:34 AM

<blockquote>quote:<hr />Originally posted by Gul Banana:
No, he was talking about Omniweb 5; the new engine is already in development. There are many, many issues with the idea of using Gecko for Omniweb, and it is not 'just dumb' to not do so. This has been discussed extensively before; see those earlier discscussions for why it would be a bad idea.<hr /></blockquote>Like I said I really don't care that much. There's 6 or 7 browsers for OSX currently... they all have issues, but mozilla, IE, and omniweb are the only ones that are "close" to being good/complete/etc. The main issues here are that IE is not stable and omniweb 4's engine isn't any good. Not that I could write a better one. If omniweb 5's engine is good, then i'll probably use it.

So I just stick with mozilla. It never crashes, and it's rendering is fast and precise. The only issue is that the interface looks kinda weird on OSX. The price you pay for a browser that works, I suppose.

And if omniweb 4 works for you, that's great

Its just that there's a number of sites I visit that are mangled with it.

Fotek2001 · May 28, 2002, 11:57 AM

<blockquote>quote:<hr />Originally posted by: ROFL

Like I said I really don't care that much. There's 6 or 7 browsers for OSX currently... they all have issues, but mozilla, IE, and omniweb are the only ones that are "close" to being good/complete/etc. The main issues here are that IE is not stable and omniweb 4's engine isn't any good. Not that I could write a better one. If omniweb 5's engine is good, then i'll probably use it.
So I just stick with mozilla. It never crashes, and it's rendering is fast and precise. The only issue is that the interface looks kinda weird on OSX. The price you pay for a browser that works, I suppose.
And if omniweb 4 works for you, that's great <img border="0" title="" alt="[Wink]" src="wink.gif" /> Its just that there's a number of sites I visit that are mangled with it. <hr /></blockquote>I agree, I couldn't give a flying rat's ass who makes the browser or what it looks like as long as my favourite websites work (not too much to ask it it..?). For me this means either IE or Mozilla.

Having said that, it'll be interesting to see where Omni take OW in the coming months... I imagine that the stakes are going to heat up considerably as Microsoft and the Chimera team raise the bar.

People interested in this topic may fins this article at El Reg interesting:

<a href="http://www.theregister.co.uk/content/4/25451.html" target="_blank">http://www.theregister.co.uk/content/4/25451.html</a>

Parvulesco · May 28, 2002, 12:32 PM

<blockquote>quote:<hr />Originally posted by Fotek2001:
[QUOTE]Originally posted by: ROFL
People interested in this topic may fins this article at El Reg interesting:

<a href="http://www.theregister.co.uk/content/4/25451.html" target="_blank">http://www.theregister.co.uk/content/4/25451.html</a><hr /></blockquote>Unfortunately, the Register is scarcely more reputable and has no more inside information than <a href="http://www.macosrumors.com/" target="_blank">MacOSRumors</a>.

[ 05-28-2002, 12:32 PM: Message edited by: Parvulesco ]

Fotek2001 · May 28, 2002, 12:52 PM

<blockquote>quote:<hr />Unfortunately, the Register is scarcely more reputable and has no more inside information than MacOSRumors.<hr /></blockquote>They may be a bit sensational but they're nowhere near as bad as MOSR...

bmedina · May 28, 2002, 04:38 PM

It seems as if Fotek2001 has provided answers for the reasons the Omni folks had for not using Gecko. The only reason left is that the Omni guys *want* to write their own engine. But if 4.1->5.0 takes as long as 4.0->4.1, they could quickly find themselves nearly irrelevant in the Mac browser landscape.

Rickster · May 28, 2002, 04:56 PM

Why not just throw in the towel and make OmniWeb just another UI for Mozilla? Maybe it's pride, as Fotek suggests. Or maybe we think we can do better. I'll try explaining again why that might we worth our effort...

In the spirit of those Mac OS X architecture diagrams we've all seen a million times by now, here's a quick picture of what goes on in a web browser:
<img src="http://www.omnigroup.com/~rick/blockdiagram.gif" alt=" - " />

None of these parts of a web browser's "engine" is trivial: we (and the makers of other browsers) have invested much engineering effort into each.

Now, the state of affairs in OmniWeb 1.x-4.x is that the layout & display component (the green part in the diagram) is based on an architecture that made sense back in the earlier days of the web, but that turns out to be a major performance liability on modern pages. (It also makes compatibility with some web standards such as CSS-P near impossible.)

The other parts of the OmniWeb "engine", however, are based on a modular, multithreaded architecture that's unique among web browsers. That's why OmniWeb totals around 300,000 lines of code while Mozilla is somewhere on the order of 1.5 million lines. It's also why, despite taking a massive performance hit on layout & display, our performance is still competitive enough with the other guys that users are continually arguing over whether OmniWeb is faster or slower than Mozilla/IE/etc.

So, how do we resolve this issue where one component of our architecture doesn't work too great, but the rest are at the top of their game? If we used Cocoazilla, we'd get the entire Netscape engine, all the way down -- not only would we lose high-level features like best-of-breed Unicode support, we'd also be taking a step backward in terms of lower-level architecture. We could attempt to use the upper layers of Gecko in tandem with our lower-level code, but trying to interface the two completely different architectures in the middle would be a massive project. It'd take far more time and effort than rewriting our own layout & display component from scratch, and we'd still be taking steps backward in certain areas (like Unicode support).

We think we can do it better, so we're going to try -- we're already rewriting our layout & display engine for 5.0. If nobody thought things could be improved upon, there would be no such thing as progress.

Fotek2001 · May 28, 2002, 05:18 PM

<blockquote>quote:<hr />Originally posted by Rickster:

So, how do we resolve this issue where one component of our architecture doesn't work too great, but the rest are at the top of their game? If we used Cocoazilla, we'd get the entire Netscape engine, all the way down -- not only would we lose high-level features like best-of-breed Unicode support, we'd also be taking a step backward in terms of lower-level architecture. We could attempt to use the upper layers of Gecko in tandem with our lower-level code, but trying to interface the two completely different architectures in the middle would be a massive project. It'd take far more time and effort than rewriting our own layout & display component from scratch, and we'd still be taking steps backward in certain areas (like Unicode support).
<hr /></blockquote>Um, maybe an apology is in order... I didn't mean to seem too confrontational. After all, the pride Omnigroup take in their work is rewarded with it's popularity which it's well deserved. What I didn't realise is that Gecko isn't available simply as a layout engine. If you have to take Cocoazilla as a monolithic component, networking and all, then it's quite a different story and the Omnigroup strategy makes more sense.

Having said that, the fact remains that the rendering component of Omniweb is less up to speed in terms of features than its competitors like Internet Explorer and Mozilla and by speed, I mean feature completeness, I'm not so bothered by rendering time as by layout quality. The upshot of all of this discussion is that things will change and it's good to hear that the rendering and layout component is being re-vamped for version 5.0.

<blockquote>quote:<hr />Originally posted by Rickster:

We think we can do it better, so we're going to try -- we're already rewriting our layout & display engine for 5.0. If nobody thought things could be improved upon, there would be no such thing as progress. <hr /></blockquote>Well amen to that. I for one will be interested to see the fruits of this project and in the meantime, I'll still be supporting Omni by using OmniGraffle which beats the pants of MS Visio any day!

Spheric Harlot · May 28, 2002, 05:22 PM

Thanks, Rick.

OAW · May 28, 2002, 06:18 PM

Indeed as Rickster has pointed out, it wouldn't be prudent to "throw out the baby with the bath water" and simply dump their engine and replace it with Gecko. If there is only one component of the overall engine that is problematic (e.g the "layout and display" component), then it makes sense to simply rip it out and replace it with something better than to gut the entire thing. As the saying goes ...

"If it ain't broke, don't fix it."

OAW

[ 05-28-2002, 06:19 PM: Message edited by: OAW ]

Rickster · May 28, 2002, 06:32 PM

<blockquote>quote:<hr /> Um, maybe an apology is in order... I didn't mean to seem too confrontational.<hr /></blockquote>No offense taken... I wasn't so much rebutting your post as answering a commonly-asked question.

<blockquote>quote:<hr />... I mean feature completeness, I'm not so bothered by rendering time as by layout quality. The upshot of all of this discussion is that things will change and it's good to hear that the rendering and layout component is being re-vamped for version 5.0.
<hr /></blockquote>Oops... guess I didn't really cover that in my earlier post, perhaps because it almost goes without saying that if we're rewriting it from scratch we'll be rewriting it to support all current technologies.

ratlater · May 28, 2002, 10:19 PM

<blockquote>quote:<hr />Originally posted by Rickster:


The other parts of the OmniWeb "engine", however, are based on a modular, multithreaded architecture that's unique among web browsers. That's why OmniWeb totals around 300,000 lines of code while Mozilla is somewhere on the order of 1.5 million lines. It's also why, despite taking a massive performance hit on layout & display, our performance is still competitive enough with the other guys that users are continually arguing over whether OmniWeb is faster or slower than Mozilla/IE/etc.
<hr /></blockquote>Now I'm excited. Considering that I already feel that OmniWeb is the fastest OS X browser on my dual 500, and darn near the fastest on my iBook 600 I can't wait for OmniWeb 5.

There are already 3 separate OS X Gecko based projects in the works, why on earth would we need another one? If our goal as OS X users is to have the best browser available, we are much better suited by having different groups taking different approaches to the goal, rather then everyone trying to follow the same path. I'm excited to see how Chimera and OmniWeb 5 turn out, but right now I'd have to say that OmniWeb is in the lead because Chimera is dog slow with Quartz rendering turned on.

-matt

Northform · May 29, 2002, 05:41 AM

Using the Gecko engine doesn't come without its price. You have to agree to the Netscape Public Licence/Mozilla Public Licence which the OmniGroup may not be willing to abide by. Saying that OmniWeb should use Gecko is like saying that Windows should use the Linux kernel. You may feel that the Linux kernel is superior to the Windows kernel, but Microsoft doesn't want to have to open source its entire OS for something you fell is superior. I haven't read the NPL/MPL, but they do have requirements that the OmniGroup may not like (just as Microsoft doesn't like the GPL and hence doesn't use GPL code). Opensource doesn't mean that you can use it any way you want to. People license the code to be used in certain ways and not in others. Again, I haven't read the NPL/MPL so I don't know what it says, but they could require OW to be opensource if it used Gecko, they might not be able to charge licensing fees (the $29 registration) or other things.

If you like Chimera use it. Gecko is not a drop-in replacement for the back end of any old browser. The entire front end for OmniWeb might have to be redone in order to use it for all we know in which case it would become another Chimera. Software is a game of balance and personal preference. You think Chimera is too buggy so you don't like it. OW is to slow/incompatable so you don't like it. Which do you value more? The speed/compatability or the buggyness. The fact is that it would probably take just as long to adapt OW to Gecko as it would to create a finished Chimera.

Finally, there is the coding philosophy. OW was meant to target X/NeXT specifically while platform independence was the key in Mozilla/Gecko (other people have gone into greater detail over this). If you really feel that there needs to be work done on the OW rendering engine I believe that the source code for it is available (I heard this somewhere). Get people rallied behind it and make that your cause rather than tring to improve chimera or you can get people rallied around Chimera. Whatever. Hopefully someone can clear up the opensource OW rendering engine question. It might not exhist (I read it on a board somewhere, but you know how reliable those are).

Gul Banana · May 29, 2002, 06:15 AM

You might be thinking of the OmniFrameworks, on which many Omni products are based? ("based" meaning that they use them, not that all their functionality is provided by them. In other words, <strike>not all your base belong to</strike> sorry) They aren't so much "open source" as "the source is available" - I don't think anyone other than the Omni Group themselves actually work on them.

thePurpleGiant · May 29, 2002, 07:12 AM

Yeah thanks Rickster, sounds good, cleared up a lot in one quick post.

hushmail · May 29, 2002, 07:59 AM

<blockquote>quote:<hr />Originally posted by Northform:
Again, I haven't read the NPL/MPL so I don't know what it says, but they could require OW to be opensource if it used Gecko, they might not be able to charge licensing fees (the $29 registration) or other things.<hr /></blockquote><a href="http://www.mozilla.org/MPL/" target="_blank">Mozilla & Netscape Public Licenses</a>

gregomni · May 29, 2002, 03:10 PM

I want to follow up even more on what Rick was saying...

The different layers in Rick's architectural diagram all run in independent threads, with potentially multiple copies of each type of thread if (for instance) we are loading multiple pages at once or loading multiple images on a single page, et cetera.

This all funnels together into a single 'main' thread which runs both the user interface and view layout and display. As well as all the problems already mentioned with the view layout and display piece, that 'funnel' is a pretty major bottleneck to the speed up we get for our multi-threaded architecture.

We'll be fixing this when we replace that component in OW 5. The 'funnel' will essentially move up one level higher to be right below the user interface layer. Meaning, view layout and display will no longer be competing in the same thread with user interface, which should make OW more responsive.

Anyway, what I originally wanted to get at, is that even today with our outdated view layout layer, OmniWeb is very speedy compared to other browsers if you have a dual processor machine and a fast network connection. Our multi-threading architecture lets us get more done simultaneously, if your hardware and network can support it.

I see this as a bet on the future. I think cable and DSL are going to get more common, and I think multiprocessor Macs are going to get more common (including, perhaps, quad processors on the high end). OmniWeb is architected in such a way that we can continue to benefit from additional processors and additional bandwidth -- we have a lot of headroom to grow.

The other browser architectures (at least as far as we've investigated them) are concentrating on single-threaded performance, and don't appreciably benefit from multiple processors. They also don't tend to do as much network processing in parallel, so they don't take advantage of increasing network bandwidth as much as we can.

I admit it's a little hard to imagine a world in which average people do all their web browsing with a quad processor box hooked up to a megabit per second net connection, and it's even harder to imagine those people still complaining about slow web browsing in such a world. But if they did complain, it wouldn't be about our browser. :-)

Thilo Ettelt · May 29, 2002, 03:23 PM

<blockquote>quote:<hr />Originally posted by Fotek2001:

2) Chimera is written in Objective C and although it's very immature, it performs better than OmniWeb's rendering engine in terms of speed and compliance with basic formatting elements like CSS and HTML 4.0.
<hr /></blockquote>Damn! Chimera is written in *Objective-C++*!!

- Thilo

macmike42 · May 29, 2002, 03:44 PM

About the NPL and MPL: the basic gist of these licenses allows you to use the Gecko engine in any kind of product you want. You are only obligated to make any changes you make to the Mozilla source code open-source. You are allowed to keep all of your own code closed-source if you wish.

As for OmniWeb, I must say the OmniGroup crew, for the small number of people it consists of, have developed an excellent rendering engine. Sure, it has lousy JavaScript support, slightly faulty CSS1 support, and a few minor glitches here and there.

The point is that these guys are developing a completely Cocoa-native rendering engine, which works pretty damn well. In fact, on my 300 MHz G3, it is easily as fast as IE, if not a bit faster, although scrolling gets slower the more complex the page gets. Chimera on the other hand, can't compete on equal ground with OmniWeb on my machine. If Chimera has font smoothing turned on, it is much slower. If font smoothing is turned off, it is just as fast as Mozilla.

However, I must say that I'm currently designing a site that basically uses CSS1 for all formatting (except for one table which is unavoidable without full CSS2 support, which no browser offers on any platform). I use only standard HTML tags such as P, H1-6, DIV, FORM and UL/OL/LI. All of these tags have various font/color/border/margin/padding style settings which are handled as well as can be expected by every OS X browser except iCab.

Basically I am designing a "responsible" web site. I keep page sizes down with CSS and minimal image use. Every page works perfectly with anything from a 14.4 modem and Lynx to a T3 and MSIE 6.0. Guess what? OmniWeb renders the page just as fast as either of them, and even more beautifully than MSIE 6.0.

In conclusion, I would just like to say that while Mozilla is the most complete and useable OS X browser, OmniWeb would be better if it wasn't for the completely random and sloppy nature of web design. OmniGroup could stop worrying about compatibility with every poorly designed website in existance and just develop something spec-compliant. If you think about it long enough, it really is Microsoft's fault.

OAW · May 29, 2002, 05:32 PM

<blockquote>quote:<hr />Originally posted by gregomni:
[QB]
Anyway, what I originally wanted to get at, is that even today with our outdated view layout layer, OmniWeb is very speedy compared to other browsers if you have a dual processor machine and a fast network connection. Our multi-threading architecture lets us get more done simultaneously, if your hardware and network can support it.
QB]<hr /></blockquote>Greg,

I just wanted to ask you (or Rickster) about the statement above. Are you saying that the architecture of OW has no advantages over the competition unless you have multiple processors and a fast network connection? Or are you saying that OW can take better advantage of either of them ... but it really flies if you have both?

Just wondering about all us single processor Mac owners who only have a fast cable modem or DSL connection!

Thanks!

OAW

[ 05-29-2002, 05:33 PM: Message edited by: OAW ]

Northform · May 29, 2002, 06:17 PM

<blockquote>quote:<hr />Originally posted by hushmail:
 <blockquote>quote:<hr />Originally posted by Northform:
Again, I haven't read the NPL/MPL so I don't know what it says, but they could require OW to be opensource if it used Gecko, they might not be able to charge licensing fees (the $29 registration) or other things.<hr /></blockquote><a href="http://www.mozilla.org/MPL/" target="_blank">Mozilla & Netscape Public Licenses</a><hr /></blockquote>I knew where to find them; it was taking the effort to read them.

Rickster · May 29, 2002, 10:14 PM

<blockquote>quote:<hr /> Are you saying that the architecture of OW has no advantages over the competition unless you have multiple processors and a fast network connection? Or are you saying that OW can take better advantage of either of them ... but it really flies if you have both?<hr /></blockquote>The latter.

In the classical web browser architecture, various software components (image decoding, image rendering, HTML parsing, etc.) are often stuck waiting for data to arrive from the network while other components have data that they could be processing. In OmniWeb, we can actually be processing multiple tasks at once. Of course, on a single processor system, we can't really be doing two things at once, but we still tend to see some improvement because the Mach kernel's thread scheduling works so well compared to having the app make its own pithy attempt at task scheduling -- we're far more likely to be fully utilizing the CPU instead of waiting for data even though data is there to be processed.

Of course, letting the kernel do the scheduling gives us a couple of other benefits, too: We don't have to write and maintain as much of our own scheduling code, for one. And it means we'll automatically scale to fully utilize as many CPUs as are available -- whether it's one or two or twenty -- to get work done faster. (Now watch, someone's going to read this and assume Apple seeded us with a 20-processor Über-Xserve or something equally silly...

)

This architecture doesn't work all that great on slow network connections, partially because it has a tendency to gorge itself: it'll ask for as many simultaneous network connections as the CPU can handle and end up overloading the narrow bandwidth capacity. But one of the things we intend to look into post-4.1 is finding ways to have the engine more intelligently "tune" itself to make the best use of available networking resources. Should be interesting research for whoever takes it up.... I'll be busy making sure the 5.0 user experience kicks butt.

Rickster · May 29, 2002, 10:23 PM

Oops, hit "add reply" instead of "quote". Yeah, I'm literate all right.

<blockquote>quote:<hr /> Damn! Chimera is written in *Objective-C++*!! <hr /></blockquote>Don't get too excited. ObjC++ isn't really a language... it's more just a compiler frontend that lets you combine ObjC and C++ syntax in the same file. The object models are still incompatible (as they should be), but it is useful for such tasks as wrapping a Cocoa application around cross-platform C++ "backend" code because you can construct and use C++ objects within an ObjC method -- otherwise you'd have to make every C++ function you wanted to call accessible via plain-C API wrappers.

<blockquote>quote:<hr /> They aren't so much "open source" as "the source is available" - I don't think anyone other than the Omni Group themselves actually work on them. <hr /></blockquote>Actually, we do get a bit of community involvement with the <a href="http://www.omnigroup.com/developer/sourcecode" target="_blank">Omni Frameworks</a>. Not a whole lot, but we do often integrate code patches and fixes sumbitted by folks outside Omni. We've even had a few submissions from people at Apple.

bmedina · May 29, 2002, 10:59 PM

Rickster, you manage to get me excited again about OmniWeb every time I read one of your posts!

Do you yet have any sort of time frame for when we can expect early releases of 5.0?

Northform · May 30, 2002, 05:58 AM

<blockquote>quote:<hr />Actually, we do get a bit of community involvement with the Omni Frameworks. Not a whole lot, but we do often integrate code patches and fixes sumbitted by folks outside Omni. We've even had a few submissions from people at Apple. <hr /></blockquote>Hey, I know this is a little off topic, but here goes.

Are there any advantages to using the Omni Frameworks other than making life easier/saving time? Are there any drawbacks to using the Omni Frameworks (possibly compatability with future X versions until you issue an update or speed)?

I guess what I was refering to in my original post was the OWF or OmniHTML. Couldn't people jump on board here and help with the development?

By the way <thickHeaded> <a href="http://www.fakestocksite.com" target="_blank">www.fakestocksite.com</a> doesn't exhist anymore. It probably went under with all the other dot-coms. </thickHeaded.

Chuckit · May 30, 2002, 06:42 AM

<blockquote>quote:<hr /> Are there any advantages to using the Omni Frameworks other than making life easier/saving time? <hr /></blockquote>What other kinds of advantages could you get from a framework? It's just reusable code that somebody else (who is hopefully very skillful) has already written for you. It's not going to make you better in bed.

By the way, while we're on the subject of standards and improvements in OmniWeb 5 (and have the attention of Rick & crew), are there any plans to make the window tiling more like other browsers'? Having windows open completely regardless of where other windows currently are is so disorienting that I just can't stand to use OmniWeb full-time. I know it's a Cocoa thing, but it's much more glaring in a Web browser than it is in TextEdit.

Gul Banana · May 30, 2002, 08:40 AM

Regarding that, an _option_ to tile would be fine, but please don't take away my full screen windows!

hushmail · May 30, 2002, 09:34 AM

<blockquote>quote:<hr />Originally posted by Northform:
 <blockquote>quote:<hr />Originally posted by hushmail:
<a href="http://www.mozilla.org/MPL/" target="_blank">Mozilla & Netscape Public Licenses</a><hr /></blockquote>I knew where to find them; it was taking the effort to read them.[/QB]<hr /></blockquote>So you prefer to speculate about what the licenses might say, instead of spending 5 minutes finding out? Not that I'm surprised, it seems to be the norm in these forums.

Northform · May 30, 2002, 12:17 PM

<blockquote>quote:<hr />Originally posted by hushmail:
 <blockquote>quote:<hr />Originally posted by Northform:
 <blockquote>quote:<hr />Originally posted by hushmail:
<a href="http://www.mozilla.org/MPL/" target="_blank">Mozilla & Netscape Public Licenses</a><hr /></blockquote>I knew where to find them; it was taking the effort to read them.<hr /></blockquote>So you prefer to speculate about what the licenses might say, instead of spending 5 minutes finding out? Not that I'm surprised, it seems to be the norm in these forums.[/QB]<hr /></blockquote>Yeah, pretty much. I started reading the MPL, but it mas much less straight forward than the GPL (which is very well written no matter what you think about its politics) and since I wasn't really going to do anything with the Mozilla source I stopped. I thought that you had to allow (at least) Netscape to use your code, but as you pointed out it is modifications to their code not original code you use in the same app (if that makes sense - it does to me, but I usually confuse people).

Northform · May 30, 2002, 12:22 PM

<blockquote>quote:<hr />Originally posted by Chuckit:
 <blockquote>quote:<hr /> Are there any advantages to using the Omni Frameworks other than making life easier/saving time? <hr /></blockquote>What other kinds of advantages could you get from a framework? It's just reusable code that somebody else (who is hopefully very skillful) has already written for you. It's not going to make you better in bed.

By the way, while we're on the subject of standards and improvements in OmniWeb 5 (and have the attention of Rick & crew), are there any plans to make the window tiling more like other browsers'? Having windows open completely regardless of where other windows currently are is so disorienting that I just can't stand to use OmniWeb full-time. I know it's a Cocoa thing, but it's much more glaring in a Web browser than it is in TextEdit.<hr /></blockquote>Two things. With the frameworks I was wondering if it would give me added features (long shot, but just wondering).

As for the window thing: I agree. The tiling should be like IE's. It makes it much more convienient when switching between windows (and less cluttered). Even more important (to me) would be tabs though. Tabs would make the whole window positioning thing irelivant since, well, there would be tabs.

Spirit_VW · May 30, 2002, 12:51 PM

<blockquote>quote:<hr />Originally posted by Northform:
As for the window thing: I agree. The tiling should be like IE's. It makes it much more convienient when switching between windows (and less cluttered). Even more important (to me) would be tabs though. Tabs would make the whole window positioning thing irelivant since, well, there would be tabs.<hr /></blockquote>Ick - I hate IE's window tiling. If OmniWeb ever gains this, it better be as an option - and I hope the current would be the default. IE always annoys me with its window tiling.

BZ · May 30, 2002, 12:55 PM

Rick, you have done it again.

I just love reading your posts, buying / using OmniGroup's products and knowing you guys are always thinking and working on the next best thing.

My only negative would be that, since 4.1X is taking much much longer to get out the door (I remember you guys were shooting for MWSF 02) are we going to be waiting another 6/12 months to see 5 start to come around (ie, in sneaky peaks)?

Keep up the great work.

BZ

BTW: is OmniGroup coming to MWNY 02?

gregomni · May 30, 2002, 01:41 PM

<blockquote>quote:<hr /> With the frameworks I was wondering if it would give me added features (long shot, but just wondering).<hr /></blockquote>Well, the frameworks can nearly instantly give an app that uses them features like OmniWeb-style (System Preferences style) preference panes, software update, and find/replace with regular expressions. All of our apps have those things and they are all essentially 'free' just from using the frameworks.

There's a lot more, of course, but those are the most obvious user visible features I can think of...

gregomni · May 30, 2002, 01:54 PM

<blockquote>quote:<hr />Originally posted by BZ:
My only negative would be that, since 4.1X is taking much much longer to get out the door (I remember you guys were shooting for MWSF 02) are we going to be waiting another 6/12 months to see 5 start to come around (ie, in sneaky peaks)?<hr /></blockquote>Absolutely not!

What has really slowed 4.1 has been interfacing with other people's code. It's been a lot of very frustrating work with Mozilla's JavaScript code, Apple's embedding Carbon controls in Cocoa for Java, and Macromedia's/Apple's/Netscape's/everyone's netscape-style plugin architecture and the various plugins making strange undocumented assumptions about how and when and for what they use the plugin interface for.

The nice thing about 5.0 is that the place where most of the code changes are going to happen is all ours, and the layers above and below those changes are also all ours (with the exception of JavaScripting). So hopefully we'll be more productive this time around.

At the very least, we'll have no one to blame but ourselves if 5.0 takes too long, so that should be motivating. :-)

Rickster · May 30, 2002, 02:12 PM

To clarify Greg's last post:

You can expect that the amount of time between 5.0 sneaky peek 1 and 5.0 final won't be near as long as it has been for 4.1.

However, I caution you not to get your hopes up for seeing 5.0sp1 soon after 4.1 ships -- whenever one develops a new major version of a software product, there's a lot of taking things apart and rebuilding, a lot of adding new features that take a long time to implement, and a lot of deciding what new features are going to stay and what won't make it in; so it can be several months before even a pre-alpha build is worth sharing with anyone outside the company. And, first things first, as soon as 4.1 ships, we're all making Ken take vacation before he's allowed to work on anything else.

BZ · May 30, 2002, 02:16 PM

So... will be playing with a Sneaky Peak by.. "Late Summer"?

Really, keep up the great work. Can't wait for 4.1 final and for anything else you guys put out.

BZ

<blockquote>quote:<hr />Originally posted by Rickster:
To clarify Greg's last post:

You can expect that the amount of time between 5.0 sneaky peek 1 and 5.0 final won't be near as long as it has been for 4.1.

However, I caution you not to get your hopes up for seeing 5.0sp1 soon after 4.1 ships -- whenever one develops a new major version of a software product, there's a lot of taking things apart and rebuilding, a lot of adding new features that take a long time to implement, and a lot of deciding what new features are going to stay and what won't make it in; so it can be several months before even a pre-alpha build is worth sharing with anyone outside the company. And, first things first, as soon as 4.1 ships, we're all making Ken take vacation before he's allowed to work on anything else.

OAW · May 30, 2002, 04:30 PM

Rickster/Greg,

I know you guys have stated that OW 5.0 will involve a rewrite of the Layout and Display component of your rendering issue which will address the current performance bottleneck. I was wondering if you could give us some information about how (or if) this rewrite will improve the oft-mentioned JavaScript and CSS issues that haven't been fixed in 4.1?

OAW

Rickster · May 30, 2002, 05:33 PM

<blockquote>quote:<hr /> I know you guys have stated that OW 5.0 will involve a rewrite of the Layout and Display component of your rendering issue which will address the current performance bottleneck. I was wondering if you could give us some information about how (or if) this rewrite will improve the oft-mentioned JavaScript and CSS issues that haven't been fixed in 4.1?
<hr /></blockquote>The problem with the current L&D architecture is twofold: it's not just a performance bottleneck, it also makes modeling parts of the CSS spec (such as floating boxes aka layers) damn near impossible. If we rewrite it, we can design it "from the ground up" around these newer technologies. Preliminary results are quite impressive.

Most of the "JavaScript issues" stem from the fact that the rendering engine itself can't model certain aspects of a document, and so the JavaScript document object model can't access or manipulate these aspects. Also, the current architecture doesn't allow the document to be quite so dynamic: you can't document.write() once it's finished loading, etc. Again, if we're rewrite the rendering component, the limitations that affect modern JavaScript will also disappear.

<blockquote>quote:<hr />So... will be playing with a Sneaky Peak by.. "Late Summer"?<hr /></blockquote>That seems awful early to me.

[ 05-30-2002, 05:42 PM: Message edited by: Rickster ]

juanvaldes · May 31, 2002, 08:31 AM

<blockquote>quote:<hr />Originally posted by gregomni:

Anyway, what I originally wanted to get at, is that even today with our outdated view layout layer, OmniWeb is very speedy compared to other browsers if you have a dual processor machine and a fast network connection. Our multi-threading architecture lets us get more done simultaneously, if your hardware and network can support it.
<hr /></blockquote>I knew there had to be a reason OW kicks every other browser I used ass!

Dual 450 w/University bandwidth (just now got DSL), I was beginning to doubt myself at times.

BTW just noticed this right now, but say you have a text field in a page (just like the replay field) and their is a whole bunch of text (thus school bar) if you highlight the text and move the mouse down you would expect it to hit the bottom and scroll down more, but it does not. I'd guess it doesn't realize its' a window in a window.

well, just another thing I noticed that could be made better in OW. Love the browser, keep up the good work, don't worry about 5.0 when your ready to show us we will be ready to test it out for ya, just like with 4.1 <img border="0" title="" alt="[Wink]" src="wink.gif" />

and if any of this doesn't make a whole lot of sense let me state that its' 5:30am and I still have to get to sleep

petej · May 31, 2002, 09:08 AM

<blockquote>quote:<hr />Originally posted by Rickster:
[QUOTE]Apple seeded us with a 20-processor Über-Xserve<hr /></blockquote>Whoa! Imagine a Beowulf cluster of these!

unfaded · May 31, 2002, 04:16 PM

<blockquote>quote:<hr />Originally posted by bmedina:
Rickster, you manage to get me excited again about OmniWeb every time I read one of your posts!<hr /></blockquote>Hey Rick, you unknowingly created your own Reality Distortion Field :o)

Rickster · May 31, 2002, 04:36 PM

<blockquote>quote:<hr /> BTW: is OmniGroup coming to MWNY 02?
<hr /></blockquote>Yes! We claimed our booth space rather late, so we don't have a great location, but you should be able to find us next to the MUG Internet Café

<blockquote>quote:<hr /> What other kinds of advantages could you get from [the Omni Frameworks]? ... It's not going to make you better in bed.
<hr /></blockquote>I've been asked to relay that the Omni wives/girlfriends/significant-others might disagree with you, Chuckit.

[ 05-31-2002, 04:42 PM: Message edited by: Rickster ]