Re: No way...
Originally posted by sergeantmudd
Just a couple points
1. iTunes does not use WebCore. People have proven it by showing linked frameworks and you don't need a full rendering engine to render a handful of pages all put out by Apple.
Personally, I don't buy it. Yes, iTunes4 is (obviously) not using WebCore as a shared library (if it were, it would have to include it in its resource bundle as WebCore is not an OS shared library yet! You don't need to list all the dylib data on iTunes to see that!)
That doesn't mean that the presentation code from WebCore was not statically linked into iTunes though. Using the WebCore shared library would have meant that iTunes would either have to put a copy of said shared lib into the system (can not rely on Safari being present, and Safari uses a "captive instance" of the shared library within its resource bundle) or contain the entire lib (3.3MB in Safari). Either way, this adds 3.3MB to the download (possibly more if other Safari frameworks were used). If iTunes instead compiled against the WebCore code statically, gcc could remove unused code and leave only those portions which iTunes actually uses.
Thus, there is a more than feasible method for iTunes4 to be using WebCore, and here's the motive: rewriting code is bad. If Apple is not reusing their own code, they are in very sorry shape developmentally. Given the software they've put out, I do believe that they have some engineers working there with a head on their shoulders. Reinventing the wheel for no cost gain is bad, very bad. Entire development teams have lost their jobs for less.
2. KHTML on Windows is a bad idea. KHTML is heavily dependant on the Unix way of doing things. I am not a computer science major, but KHTML is written specifcally for the strucutre of a Unix operating system. Hence it's speed. IF possible, I would guess the speed of KHTML for Windows would be about the speed of IE for Mac.
Huh? What exactly is the "UNIX way of doing things" from a developer's perspective? I mean, UI and configuration issues aside (which don't in themselves affect performance), why would KHTML/Windows be different from KHTML/Linux? KHTML relies on the Qt system libraries (KDE basis), which exist (although for a fee) on Windows and, last I heard, ran quite well on Windows.
3. Safari or KHTML? Say Apple was able to port KHTML, what good would it do. Not too many Mac users love Konquerer. We don't love the engine, we love the browser. And the browser needs Cocoa. The front end is heavily heavily dependant on the Cocoa frameworks. And the Cocoa frameworks are not available for Windows. The amount of work necessary is tremendous. So even if Apple ported KHTML, the Safari experience is not available.
The thinking (not saying it is correct

goes that if Apple is porting a huge chunk of Cocoa to Windows (necessary for iTunes4, so the thinking goes) then it might as well use this development effort in more than one product.
And, IMHO, what
I love about Safari is not the Cocoa interface (although I don't mind that!) or the engine itself (although it is shaping up to be one of the best for standards compliance, and its performance is great!), but the fact that it gives Apple an "in" do innovate in the browser space. Snapback, while no replacement for tabs, is a very nice feature. The bookmarks pane, IMHO, is an improvement in bookmark management. I expect to see more UI innovations coming from Apple here, and those innovations are just as likely to bear fruit on Windows as on OS X.
4. Tabs are not needed for IE, because the task bar is basically tabs already. Not perfect, but for most people good enough. When I use a PC and IE, I browse with IE's window full screen. If I open a new window, it gets its own tab in the taskbar. To switch all I need is a mouse click. Same thing as tabs, just implemented system wide.
IMHO, completely different concepts. Tabs allow grouping. The Windows Task Bar has no grouping cpabilities whatsoever (except "by application", making all windows of a particular app into one button with a hidden menu to get the actual windows). By the same reasoning, tabs are not important in Safari because a right-click on the Safari icon in the dock lets me switch instantly to any Safari window.
Tabs are organizational, not just "single-button window switching".
That goes without saying

But that doesn't mean we can't have a great application on there!
I am 95% certain on all I have said. But I have been and will be wrong. I will try to find links to back up the Unix structure stuff.
I look foward to reading it ...