Wine, Mozilla & IE ?

Dimitrie O. Paun dpaun at rogers.com
Fri Jan 10 13:03:23 CST 2003


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

-- 
Dimi.




More information about the wine-devel mailing list