diff options
Diffstat (limited to 'khelpcenter/DESIGN')
| -rw-r--r-- | khelpcenter/DESIGN | 16 |
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 |