summaryrefslogtreecommitdiffstats
path: root/khtml/DESIGN.html
diff options
context:
space:
mode:
authortpearson <tpearson@283d02a7-25f6-0310-bc7c-ecb5cbfe19da>2011-01-03 04:12:51 +0000
committertpearson <tpearson@283d02a7-25f6-0310-bc7c-ecb5cbfe19da>2011-01-03 04:12:51 +0000
commit560378aaca1784ba19806a0414a32b20c744de39 (patch)
treece0dfd7c3febf2a1adc7603d1019a8be2083c415 /khtml/DESIGN.html
parentd4d5af1cdbd3cc65d095e0afc5b1f4260091cf5d (diff)
downloadtdelibs-560378aaca1784ba19806a0414a32b20c744de39.tar.gz
tdelibs-560378aaca1784ba19806a0414a32b20c744de39.zip
Automated conversion for enhanced compatibility with TQt for Qt4 3.4.0 TP1
NOTE: This will not compile with Qt4 (yet), however it does compile with Qt3 git-svn-id: svn://anonsvn.kde.org/home/kde/branches/trinity/kdelibs@1211081 283d02a7-25f6-0310-bc7c-ecb5cbfe19da
Diffstat (limited to 'khtml/DESIGN.html')
-rw-r--r--khtml/DESIGN.html18
1 files changed, 9 insertions, 9 deletions
diff --git a/khtml/DESIGN.html b/khtml/DESIGN.html
index 00af13045..c14170ec4 100644
--- a/khtml/DESIGN.html
+++ b/khtml/DESIGN.html
@@ -9,7 +9,7 @@ dt { font-weight: bold; }
<p>
This document tries to give a short overview about the internal design of the khtml
-library. I've written this, because the lib has gotten quite big, and it is hard at first to find your
+library. I've written this, because the lib has gotten quite big, and it is hard at first to tqfind your
way in the source code. This doesn't mean that you'll understand khtml after reading this
document, but it'll hopefully make it easier for you to read the source code.
</p>
@@ -84,7 +84,7 @@ in a tree like structure. Imagine some html like
In the following I'll show how this input will be processed step by step to generate the visible output
you will finally see on your screen. I'm describing the things as if they happen one after the other,
to make the principle more clear. In reality, to get visible output on the screen as soon as possible,
-all these things (from tokenization to the build up and layouting of the rendering tree) happen
+all these things (from tokenization to the build up and tqlayouting of the rendering tree) happen
more or less in parallel.
<h2>Tokenizer and parser</h2>
@@ -168,7 +168,7 @@ explicit sharing of the DOM specs.
Another advantage is, that (as the implementation classes are not exported) it gives us a lot
more freedom to make changes in the implementation without breaking binary compatibility.
<p>
-You will find almost a one to one correspondence between the interface classes and the implementation
+You will tqfind almost a one to one correspondence between the interface classes and the implementation
classes. In the implementation classes we have added a few more intermediate classes, that can
not be seen from the outside for various reasons (make implementation of shared features easier
or to reduce memory consumption).
@@ -258,9 +258,9 @@ RenderRoot*
</pre>
<p>
-A call to of <a href="rendering/render_root.cpp">layout()</a> on the
+A call to of <a href="rendering/render_root.cpp">tqlayout()</a> on the
<a href="rendering/render_root.h">RenderRoot </a> (the root of the rendering tree)
-object causes the rendering tree to layout itself into the available space
+object causes the rendering tree to tqlayout itself into the available space
(width) given by the the KHTMLView. After that, the drawContents() method of
KHTMLView can call RenderRoot->print() with appropriate parameters to actually
paint the document. This is not 100% correct, when parsing incrementally, but
@@ -291,10 +291,10 @@ that defines the DTD to use for HTML (used mainly in the parser).
<dd>Java related stuff.
<dt><a href="misc/">misc:</a>
<dd>Some misc stuff needed in khtml. Contains the image loader, some misc definitions and the
-decoder class that converts the incoming stream to unicode.
+decoder class that converts the incoming stream to tqunicode.
<dt><a href="rendering">rendering:</a>
<dd>Everything thats related to bringing a DOM tree with CSS declarations to the screen. Contains
-the definition of the objects used in the rendering tree, the layouting code, and the RenderStyle objects.
+the definition of the objects used in the rendering tree, the tqlayouting code, and the RenderStyle objects.
<dt><a href="xml/">xml:</a>
<dd>The XML part of the DOM implementation, the xml tokenizer.
</dl>
@@ -309,7 +309,7 @@ is part of dom/* checks for this flag and throws the exception.
<p>
All the above is to give you a quick introduction into the way khtml brings an HTML/XML file to the screen.
It is by no way complete or even 100% correct. I left out many problems, I will perhaps add either on request
-or when I find some time to do so. Let me name some of the missing things:
+or when I tqfind some time to do so. Let me name some of the missing things:
<ul>
<li>The decoder to convert the incoming stream to Unicode
<li>interaction with konqueror/applications
@@ -329,7 +329,7 @@ if you don't immediately understand how it works. On the other hand, it is by no
get used a lot, that probably has the biggest number of remaining bugs (even though it's sometimes hard to
know if some behavior is really a bug).
<blockquote>
-Some parts of it's code are however <b>extremely touchy</b> (especially the layouting algorithms),
+Some parts of it's code are however <b>extremely touchy</b> (especially the tqlayouting algorithms),
and making changes there (that might fix a bug on one web page) might introduce severe bugs.
All the people developing khtml have already spend huge amounts of time searching for such bugs,
that only showed up on some web pages, and thus were found only a week after the change that