@ -359,7 +359,7 @@ There is more going on, like checking for duplicate keys, but this is the core.
As of Kommander 1.3 Kommander automatically makes KParts using the libkommander_part.la. In addition to this there is a KPart plugin which allows Kommander to load plugins. Being curious developers we tried loading a Kommander part into Kommander. Why do that? Why not? The results were interesting and are demonstrated here. One interesting thing is the parent part can directly access all of the child part. While this is handy it has a down side. Any child widget being called with the same name as a parent widget will cause a lock up! In addition to that the DCOP interface is generated all over again for the part which wipes out the parent interface and disables most of the old parser functionality as well as Kommander specific DCOP to the parent. This is too difficult to fix for the remaining life of the KDE3 version. Even with these limitations and cautions this can be useful, if used carefully. The example files to look at this are in the current examples as kpartmwframe.kmdr and kpartpart.kmdr. Remember you will need the KPart plugin to fully run this example.
As of Kommander 1.3 Kommander automatically makes KParts using the libkommander_part.la. In addition to this there is a KPart plugin which allows Kommander to load plugins. Being curious developers we tried loading a Kommander part into Kommander. Why do that? Why not? The results were interesting and are demonstrated here. One interesting thing is the parent part can directly access all of the child part. While this is handy it has a down side. Any child widget being called with the same name as a parent widget will cause a lock up! In addition to that the DCOP interface is generated all over again for the part which wipes out the parent interface and disables most of the old parser functionality as well as Kommander specific DCOP to the parent. This is too difficult to fix for the remaining life of the KDE3 version. Even with these limitations and cautions this can be useful, if used carefully. The example files to look at this are in the current examples as kpartmwframe.kmdr and kpartpart.kmdr. Remember you will need the KPart plugin to fully run this example.
</para>
</para>
<para>
<para>
You can also load KMail, KOrganizer and many other TDE applications right into Kommander, of course without the problems. KHTML and KDE's file manager widgets seem not to have some functionality but there is a special KHTML plugin if you really want to incorporate a browser.
You can also load KMail, KOrganizer and many other TDE applications right into Kommander, of course without the problems. TDEHTML and KDE's file manager widgets seem not to have some functionality but there is a special TDEHTML plugin if you really want to incorporate a browser.
@ -2127,7 +2127,7 @@ Setup the <link linkend="configure-quanta">behavior</link> of &quantaplus;.
</term>
</term>
<listitem>
<listitem>
<para>
<para>
Setup the behavior of the integrated preview. <important><para>The changes made in the dialog have effects on every application using the KHTML part, including the &konqueror; web browser.</para></important>
Setup the behavior of the integrated preview. <important><para>The changes made in the dialog have effects on every application using the TDEHTML part, including the &konqueror; web browser.</para></important>
@ -5,7 +5,7 @@ This file is intented to provide some informations about the internal design of
Summary:
Summary:
1- A bit of history.
1- A bit of history.
2- Some definitions.
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.
4- Basic design and interaction with Quanta.
5- VPL Classes
5- VPL Classes
6- Synchronizations
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:
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
HTML
*-- BODY
*-- 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...)
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!
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.
5) VPL classes.
VPL has several classes, but note sometimes it is not really object oriented, but I will clean up soon.
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.
* 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.)
* 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.
* HTMLEnhancer(htmlenhancer.[h|cpp]): Derived from NodeEnhancer, it apply transformations for HTML files.
KMessageBox::information(this,i18n("Changes made in the preview configuration dialog are global and have effect on every application using the KHTML part to display web pages, including Konqueror."),i18n("Warning"),"configure_preview_warning");
KMessageBox::information(this,i18n("Changes made in the preview configuration dialog are global and have effect on every application using the TDEHTML part to display web pages, including Konqueror."),i18n("Warning"),"configure_preview_warning");
Timothy Pearson
11 years ago