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!'"
A remarkably mature attitude (Score:5, Insightful)
Re:Immediate development? (Score:4, Insightful)
I would think Omni would wait until a more stable (non-beta) release is produced before changing its own browser's direction.
I've played with Safari and the biggest "Beta" issue that I have noticed is in the supporting features. The cookie management is rather crude (all/none/self are the only choices), but it does an excellent (and FAST) job of rendering pages. I would love to have my copy of OmniWeb be based on this code.
Re:Serious question here... (Score:5, Insightful)
The rendering engine in IE is a component - you can embed it into other applications... theoretically at least, you can build your own rich browsing experience around it as you see fit (as evidenced by the MSN browser vs. IE)... exactly what hooks are available to you, and therefore how rich an experience you can create, I am not familiar with...
The 'big issue' with IE source is not one of how you can re-use the layout engine, but one of not being able to fix any bugs that exist, or to extend it's basic functionality (ie. more complete implementation of standards).
Re:A remarkably mature attitude (Score:5, Insightful)
I would've thought that by itself (ie greater incentive for the user to install a 3rd party browser) would be a blessing for Omniweb - hardly being cut off at the knees.
Re:I use OmniWeb ... (Score:4, Insightful)
The Apple UI guidelines specifically disagree with you. Each button on a dialog is supposed to be a verb. Here [apple.com] is a page talking about it...
If you think about it, this makes sense. Imagine a dialog that says "You are using an outdated version of this program, do you wish to continue?" and "You are using an outdated version of this program, do you wish to exit?" If the buttons are labelled Yes/No/Cancel, I need to read the dialog carefully. If buttons are labelled "Continue" and "Exit" I am less likely to select the wrong button.
There are altogether too many times when I've triggered some Yes/No/Cancel dialog in Windows, I don't read the text carefully because I'm in a hurry, and I click 'Yes'.
Re:I use OmniWeb ... (Score:5, Insightful)
If you notice, all of the dialog box buttons in MacOS have verbs (action words) on them. Buttons are never specifically answers to questions, but are rather the action which will be taken when you click on them. For example, a traditional dialog box would say:
The proper MacOS dialog box would be something like this:
The traditional dialog box does not actually tell you what is going on when you press the button and it is easily confused with other dialog boxes that may be the same size, look the same, and have the same answers. For example, the following two dialogs could be confused and someone could accidently hit the wrong button thinking it was the dialog they expected:
A better set of buttons would be like this:
There is very little confusion there as to what action will be taken. Hit the [Feed] button and the fish gets fed, hit the [Eat] button and the fish gets eaten.
Re:Omniweb not as far along? (Score:3, Insightful)
From my limited experience with Objective-C, I don't think switching renedring engines will be that big a deal for Omniweb.
Re:Errr... (Score:5, Insightful)
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.
Re:Errr... (Score:5, Insightful)
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.
Re:WebCore (Score:4, Insightful)
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.
Re:Errr... (Score:5, Insightful)
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!
Re:Errr... (Score:5, Insightful)
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.")
Re:A remarkably mature attitude (Score:3, Insightful)
The point of a browser is to browse, not deal with the browser.
Re:WebCore (Score:3, Insightful)
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.
Re:I use OmniWeb ... (Score:3, Insightful)
Exactly. If the options had been [Don't Save] [Save] then there would be very little confusion about what action is going to be taken.
One other cool idea in human interface design is to make the least destructive action the default action in any "dangerous" dialog box. For example:
Yeah, it's a little pain to not have the [Erase] button highlighted automatically, but it's worth the safeguard considering you are talking about the potential loss of all of your data.