In the spirit of many HACKING files that came before this one this file contains a high level overview of the QtWebKit classes and how they interact. This is meant mostly for those who want to hack on QtWebKit rather then developers who want to use QtWebKit. It isn't complete by any means, but should give you a nice overview and some hints on where to start looking when you want to enhance/fix something.
QWebView - A QWidget that wraps QWebPage, many functions just call page()->foo() or page()->mainFrame()-foo(). This class exists mostly to pass QWidget events to QWebPage. You could write a similar class using QGraphicsItem and QWebPage.
QWebPage - A web page with a pointer to QWebView if set. Contains many if not all of the webkit objects. Really this is just a class that owns a bunch of other objects. Most of webkit stuff (url, html, etc) is down in the frame and not here.
- has a QWebPluginFactory and QWebSettings
- has a QNetworkAccessManager which is typically shared among all QWebpage's
- has a QWebHistory for this page
- has a (main) QWebFrame Webkit wise it has:
- WebCore::ChromeClientQt *chromeClient;
- WebCore::ContextMenuClientQt *contextMenuClient;
- WebCore::EditorClientQt *editorClient;
- WebCore::Page *page;
QWebPluginFactory - QObject that is subclasses so developers can add plugins to QWebPage
WebCoreSupport/FrameLoaderClientQt.cpp is the one that call's create()
QWebSettings - there is one global and one per page. Contains settings such as the current font size.
QNetworkAccessManager - Qt class that gets/sends QNetworkRequest's. All i/o http etc is in here
Also contains the QCookiejar. get() is called by QNetworkReplyHandler.cpp QNetworkReplyHandler listens for finished.
QWebHistory - history for the current page. Wrapper around WebCore::BackForwardList::addItem addItem is called when there is new data from QNetworkReplyHandler::forwardData()
QWebHistoryInterface - base class that a global history manager should subclass
- historyContains() is called from WebCore::checkPseudoState()
- addHistoryItem is called from FrameLoaderClientQt::updateGlobalHistoryForStandardLoad()
QWebFrame - container of what we typically think of a webpage, a url with a data, scrollbar, etc
- has N child frames
- This is where you find the paint, print, etc functions
- contains the url, name, referrer
- has a QWebFrame *q;
- has a WebCore::FrameLoaderClientQt *frameLoaderClient;
- has a WebCore::Frame *frame;
- has a QWebPage *page;
QWebHitTestResult - used to find out what is under a point, see QWebFrame::hitTestContent(point)
- wrapper around HitTestResult
WebKit/qt/WebCoreSupport/ Virtual classes that are implemented as a way for webkit to do stuff outside of webkit such as closing the tab/page/browser or getting a url
ChromeClientQt subclass of WebCore::ChromeClient and has a pointer to QWebPage. This is how many of the calls from webkit including signals like toolBarVisibilityChangeRequested(visible); get sent up to QWebPage
ContextMenuClientQt.cpp - does nothing (who handles context menu's?)
DragClientQt.cpp - implemented using QDrag
EditCommandQt.cpp - Command for undo/redo in editors
EditorClientQt.cpp - grammar, spelling not implemented... some key handling stuff... not sure
InspectorClientQt.cpp - Makes a QWebView top level window for the inspector
FrameLoaderClientQt.cpp - implements all of the loading functionality. mishmash of stuff from creating a frame, getting the user agent, pulling up a file dialog, create plugin, accepting/denying urls.
Inside WebCore/ is the majority of the webkit logic. Various parts have implementation that hook in Qt code or use Qt code from the above classes. Most of the Qt code I have read here is small.
- focus, mouse, wheel, events
- wrapper to support the QWebPluginFactory plugins ?
- QClipboard wrapper ?
DocumentLoaderQt - not implemented
- CookieJarQt.cpp - uses the current QNetworkAccessManager's cookiejar to get/set cookies
- StringQt.cpp - wrapper for QString constructors
- KURLQt.cpp - wrapper for QUrl and provides KURL(const QUrl& url) and operator QUrl()
- SoundQt.cpp - implements systemBeep() :)
- Many more classes....
File and Class naming conventions
We try to stick with these rules for naming the classes and files specific to our port:
- Public API follow Qt conventions:
qsomething.hwith class named
- Private classes for public API classes follow Qt conventions:
qsomething_p.cpp(if needed), with class named
- Subclasses and Qt-specific implementations of WebKit/WebCore classes use Qt suffix:
- Other classes created for using in our port use Qt prefix: