Modularity of DOM/JS parts

[Paul Giannaros]

On Tuesday 20 March 2007 11:30, David Faure wrote:
> On Sunday 18 March 2007, Paul Giannaros wrote:
> > Hi,
> >
> > I've been working on a project to facilitate web navigation/scraping
> > using a "real" browsing engine to handle (X)HTML/JavaScript/cookies. I
> > began using KHTMLPart with Xvfb (so that it works on X-less servers -- a
> > requirement), but that solution is proving to be increasingly finicky and
> > unextensible. A major problem is how closely it's tied to the graphical
> > side: there are constantly message boxes asking about cookies,
> > remembering passwords, kwallet asking things, etc.
> > Since then I've been looking at different engines to get this to work
> > the 'proper' way -- by seperating out the DOM/JS stuff from the graphical
> > side -- and KHTML looks like the nicest.
> >
> > How tied are the graphical and non graphical bits of KHTML? I'd need to
> > use the HTML parsing and DOM stuff, tie it with KJS, and probably handle
> > cookies myself. The (eventual) goal would be to make it work with
> > QCoreApplication.
>
> All the things you mention are in fact handled by separate programs:
> kcookiejar for the cookies, kpasswdserver for http passwords, and kwallet
> for form contents (and kpasswdserver also uses kwallet).
> So it should be quite easy to replace the calls to those things, or the
> implementation of those things, to avoid the GUI interaction.
> The form saving is probably the only one that has the messagebox inside
> khtml's code - but you can hack it out easily.

Encouraging. I had a fair read of KHTML's source to get an idea of what's 
happening yesterday, however, but was disheartened to see that even things 
like parsing documents require a reference to a KHTMLView -- If I attempt to 
instanstiate a QWidget subclass when using a QCoreApplication, things will go 
kaboom, surely?