Notes about WebCore
Notes about WebCore
- Subject: Notes about WebCore
- From: Philippe Mougin <email@hidden>
- Date: Wed, 8 Jan 2003 22:29:32 +0100
Here are some notes I took while looking at WebCore and Safari.
WebCore is an Objective-C framework (it provides an Objective-C API)
for processing and displaying web pages. To that end, WebCore
integrates the KHTML open-source technology from KDE. KHTML is
implemented in C++, and, internally, WebCore access KHTML using the
Objective-C++ compiler.
In addition, WebCore uses native Cocoa widgets for the content of the
web pages it displays: NSButton, NSTextField, NSTextView, NSPopupButton
etc. The native UI layer of KHTML use Qt and some other C++ APIs, not
Cocoa. Thus, a significant part of WebCore's job is to wrap native
Cocoa widget into Qt-like C++ objects for KHTML to use them
transparently (it does this in a module called KWQ). KHTML (and Qt) are
written in C++, while Cocoa is written in Objective-C. Again, WebCore
use Objective-C++ to bridge the two worlds easily and elegantly.
For instance here is how the "isSelected()" method on list box widgets
is bridged by WebCore between KHTML and Cocoa:
bool QListBox::isSelected(int index) const
{
ASSERT(!_insertingItems);
NSTableView *tableView = [(NSScrollView *)getView() documentView];
return [tableView isRowSelected:index];
}
What we have here is a C++ method issuing Objective-C invocations. One
can note that a KHTML list box is implemented by WebCore as an
NSTableView inside an NSScrollview (the whole thing is wrapped into a
C++ QListBox which is called by the KHTML layer).
Here is another example showing how the "setText()" method on the C++
class QButton accesses the underlying native Cocoa widget, a good old
NSButton.
void QButton::setText(const QString &s)
{
NSButton *button = (NSButton *)getView();
[button setTitle:s.getNSString()];
}
WebCore doesn't provide a complete port of KDE's API on Cocoa/Mac OS X,
only the bits needed for KHTML to work.
WebCore is an interesting example of two-way Objective-C++ usage:
Objective-C (i.e. WebCore high-level classes) calling C++ (i.e. KHTML,
JavaScript library) and C++ (i.e. KHTML through KWQ) calling
Objective-C (i.e. Cocoa widget & other classes).
Cocoa is not only used internally by KWQ for its widgets. For
instances, classes like NSTimer , NSDictionnary NSBundle or
NSBezierPath are used. Along with Cocoa classes, WebCore directly
calls-in other OS X APIs, like CoreGraphic and CoreFoundation.
The use of native Cocoa widgets provides Safari, which use WebCore,
with a native Aqua look and feel inside the web pages, all the Cocoa
niceties (check spelling etc.), much-reduced bloat, and the ability to
benefits automatically (without complex developments) from new Cocoa
improvements. AFAIK this is an important difference between Chimera and
Safari. Chimera is a Cocoa application, but its HTML engine does not
use Cocoa widgets.
Before the Safari release, Omniweb was the only web browser using Cocoa
extensively (even more than Safari), but they announced a while ago
that they were going to write their own, lightweight, UI layer because
of bad Cocoa performance when dealing with long and complex pages. It
seems that the Safari/WebCore Team has found a right balance between
performances and Cocoa usage, with some tricks like this WebHTMLView
class (an NSView subclass), which probably delegates much of the web
page layout to KHTML (personal opinion: this should not stop Apple to
invest into improving Cocoa performances, something which is badly
needed!)
At first glance, the source code of WebCore seems clean, not too
tricky, and well organized. Some parts of the code (e.g. the KDE code
itself) are documented while others come mostly uncommented. The source
code files specifically developed by Apple (i.e. not the KDE files) are
under a BSD-like open source license.
WebCore seems designed as an embeddable framework, which is quite
significant for Cocoa developers because it shall give them world-class
HTML processing and rendering capacities for their own applications.
But AFAIK, there is no documentation about it. Is it intended to be
used directly, or through a forthcoming framework? This is still
unclear for me, although the latter seems probable. Indeed, inspecting
Safari at run-time reveals that there are more web related classes here
than those provided by WebCore alone (and JavaScriptCore, its companion
package).
Best,
Phil
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.