Next OmniWeb to be based on Safari Engine? 131
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!'"
Serious question here... (Score:4, Interesting)
Immediate development? (Score:4, Interesting)
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)
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)
OmniWeb's adoption problem... (Score:4, Interesting)
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)
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].
Omniweb not as far along? (Score:4, Interesting)
Re:A remarkably mature attitude (Score:3, Interesting)
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)
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)
steve's love for omniweb (Score:3, Interesting)
Re:steve's love for omniweb (Score:1, Interesting)
WebCore and JavaScript Core aren't about drawing (Score:1, Interesting)
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)
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)
Re:WebCore (Score:3, Interesting)
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)
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)
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)
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 >