Wine, Mozilla & IE ?

[Roderick Colenbrander]

Forgot to include an url to the safari developer page containing the usefull 
source code. I rechecked the license of the qt wrapper (kwq) and it looks a 
lot like a BSD license. It also seems possible to easily compile the wrapper 
to work on for example Linux. (only new makefiles are needed)

I hope this helps,

Roderick Colenbrander

On Friday 10 January 2003 21:57, Roderick Colenbrander wrote:
> 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 :)).