Understanding Konqueror

[Dirk Mueller]

On Tuesday 24 January 2006 12:54, Eva Brucherseifer wrote:

> - where in konqueror happens the loading of a web url? (the backend?)

It starts via KHMLPart::openURL which after some magic starts a Tokenizer 
(either HTMLTokenizer or a XML equivalent). The HTMLParser takes the stuff 
and creates DOM Elements (ElementImpl's or derivatives) while parsing. if all 
external stylesheet references are loaded, the DocumentImpl starts attaching 
the DOM elements at some time later, which generates the render tree. The 
rendertree relayouts itself as necessary and then triggers the painting 
(painting can also be started spontaneously if the window gets exposed etc). 

> - where is the page parsed and where does it decide to branch into
> html/css/js code?

parsing is done in HTMLParser on the element level. attributes of elements are 
parsed in the ::parseAttribute() handler of the HTMLElementImpl derivative. 

CSS parsing is completely separate. The tokenizer starts the Loader for 
external CSS references. The Parser will start the parsing for CSS or JS 
references as necessary. Another separate part is the Style selector, which 
constructs a RenderStyle object for each Rendertree object based on the 
parsed CSS rules. 

The main entry point for JS is KHTMLPart::executeScript, which will then 
descend into the JS interpreter. The interpreter has access to the already 
constructed DOM tree via the ECMA bindings (ecma/).  

> - where takes the main rendering place?

painting is started by KHTMLView::drawContents, which descents into the root 
layer (rendering/render_layer) which from that point on descends into the 
rendering tree to paint in the correct z order. Each element usually paints 
itself and its background/box as necessary (the detailed procedure is 
accurately described in the CSS specification). 

> - in font.cpp the variable scFont is not set - any idea what could trigger
> this? What does usuallly set scFont?

The style creation. (CSS Style selector and RenderStyle* as well as 
RenderObject::setStyle (which assigns it)). 

> - which of the kdesrc/dropin dirs are most important for displaying web
> pages, which ones are less important and usually not used (like e.g. dom)?

you'll have most fun with adopting rendering/font* and with the loader 
(misc/loader*). Also of interest is the KIO dropin stuff that tries to do the 
lower level of fetching sources. 

there are various debug #defines that can be enabled to isolate bugs in 
various places: 

html/htmlparser.cpp #PARSER_DEBUG if one suspects a parsing bug (usually 
seldom)

html/htmltokenizer.cpp: TOKEN_DEBUG

kjs/global.h: KJS_VERBOSE: to see what JS is executed

css/cssparser.cpp: CSS_DEBUG

khtml/khtml_part.cpp: KJS_DEBUG: to see which raw JS is executed

the debugRenderTree/debugDOMTree() actions in khtml_iface / khtml_browser.rc

rendering/render*.cpp: DEBUG_LAYOUT for debugging page layouting algorithms. 


-- 
Dirk//\