Slashdot Mirror
Next OmniWeb to be based on Safari Engine?
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!'"
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.
The one response you'd never expect from a commercial company that was just (superficially) trumped by a platform vendor: Gratitude. Kudos to Mr. Case for recognizing the long term potential and not griping about 'being cut off at the knees' or other shortsighted objections.
An object at rest cannot be stopped!
Nearly everything you said is wrong.
1. Yes, Safari is free. No, it is not open source. WebCore (which is KHTML plus some other stuff) and JavaScriptCore (which is KJS, more or less) are open source, and you can download them from here. WebCore is basically a software component, not an application.
2. OmniGroup is excited because Apple has given the OS X developer community a solid, fast, and very (though not yet perfectly) compliant HTML component. This will allow OmniGroup to write OmniWeb 5 (or whatever) around WebCore and JavaScriptCore-- which takes care of turning HTML into stuff on the screen and handling the JavaScript runtime and whatnot-- so they can spend all of their time and effort on the features. This is basically the story of Mozilla, Chimera, and Phoenix, and others. One rendering component, lots of apps built around it to suit different needs.
3. OmniWeb has some cool features that frankly don't belong in Safari: built-in regular-expression URL filtering, for just one example. Some kind of MDI ("tabbed") interface could possibly be another.
4. OmniWeb has never "force fed you banner ads." It's just a browser. You can use it for free, but OmniGroup prefers that you pay for it. No big deal.
Are we a little more clear now, at least?
I write in my journal
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.
Twelve fingers or one, its how you play. ~Gattaca (Vincent)
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
...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.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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.
"OmniGroup is excited because Apple has given the OS X developer community a solid, fast, and very (though not yet perfectly) compliant HTML component."
Well, uh, KHTML is already under the GPL. Shouldn't these guys be thanking the KDE Project for writing the code in the first place?
In fact, since Apple based WebCore/JavaScriptCore off GPL code, they must make the code public. I'm not so sure that they would have released the code back to the community if it was under a BSD-style license.
Don't get me wrong - I think it's great when corporations enhance existing FOSS projects. I just think that the gratitude is misplaced in this instance.
Well, uh, KHTML is already under the GPL. Shouldn't these guys be thanking the KDE Project for writing the code in the first place?
Sure, appreciation all around. But from OmniGroup's perspective, what Apple did was more significant. (Not more important, not better, just literally more significant.) Apple removed the dependency on Qt and created an Objective C API for KHTML. That was a ton of work, not to be underestimated. Without it, KHTML wouldn't have been of any use to any Mac developer.
In fact, since Apple based WebCore/JavaScriptCore off GPL code...
Let's be precise. KHTML and KJS (and by extension WebCore and JavaScriptCore) are LGPL, not GPL. This is an important distinction. If either of those components had been GPL only, Apple would not have been able to use them.
I write in my journal
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.
karma: ouch!
Thanks for the link; Hyatt's blog gives some info on what kind of CSS support should be there (much of CSS2 and bits of CSS3), what the status of XML rendering support is (not yet), and that, yes, a bug they just fixed did prevent it from running the CSS1 test suite at w3c.org. 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...I'm afraid that tabs might be beyond their UI guidelines.
Babar
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.
I write in my journal
You get these in Mozilla. Imagine you're looking at www.yahoo.com. There are hundreds of links, and you can visually scan them easily. Now to choose the one you are looking at...you have to take your hand off the keyboard, and hit a relatively tiny link with something shaped too much like a hockey puck. Or you could just type some of the text in the link, and have Mozilla highlight it for you, hit return, and the browser will follow the link. This might sound weird, but I insist that you try it in a recent version of Mozilla. Once you've seen the light, you don't want to go back. It's that good. Notice that unless a text widget or the location bar has the focus, typing text does nothing usually, so doing so is (I think) a fairly intuitive act. Type ahead find in the page is...perhaps less intuitive unless you're a vi or "less" (the pager) junky. If you type /perfect (with the slash), you're asking Mozilla to find the text "perfect" anywhere in the page and go there. That's a micro-optimization of cmd-f, really. I like it, but it doesn't ruin my life not to have it.
OK, so I suppose it's possible that there is a better UI notion than tabs waiting to be discoverd to do multiple-document interfaces, but choice iii is just insane. Look, if tabs bother you, then I guess you don't like multiple links on a web page either. In my mind, it's basically the same kind of thing; you want to see where you're likely to want to go and be able to make it happen with a minimum of fuss. Sure, I could cmd-~ my life away through a bunch of windows, but since most of them would be hidden, I can't easily tell what is there. 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). A secondary nice thing about tabs is that I personally use them to organize my browsing. Often, I have one window full of tabs that point to results of various BLAST searches on NCBI, another window with tabs that point to my course web pages and stuff like that, and third window that has stuff like, well, slashdot on it. Easy to go from window to window, and then from tab to tab; voila, my very own hierarchical web interface and no hands ever leave the keyboard. :-)
Look at Mozilla, or even the Apple home page that *explicitly* uses tabs as the navigational metaphor. The Apple home page looked weird for about 30 seconds, but then my only complaint was that the tabs were just a fakey image hack.
Well, sure, a bad implementation would suck. :-) But I really don't want to get into a situation where the perfect is the enemy of the good. There are some issues with the current Mozilla tab interface (cntrl-page_up to cycle through them is not a terrific choice), but I'd fix the obvious problems and put it in as an option in the Beta. They would get feedback on the feature, and I'd be surprised if it were less than strongly supportive.
Babar
Depends.
/System/Library/Frameworks, you'll find stuff like AppKit.framework, which every application on your computer (Cocoa, anyway) links to at run time. If Apple puts WebCore and JavaScriptCore (and maybe WebKit) in the operating system-- in other words, puts them in /System/Library/Frameworks in a future version of OS X-- then programs like OmniWeb will be able to link to them at run time. Future improvements to those frameworks will apply to those programs automatically.
;-)
WebCore.framework and JavaScriptCore.framework work like DSO's or DLL's, if that means anything to you. The difference is that a framework can be bundled inside an application or available externally. If you look in
But as of right now, WebCore and the others aren't part of the OS. They're bundled right inside Safari. If Apple decides to leave them out of the OS, then OmniGroup will still be able to use them, but they'll have to distribute the frameworks inside of the OmniWeb package. In that case, updates to the frameworks would have to go from Apple to OmniGroup to the user.
I imagine Apple is going to make WebCore et al. part of the operating system real soon. It's just too darned useful; even apps like Project Builder need to be able to parse HTML to display documentation and whatnot. The million-dollar question is whether they're going to do the same thing with WebKit. If so, expect to see about a hundred special-purpose Cocoa web browsers for OS X in the first week after release. It'll be so easy to write your own web browser, what with PB and IB and all, that you'll hardly be able to avoid it!
I write in my journal
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?
I write in my journal
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.
Yeah, and you guys panned the ipod too: http://apple.slashdot.org/article.pl?sid=01/10/23
I'm not so sure that they would have released the code back to the community if it was under a BSD-style license.
Well, that's a silly concern since they realeased their commercial operating system even though it wasn't under the BSD license- it was owned by them free and clear.
How soon people forget that Apple is the first, and so far, only company to open source its commercial operating system.
And not only does it help scores of open source projects around the world (as well as make use of them- after all that is the POINT of open source) but it does work to make it so that people who want to can run completely Open software on their platform more easily without paying apple any money,-- by supporting X11, and other stuff they don't ahve to that goes against their bread and butter OS sales.
Gee, I wonder why. They sure are GREEDY those bastards!
And yet all you Open source self-proclaimed advocates still hate them. could it be that you really don't care bout open source so much as you love linux? (Not bashing you, Phexro, just the broader group that irrationally hates apple becuase it "doesnt support open source.")
Yeah, and you guys panned the ipod too: http://apple.slashdot.org/article.pl?sid=01/10/23
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.
.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!
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 >
I live in a giant bucket.
Safari has a number of UI elements that replace tabs. Snapback in the address field and search fields takes you back to where you started surfing. You can also drag links to the Bookmark bar and then drag them off again easily, like a little shelf. The little book icon on the left of the Bookmark bar switches the window to a view of your Bookmarks and History, like lifting up a page to look at a TOC. Plus, it is FAST. I find myself just surfing rather than opening up a bunch of windows because pages appear instantly.
Also, the menubar is pervasive, so the History and Bookmarks menus are right there all the time in the same place. Safari also shows the URL's in your Address Book in the Bookmarks menu, so even without tabs, you find yourself having lots of clickable links right away, and plenty of room to put more.
It's a great browser.
The advantage of tabs is enormous, and the only complaint I've heard is closing the window will lose many of your tabs. It's something you learn not to do, by and large.
You claim that no other Apple application uses Tabs, but you might want to load up Project Builder sometime to see that it's not really true. Tabs are useful in certain circumstances, and one of those circumstances is when you have a lot of information that you don't necessarily need side by side. The web is perfect for tabbing.
The paragraph about 'new views' and such? It means nothing to a user. It may be confusing to program, but so what? It's really, really useful. If you want to know the best way to program it, start with Chimera's implementation.
Of course, the best thing Apple could do for the success of Chimera is to not add tabbed browsing. Whatever other features, speed, or stability they might add, I and many others will go back to Chimera if Tabbed browsing isn't added to Safari.
=Brian
There is nothing so good that someone, somewhere, will not hate it.
I completely agree, and one of Omniweb's sweetest features to me is it's ability to open links behind your current window.
Safari can do this, too. Command-shift-click a link. OmniWeb has the feature in a context menu, unlike Safari, but that's the only difference.
(I may have mentioned this before. Pardon me if I'm being redundant; I just woke up.)
I write in my journal
Wow. I had never looked at tabs this way before. Truly, Safari's window creation speed and ease of switching does make them much less necessary than they are in slower, clunkier browsers.
My feeling is that tabs are a feature that the average user is going to have difficulty understanding. I think Apple will implement this feature as turned off by default (and thus absent from the UI of each window) unless you specifically turn it on. 'Power' users will probably be satisfied by this, but as you so cleverly pointed out above, it is mostly unnecessary for Safari. I have been using tabbed browsers for over a year now but that does not mean I am not prepared to abandon them for a browser that does multiple windows right!
Here I disagree. And I suspect we will continue to do so, but I neglected to mention this on my first post. The window menu doesn't allow you to see, at a glance, what sites you have up and active. And, in Mouse Time, click-drag-un/click takes a whole lot more time than just click. If there were, say, a floating palette of the currently active windows, that would almost be as good, but that takes up a lot more screen real estate than tabs.
Project Builder never puts two separate projects into the same window. Ever.
No, but it does allow you to have different documents within that project to be in the same window. You can flip between different source files and they show up in the same window. It's the same thing as tabs, but just using a file list instead of an actual tab.
Speaking of, it's also similar, conceptually, to the preview pane used in mail programs (such as Mail). It's a view that shows different documents in the same space, which is changed by the click of a button on an element that represents what the view will contain. It just uses a list rather than tabs, just like Project Builder.
=Brian
There is nothing so good that someone, somewhere, will not hate it.