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 :)).