Forgot your password?
typodupeerror
Networking (Apple) Businesses Apple Hardware

Next OmniWeb to be based on Safari Engine? 131

Posted by pudge
from the i-want-an-open-source-tabbing-engine dept.
An anonymous reader writes "A MacFixIt article includes a quote from the Omni Group's CEO Ken Case: 'The wonderful news for OmniWeb is that Apple has based it on a fast, compatible (and small!) rendering engine which is tuned for Mac OS X, and which they are making available to the entire Mac OS X development community! [...] This means that we may be able to reach our compatibility and speed goals for OmniWeb much more quickly than when we were working alone, and then return our focus to doing what we do best: providing a rich browsing experience. Thank you, Apple!'"
This discussion has been archived. No new comments can be posted.

Next OmniWeb to be based on Safari Engine?

Comments Filter:
  • by soapvox (573037) on Wednesday January 08, 2003 @06:54PM (#5043269)
    Ok so Omniweb is going to make a browser based off of Apple and Open Source work which is cool (like chimera based off of mozilla), would windows developers build better and different browsers based off of Explorer if Microsoft were to open its source and if so how would that hurt MS, I mean chimera to me actually enhances Mozilla (love them both). Thanks for any comments.
  • by Shishio (540577) on Wednesday January 08, 2003 @07:03PM (#5043322)
    So will OmniWeb's developers begin working with Safari code now, or wait until Apple refines it? Safari is still very much a beta browser and its compatibility, one of the features Omni seems to value, needs a lot of work. As mentioned in the article, some sites crash it outright.

    I would think Omni would wait until a more stable (non-beta) release is produced before changing its own browser's direction.

    Also, what engine is OmniWeb based on now? I used to use it, and it kept up with Explorer moderately well. Safari and Chimera would blow it away, of course.
  • I use OmniWeb ... (Score:4, Interesting)

    by daviddennis (10926) <david@amazing.com> on Wednesday January 08, 2003 @07:15PM (#5043431) Homepage
    mainly because I like the way its rendering engine looks. Seems to me Omni is throwing away their main competitive advantage by using Safari's.

    I'm using Safari right now, and the only thing I don't love about it is that the text doesn't look quite as perfectly polished as Omni's.

    I'll miss OmniWeb's nicer looking text if that's really the direction they'll take.

    Safari is my favourite user interface right away. Even though I understand the old-style ones, I particularly like their slick error messages. They're written in high-quality, clear language that even a novice is going to have no trouble understanding. For a choice example, try refreshing a page with a submitted form on Safari, and then try doing it with any other browser.

    D
  • Re:I use OmniWeb ... (Score:3, Interesting)

    by Twirlip of the Mists (615030) <twirlipofthemists@yahoo.com> on Wednesday January 08, 2003 @07:18PM (#5043459)
    I agree, but compared to Chimera, Safari is wonderful. I haven't spent much time with the WebCore code yet, so I'm not sure if the Quartz stuff is in there or in Safari itself.
  • by bill_mcgonigle (4333) on Wednesday January 08, 2003 @08:09PM (#5043803) Homepage Journal
    ...has always been that they're behind the curve on standards. I don't blame them, they have a small team and do a good job with that they can render; it just doensn't render the most modern stuff.

    Their application is second-to-none, but I use Mozilla because I need to render the latest stuff (oh, and tabs). I would send in my registration fee if their renderer was current.

    This is a great move for them. If the guys who wrote their renderer are reading - you did a great job, it's just that customers ask the impossible of a small team.
  • Re:I use OmniWeb ... (Score:3, Interesting)

    by b_pretender (105284) on Wednesday January 08, 2003 @08:21PM (#5043846)
    Although I agree that the error message does an excellent job describing the error, I have a nit to pick with any dialog box that specifically asks one question and doesn't set the buttons as answers to the question.

    It's rather microsoftish. For example: Your preferences have changed. Would you like to restart to use your new preferences: [OK] [CANCEL]. Or even better, they try to word the error message around the buttons: Press OK to accept the new settings or CANCEL to discard the settings [OK] [CANCEL] rather than a much simpler: WOuld you like to accept the new settings? [YES] [NO].

  • by WatertonMan (550706) on Wednesday January 08, 2003 @08:30PM (#5043889)
    The implication of this quote is that the underlying renderer Omniweb 5.0 was supposed to have wasn't as far along as many thought. Presumably they are keeping their high level interface stuff. But to completely switch rendering engines at this stage is a fairly significant change.
  • by EccentricAnomaly (451326) on Wednesday January 08, 2003 @08:57PM (#5044038) Homepage
    The Safari BETA may be less full featured than IE, but when it ships with new Macs I have a feeling that it will be on par with IE, just much, much faster.

    I like Omniweb's features and if it was as fast as Safari and rendered as many pages as Safari I would pay for Omniweb (actually I've already paid for Omniweb).

    Right now I'm using Safari and Mozilla as a backup for the few pages that safari can't handle. IE is just too slow on my G3 to be usable.

  • Re:I use OmniWeb ... (Score:1, Interesting)

    by Anonymous Coward on Wednesday January 08, 2003 @09:13PM (#5044118)
    Thanks for pointing that out, i was about to link to that page myself, and note that button labels should almost always be verbs.
    It's nice that apple follows their own guidelines in that respect, even though they blatantly ignore the guidelines about when you should use textured windows (hint: apps like Safari and iChat shouldn't)
  • by krel (588588) <{krell} {at} {mac.com}> on Wednesday January 08, 2003 @09:57PM (#5044313) Homepage
    I'm surprised Apple didn't hire the omniweb people, they may not be the fastest, but they can do some darn fine cocoa web browsing. I understand that back in NeXT, steve used and liked omniweb.
  • by Anonymous Coward on Wednesday January 08, 2003 @10:31PM (#5044511)
    When all you've got is cat food, it tastes pretty good. There were two browsers on NeXTStep for all of about five minutes.
  • by Anonymous Coward on Wednesday January 08, 2003 @10:45PM (#5044600)
    A lot of posters here think WebCore and JavaScriptCore are about drawing to the screen. They aren't. There is another framework called WebKit that contains the Cocoa classes that bridge into the Core frameworks.

    This stuff from Omni seems pretty silly to me. If these web frameworks are made public (they are private, without header files and inside the Safari app right now), then all they need to do for OmniWeb 5 is to drop a WebView into their existing UI and toss their rendering engine. That should wipe out about 90% of their code. Why bother at that point?

    I'm a little biased against OmniWeb. As an old-time NeXT developer, one of my happiest moments was the point when I became able to use a NeXT-derived system and NOT browse with OmniWeb! Their UI design is great and broke some new ground in terms of bookmark management and search (Sherlock was a complete rip-off of their search panel that is no longer part of the app. Kind of ironic how Sherlock has been a clone of another app in two generations now!). Unfortunately, their HTML rendering was never very satisfying (4 was better though).
  • Re:WebCore (Score:3, Interesting)

    by Twirlip of the Mists (615030) <twirlipofthemists@yahoo.com> on Thursday January 09, 2003 @12:05AM (#5044927)
    Now all I have to do is convince them that the lack of type-ahead-links and type-ahead-find in web pages are truly important shortcomings in Safari

    What are those? I'm not familiar with those features.

    I'm afraid that tabs might be beyond their UI guidelines.

    There's an extremely active discussion going on over in the Apple support forum about how-- if at all-- to implement a multiple document interface for Safari. There seem to be three camps on the issue: 1) Tabs are absolutely essential for browsing, and not including them is stupid. b) Tabs are bad and wrong, but some kind of multiple-document interface would be a good idea. iii) The best way to browse the web is with the good old single-document interface paradigm: one web page, one window.

    Myself, I fall somewhere between b and iii. I think a multiple-document interface for browsing is a dumb idea-- once you look past the superficial details of how to arrange the widgets on screen, you run into a whole assload of inconsistencies and irregularities in the paradigm-- but I think so many people are clamoring for it that it makes sense to try to make it work. But I wouldn't vote for a MDI that's anything less than absolutely perfect. Better not to use MDI at all, even as an option, than to implement it in a bad or illogical way.
  • Re:Errr... (Score:1, Interesting)

    by Anonymous Coward on Thursday January 09, 2003 @12:23AM (#5044993)
    If Apple releases a new version of Safari, with an improved WebCore and JavaScriptCore, will a future OmniWeb 5 (based on WC/JSC) inherit this improvement? Or will OmniWeb need to release there own copy of the new WC/JSC?
  • Re:WebCore (Score:3, Interesting)

    by Twirlip of the Mists (615030) <twirlipofthemists@yahoo.com> on Thursday January 09, 2003 @01:21AM (#5045201)
    As far as the typing thing you described goes, I can honestly say that I've never even thought of something like that before. It doesn't strike me as something I'd ever use. I've almost always got one hand on the mouse anyway.

    With a row of tabs, I can just see everything in my working set, and then select a tab to go there (just like hitting a link in spirit).

    How is that different from the "Window" menu? Since "Window" is in the menu bar at the top of the screen, it's way easier to hit with the mouse. Two clicks (or a click-and-drag) gets you where you want to be. Granted, that's twice as many clicks as you'd have to use with tabs, but the Window menu doesn't have any of the bad implications that tabs have. There's no ambiguity between closing a window and closing a tab, for instance. You're also not limited in how long your window titles can be, because in the menu they're represented vertically instead of horizontally. When you pull down the Window menu, you get to see as much of each page title as will fit across your screen, dozens of characters at least. (When we all have 23" monitors, it'll be hundreds!)

    Look at Mozilla, or even the Apple home page that *explicitly* uses tabs as the navigational metaphor.

    Okay, if we're gonna get into this, we might as well get into it. Here's the problem with tabs.

    In Chimera or whatever, a tab basically represents an invisible view. (Here I'm using "view" in the sense of NSView, a representation of in-memory contents on the screen, with a scroll bar and stuff.) Normally a view is bound to a window. Think TextEdit here. If you open a document, you get a window that contains a view of that document. When you close the window, the view is closed, too. The view doesn't linger around.

    But tabbed browsing breaks the one-to-one link between views and windows. One window can have more than one view. In and of itself that's okay, except for the fact that no other application works like that. If I open two documents in TextEdit (for example), I get two windows. Close one, and the other stays open. Tabs don't work like that. If you close a window that contains three tabs, you lose not only the view you were actively looking at, but two other views that you weren't seeing at that moment. So you instantly have a user interface problem there.

    So to solve that problem, let's completely separate views from windows. Views are now global, associated with an application instance. Any window can display any view. (What if you assign two windows to the same view, and then click a link in one of them? Well, both windows are going to update, of course. Does that make any sense? Intuitively, no. But in context of the detached-view metaphor, yes. So we'll go with it for now.)

    So let's say you launch Safari. You get one view created for you automatically, and one window to show it to you. That view, in that window, loads your home page. But let's say you want to create a new view. (I would say a new tab, but we're not using tabs. I hope this isn't too hard to follow. It makes perfect sense in my head.) So you go to the menu and... what? What are you really doing? Creating a new view, or pushing the existing view to the back of some notional pile? What you really want to do is set the current view aside and create a new one, one that you can work with for a while before returning to this one again. How do we represent that in the form of a menu item? We could say "new view," but then you have to explain somehow what a "view" is. Remember, a view is invisible until a window is assigned to it, so "new view" really means to create something that you can't see. That's confusing. What if we approach it from the other angle? Rather than creating a new view, you're taking the one you're currently working with and setting it aside. Maybe the menu item is simply "set aside." I don't know; we can work out those details later. But this is a critical point!

    So now you've got a window with two views. You can only look at one view at a time, of course, but if you should want to see two things at once you can open another window and pick the other view. And so it goes.

    So you get to the point where you're done with one of the views. You want to get rid of it. You're not going to use it any more. What do you do? Close the window? No, remember, the contents of the window are persistent now. Closing a window doesn't make its view go away. So we have to come up with yet another new menu item. "Close view?" Yeah, I guess, but how can you "close" something that doesn't have any physical representation on screen? "Delete view?" That's not perfect either, but it'll do for now.

    So where are we? Our users are having to spend a lot of time thinking about logical entities that have no physical screen representation: views. They're having to think about creating and deleting views. The old trick of simply closing a window doesn't get it done, because we've changed the way windows and their contents are related to each other.

    All in all, it's a hell of a mess.

    On the other hand, you can do everything you want to do right now with windows. Wanna click a link, but not read the resulting page right now? Open it in a new background window. (Command-shift-click; the request is in to make this a context menu item, too.) Wanna reduce desktop clutter? Minimize windows to the dock. Wanna get to any window in a single click? Use the "Window" menu to select it by title, just as you would a tab.

    So the situation here is not a question of whether or not "tabbed browsing" (but without the tabs) would be good, or even possible. It's a question of whether it would, if perfectly implemented, provide some new feature or benefit that cannot currently be enjoyed by the users. The answer is no. So why go upsetting the whole goddamn user interface paradigm apple cart (no pun intended) to implement tabbed browsing, when it provides no new functionality?
  • Re:I use OmniWeb ... (Score:3, Interesting)

    by splattertrousers (35245) on Thursday January 09, 2003 @02:43AM (#5045475) Homepage
    WOuld you like to accept the new settings? [YES] [NO]

    Or, since people read the button text before the message text, Would you like to accept the new settings? [Accept Settings] [Discard Settings]

    Or, even better, no dialog box and just accept the settings and let the user undo if he made a mistake.

    Or, even better, no dialog box and just accept the settings, and have a little slider in the settings window that lets the user slide back in time to any settings he had ever made.

  • Re:Get this: (Score:4, Interesting)

    by BitGeek (19506) on Thursday January 09, 2003 @03:11AM (#5045556) Homepage

    He is being silly, Mac users make up closer to %45 of the consumer market.

    IF you were meant his number was too high-- well, its worth noting that it is a far more supported number than the claim that they only make up %5 of the market-- an out right lie, and fabrication that has no basis in reality.

    The Nazis found that if you repeat the same lie often enough, people start believing it-- so we have the same thing here-- Windows is "%95 of the market", taxes are not theft, social security has a "trust fund", the government helps the poor (poverty is government's greatest triumph) etc.

    And all these statements sound absurd to people who believe what they are told to believe-- even when these beliefs contradict objective reality. And they do.

    Its amazing how well that works, though.
  • Re:WebCore (Score:4, Interesting)

    by ealar dlanvuli (523604) <froggie6@mchsi.com> on Thursday January 09, 2003 @05:30AM (#5045835) Homepage
    After using Safari for a day, my view of tabs has completely changed. This is the first non tabbed browser I have used that allowed easy creation of new windows (apple+click or apple+shift+click) when following new links. It is also the first browser I have used that doesn't use a meg and a half of memory per window, or take longer than a 10th of a second to make a new window. With these features, tabs become redundant in Safari, I'll explain why below.

    If you really think about it, tabs are an optimization seeking a metaphor. Origionally tabs were added when making a new browser window was a > .4 second affair, and really ate on the system resources. Also switching between windows in the same app on may operating systems is a nontrivial task. On osx one can simply use apple+` to switch windows in the same app. Tabs are really an optimization so you only have to have "one window", they are not in any way a document organization metaphor. How many times have you actually organized similar tabs in the same window? I'm guessing never. How many tabed browses out there even let you drag tabs between windows? I'm not noticing many. The real benifit of tabs are load-behind loading, and load-on-middle click. The other benifit is "group bookmarks". None of those traits are specific to tabs. I conclude then that the overwhelming love of tabs has more to do with the redicioulus cost of multiple window interfaces in most browsers/os's that are not relevant to Safari/osx. Thus it would be in apples best intrest to leave them out, and make the interface the most efficent web browser out there!

We have a equal opportunity Calculus class -- it's fully integrated.

Working...