

In other news... Qt 4.5 is planned to support Cocoa for both 64-bit and 32-bit apps on Leopard as well. You can get the alphas from here:
http://labs.trolltech.com/blogs/2008/06/09/second-cocoa-alpha-relea...
-Yawn... o.o
There is absolutely no reason that it shouldn't be included in Qt or anywhere else.
Is there any project attempting to combine an XUL browser frontend (that would work with firefox extensions) with a Webkit backend?
http://en.wikipedia.org/wiki/Xul
That could be interesting IMHO.
Webkit passes acid test 3.
http://en.wikipedia.org/wiki/Acid3#Desktop_browsers
Edited 2008-08-13 12:55 UTC
Are you thinking about WebKit or KHTML? You do realize that many browsers are switching their backends to Webkit or at least adding an optional Webkit rendering path because it is now an excellent rendering engine and its nightlies are very exciting especially with its new JavaScript engine and HTML 5 support. The only thing Gecko has that is better than Webkit is MathML. As far as I know Webkit has no MathML support currently.
I'm getting the impression you don't know what Webkit is.
Apple didn't fork webkit, they forked KHTML which created webkit. Webkit is what Safari is using.
Qt 4.4 has an older version of webkit that they spent a while porting, and it has quite a few limitations. The last I heard, 4.5 was going to update it to the latest trunk code available and be much improved.
Edited 2008-08-14 01:05 UTC
No Apple did a code dump on the KHTML people after the initial version of Safari was released and their was much complaining about a lack of code sharing. The KHTML people then complained about just having a heap of code dumped on them and pointed out that they could share code and ideas and speed up things all around. Eventually Apple turned Webkit completely open source. I'm not sure how exactly Webkit and its components are controlled though.
Does anyone know what kind of governance model the Webkit community uses?
Currently, Webkit is a fork of KHTML but they also share some code. KHTML strives to maintain a cleaner design than Apple does so they are quite similar but different. Kind of like the difference between Ubuntu and Debian. (I realize its not a perfect analogy but analogies aren't meant to be perfect.)
This site might help answer your question:
http://webkit.org/
http://webkit.org/coding/commit-review-policy.html
Edited 2008-08-14 06:28 UTC
You have got it the wrong way around. KHTML is the origin of the codebase. Webkit and Safari are based on KHTML, not the other way around.
http://www.mozillazine.org/poll_results.html?id=2820
http://dot.kde.org/1041971213/
http://www.linuxtoday.com/news_story.php3?ltsn=2003-01-07-022-26-OS...
http://en.wikipedia.org/wiki/Safari_(web_browser)#History_and_development
"On January 7, 2003, Steve Jobs announced that Apple had developed their own web browser based on KHTML rendering engine, called Safari. ... Safari uses Apple's WebKit for rendering web pages and running JavaScript. WebKit consists of WebCore (based on Konqueror's KHTML engine) and JavaScriptCore (based on KDE's JavaScript engine named KJS)."
Apple made some improvements to the original KHTML code and were a bit tardy in giving some of those improvements back to KHTML as they were supposed to. It took a bit of reminding to get Apple to do the right thing.
"In June 2005, after some criticism from KHTML developers over lack of access to change logs, Apple moved the development source code and bug tracking of WebCore and JavaScriptCore to OpenDarwin.org. WebKit itself was also released as open source. The source code for non-renderer aspects of the browser, such as its GUI elements, remains proprietary."
Edited 2008-08-14 06:20 UTC
"if webkit is so much better than Gecko why did Apple Fork it?"
Let's turn that question around (after adjusting it for accuracy).
If Gecko is so much better than (khtml), why did Apple fork (khtml) instead of using Gecko?
The answer is out there (Apple gave it when announcing Safari), just go find it instead of fumbling around misunderstanding the issue.