Why don't look at the stuff Apple made for their khtml wrapper? They made two components to interact with khtml. One javascript wrapper (JavascriptCore) and another component containing some sort of QT wrapper called WebCore. The license of WebCore looks LGPL compatible (not 100% sure), so perhaps it is possible to reuse the stuff they made.
When khtml gets an update they can plug it in this framework and it should work. (theoraticly)
On Friday 10 January 2003 20:03, Dimitrie O. Paun wrote:
On January 10, 2003 06:45 am, Ender wrote:
The current state of my local tree, besides being a mess, is that it has most QT dependencies removed. Currently it uses a lot of QT stub's around WinAPI functions that I wish to remove before doing much more work with it.
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?!? Just for curiosity's sake, can you give us a wc -l of the KHTML stuff?
If we do have to integrate something, I think we *have* to have a way to track the KHTML development. Just throwing something in the tree may actually be detrimental, if it remains unmaintained. To be able to track the KHTML development, we need to keep track of the revisions we worked 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: -- It should be a lot stabler than the KHTML stuff. It seems to me QT hasn't change that much from the 1.0 days, now it should be close to a libc in terms of interface stability. -- I haven't looked, but I assume KHTML can't use that many difficult to implement QT features -- Having a free QT/Windows implementation is generally useful to a lot of people, so we're likely to get more people to help If our changes to the KHTML source are minor, I am certain the KDE people will help us by integrating them upstream. If in time we can work off of the same code base, we can simply delete our copy from the Wine tree.
There might be another way. Now that Safari is out and it's deQTfied, and having more and more people interested in KHTML, the KDE folk may decide to officially switch to a QT-free KHTML version, in which case we'll be saved the trouble of implementing a WQT (pronounced wicked :)).