summaryrefslogtreecommitdiffstats
path: root/khelpcenter/DESIGN
diff options
context:
space:
mode:
Diffstat (limited to 'khelpcenter/DESIGN')
-rw-r--r--khelpcenter/DESIGN16
1 files changed, 8 insertions, 8 deletions
diff --git a/khelpcenter/DESIGN b/khelpcenter/DESIGN
index bd4da5090..8cc769d82 100644
--- a/khelpcenter/DESIGN
+++ b/khelpcenter/DESIGN
@@ -220,9 +220,9 @@ regexp' or 'Search case sensitive'.
# being represented by a checkable listview item. So, we just let the user
# enter a term, replace the \{@} placeholder in the URIs specified in the
# selected .desktop files with that term, send out a request via KIO and show
-# the results in our KHTMLPart (after all KHC::View is a KHTMLPart already). A
+# the results in our TDEHTMLPart (after all KHC::View is a TDEHTMLPart already). A
# problem with this: How to display the multiple HTML pages returned by the
-# selected search engines? Using a QSplitter to split multiple KHTMLParts?
+# selected search engines? Using a QSplitter to split multiple TDEHTMLParts?
# Hmm... just wondered... perhaps we can work around that by not showing the
# returned HTML data at all but rather use a XSLT script (that is, one XSLT
# script per web search) which transforms the returned search results into a
@@ -243,8 +243,8 @@ regexp' or 'Search case sensitive'.
# can nicely drop duplicate hits, for example, or create a list of hits in the
# sidebar (much like http://www.copernic.com does). After that, we can use
# another XSLT stylesheet to transform that cleaned XML tree into HTML which
-# we then feed to our KHTMLView. Since we then have one unified output, we don't
-# need to worry about having multiple KHTMLParts, and it's also nice because
+# we then feed to our TDEHTMLView. Since we then have one unified output, we don't
+# need to worry about having multiple TDEHTMLParts, and it's also nice because
# the user doesn't see which search engine returned which hit.
# A problem with this would be that we cannot tell how a particular search
@@ -274,7 +274,7 @@ regexp' or 'Search case sensitive'.
KHC::View
---------
-KHC::View inherits KHTMLPart and does the actual job of showing some sort of
+KHC::View inherits TDEHTMLPart and does the actual job of showing some sort of
document. Most importantly, it has a slot which passes it a KURL pointing to a
document to show. KHC::View will invoke kio_help if necessary (if the URL's
protocol == "help") by itself and otherwise use the plain URL.
@@ -326,7 +326,7 @@ protocol == "help") by itself and otherwise use the plain URL.
## demand.
# My perception is that filling the Navigator's listview takes a significant
-# amount of time, just like setting up the KHTML view (loading the stylesheet,
+# amount of time, just like setting up the TDEHTML view (loading the stylesheet,
# showing the welcome page). We could easily do taht in the background - show
# the mainwindow, then tell the TreeBuilders to start populating (using a
# QTimer with a timeout of 0, for a snappy GUI). Since they're collapsed at
@@ -409,7 +409,7 @@ protocol == "help") by itself and otherwise use the plain URL.
Font Configuration
------------------
-### Many bug reports on KHelpCenter not honouring KHTML font settings,
+### Many bug reports on KHelpCenter not honouring TDEHTML font settings,
### which is odd, because the stylesheet is intentionally loose,
### specifying only "sans-serif" as the font face.
@@ -423,7 +423,7 @@ Font Configuration
### Or, fix whatever is the reason KHC doesn't follow the rules. It could
### be encoding related, the help pages specify utf-8 as the encoding, and
-### previous incarnations of the KHTML settings allowed fonts set on a
+### previous incarnations of the TDEHTML settings allowed fonts set on a
### per-encoding basis (at which time, this was apparently working, the bug
### reports dropped off, and only returned post KDE 3.0