Ender, you may be right that we might have to integrate something into the tree. Nonetheless, it scares me shitless! What happens 3 mo, 1 year down the road? KHTML is very much a work in progress, who's gonna track it? We don't have any richedit control, heck even our bog standard edit box is not finished! And for how many years now?!?
I brought up this very same argument when I first took on the task of porting it over.. however I as basically outvoted with doing the implementation as more of a wrapper than a true port :P
off of, and we have to avoid touching their sources. To this end, I think we are much better off by implementing a QT subset:
As it seem there is some effort going on to create a native Win32 KHTML port using Apple's WebCore wrapper system I think I will take a break on my current code and play with that a little. Personally I didn't want to have to take on the chore myself, but this whole Safari thing IS creating more intrest in non-X11/QT platforms... it definatly changes the playing field, and with the large speed and compatability merges from Safari lately my current tree is hopelessly out of date anyway :)
So I think I will play with that and work on the DLL layout and COM interfaces until something eventuates... I've decided it's worth waiting to see what direction KHTML takes (portability wise) now that it is being use in a 'real' non-KDE application. There's no point rushing into a WINE-specific implementation if something more closely tied to the upstream code is released meer weeks later.
Of course there still a small problem of having to seperate the code into MS compatible COM objects and DLLs... I will have to benchmark the speed impact of stubbing the MS dll's into khtml.dll/kjs.dll ecetra, instead of replicating the exports more natively.
Cheers, Ender