1 files changed, 5 insertions, 5 deletions
diff --git a/quanta/parts/kafka/DESIGN b/quanta/parts/kafka/DESIGN
index 2f9537a2..824ab4bb 100644
--- a/quanta/parts/kafka/DESIGN
+++ b/quanta/parts/kafka/DESIGN
@@ -5,7 +5,7 @@ This file is intented to provide some informations about the internal design of
 Summary:
 1- A bit of history.
 2- Some definitions.
-3- A quick overview of the Quanta/KHTML stuff interacting with VPL.
+3- A quick overview of the Quanta/TDEHTML stuff interacting with VPL.
 4- Basic design and interaction with Quanta.
 5- VPL Classes
 6- Synchronizations
@@ -45,7 +45,7 @@ HTML
 
 
 
-3) A quick overview of the Quanta/KHTML stuff interacting with VPL.
+3) A quick overview of the Quanta/TDEHTML stuff interacting with VPL.
 First, the most important thing: the parser. Defined in the quanta/parser/ directory, it is composed of the Node class, the Tag class, the Parser class and the QTag class. The parser reads and parses (Parser::parse) or rebuilds from an already parsed document (Parser::rebuild) a Node Tree, which is basically a DOM like representation of the document, but even closing Tags and empty text are represented (as well as server side scripting elements like PHP.) In fact, everything is put in the tree so that we can get back the original SGML/XML file from the tree. From now, I call it the Node tree. For example <html><body>text<img href="boo">  </body></html> has for Node tree:
 HTML
  *-- BODY
@@ -57,7 +57,7 @@ HTML
 The Node class handle the pointers to the parent, next, previous and first child Node. *Each* Node has a valid pointer to a Tag. The Tag takes care to remember all the information concerning the Tag itself, like the attributes, the type, etc...)
 One QTag per Element is created from the .tag files when Quanta is started. Each QTag contains all the DTD information about the Tag. E.g. the "IMG" Qtag says that it is a single Tag, and what are its attributes. You can get a QTag with QuantaCommon::tagFromDTD, but don't delete the QTag!
 
-Now to tdehtml. The class KHTMLPart is the HTML renderer widget of konqueror. It internally works with a Node Tree (another? Yep!) but these Nodes are real DOM::Nodes. (From now, I will call it the DOM::Node tree) Each of the DOM Nodes is tdehtml-internally linked to a rendering Node i.e. a change made to one DOM::Node will update the HTML rendering cf /path/to/kde/include/dom/*.h and also in the tdelibs cvs module, cf the nice tdelibs/tdehtml/DESIGN.html. WARNING about DOM::Nodes, they are just interfaces!!
+Now to tdehtml. The class TDEHTMLPart is the HTML renderer widget of konqueror. It internally works with a Node Tree (another? Yep!) but these Nodes are real DOM::Nodes. (From now, I will call it the DOM::Node tree) Each of the DOM Nodes is tdehtml-internally linked to a rendering Node i.e. a change made to one DOM::Node will update the HTML rendering cf /path/to/kde/include/dom/*.h and also in the tdelibs cvs module, cf the nice tdelibs/tdehtml/DESIGN.html. WARNING about DOM::Nodes, they are just interfaces!!
 
 
 
@@ -73,7 +73,7 @@ Then when a change is made to the source file, Parser::rebuild is called and syn
 5) VPL classes.
 VPL has several classes, but note sometimes it is not really object oriented, but I will clean up soon.
 
-* KafkaWidget(kafkahtmlpart.[h|cpp]): Derived from KHTMLPart, it uses the caret mode implemented by Leo Savernik in tdehtml (that means we don't have to care about cursor navigation). It handles every keypress in order to edit the widget (backspace/delete/return/<insertion of a letter>) and modify only the DOM::Node tree (not the Node tree).
+* KafkaWidget(kafkahtmlpart.[h|cpp]): Derived from TDEHTMLPart, it uses the caret mode implemented by Leo Savernik in tdehtml (that means we don't have to care about cursor navigation). It handles every keypress in order to edit the widget (backspace/delete/return/<insertion of a letter>) and modify only the DOM::Node tree (not the Node tree).
 
 * KafkaDocument(wkafkapart.[h|cpp]): It takes care to load the DOM::Node tree from the Node tree, and when a change is made to the DOM::Node tree, it apply it in the Node tree. It basically takes care of the synchronization of the trees.
 
@@ -83,7 +83,7 @@ VPL has several classes, but note sometimes it is not really object oriented, bu
 
 * kNodeAttrs(nodeproperties.[h|cpp]): We can easily put a link to a DOM::Node from a Node in the Node class, but the opposite is impossible (we can't derive them). So we have a link DOM::Node => kNodeAttrs => Node (thanks to a QPtrDict). And we also have some informations about the way to handle this node when editing VPL. (Be careful, one Node can be linked against several Nodes. See after.)
 
-* NodeEnhancer(nodeenhancer.[h|cpp]): It is an interface class. Its aim it to "transform" or "enhance" DOM::Nodes when DOM::Nodes are synchronized from Nodes. Sometimes it is to add some style (e.g. adding a red dotted border to FORM elements) but sometimes it is essential (e.g. KHTML won't accept a TABLE without a TBODY even if it is DTD valid, so we had to manually add a TBODY. It explain why some Nodes can point to more than 1 Nodes.)
+* NodeEnhancer(nodeenhancer.[h|cpp]): It is an interface class. Its aim it to "transform" or "enhance" DOM::Nodes when DOM::Nodes are synchronized from Nodes. Sometimes it is to add some style (e.g. adding a red dotted border to FORM elements) but sometimes it is essential (e.g. TDEHTML won't accept a TABLE without a TBODY even if it is DTD valid, so we had to manually add a TBODY. It explain why some Nodes can point to more than 1 Nodes.)
 
 * HTMLEnhancer(htmlenhancer.[h|cpp]): Derived from NodeEnhancer, it apply transformations for HTML files.