[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: dependencies on KJS/KHTML in kdelibs and kdebase-runtime
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2010-09-25 18:35:19
Message-ID: 201009251135.33212.aseigo () kde ! org
[Download RAW message or body]


On Friday, September 24, 2010, David Faure wrote:
> On Saturday 25 September 2010, Aaron J. Seigo wrote:
> > KHelpCenter uses the DOM API to perform a few navigation related tricks.
> > this would need to be implemented with QDom*.
> 
> Nonsense, QDomDocument is for XML documents, not for HTML documents.
> 
> Either it can be done with QWebElement or with javascript evaluation,
> or it cannot be done on top of QtWebKit.

erf, yes, i meant QWebElement ... was thinking "dom", looking at the code in 
KHelpCenter using DOM:: and typed the wrong Qt class. :/

in any case, the use of DOM in khelpcenter is pretty limited. 

the trickier parts, really, would be the reliance on KHTMLPart for printing, 
some features like "use konqueror settings", etc.

> But in terms of "not fixing what isn't broken", khelpcenter works just fine
> on top of KHTML anyway...

KTranscript isn't broken by that definition either. the idea is to resolve a 
dependency that isn't desirable for items in kdelibs / kdebase-runtime, not 
fix things that are functionally broken.

in any case, i'm going to try to find out what's going on with this rumoured 
khelpcenter replacement, because this could all be a moot issue.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]