HTML Help and IWebBrowser status

[Mike Hearn]

Hi Roderick,

This was discussed about a month ago, so see the archives for more info.
Basically there was a Gecko vs KHTML debate, with Ender (who is writing
the code) eventually settling on KHTML for the following reasons:

- Simple
- No XPCOM dependancies
- Could be more easily hacked to add IE compatability (and was more IE
compatible to start with)
- Small, good for embedding, relatively fast (gecko embedding is huge)
- Would be possible to include in the Wine CVS tree as opposed to Gecko
which is probably almost as big as Wine itself.

There are obviously some pros for Mozilla as well, but the things that
make Moz a good choice for a web browser don't apply so much to a good
replacement for the WebBrowser control.

thanks -mike


On Wed, 2002-12-04 at 12:50, Roderick Colenbrander wrote:
> Hi,
> 
> Why not use Mozilla instead of KHTML? There exists an opensource activex 
> control based on mozilla which is fully compatible with IWebBrowser. The only 
> difference is that the name is MozillaBrowser. There's even a little tool 
> that can convert a IWebBrowser app to a MozillaBrowser app by changing the 
> CLSID. Likely this control can be somehow recompiled using winelib and native 
> mozilla.
> 
> Check this page:
> http://www.iol.ie/~locka/mozilla/mozilla.htm
> 
> Roderick Colenbrander
> 
> On Tuesday 03 December 2002 11:46, Ender wrote:
> > Hi all,
> > 	I'm just posting a quick update on my various WINE work for those
> > intrested.
> >
> > I currently have a working HTML Help viewer, which seems to work pretty
> > well on everything I've tested so far. It does however need some more work
> > to conform to the way the real HTML Help system works in Windows (eg, I
> > havn't written an ActiveX control for it yet).
> >
> > Currently the HTML Help viewer requires an IWebBrowser interface, and only
> > really works with an Internet Explorer installation - so I don't believe
> > it should be commited into WINE proper yet. We don't want applications in
> > our own CVS that require native dlls :)
> >
> > That brings me to my other WIP, de-QT'ing KHTML and turning it into a
> > working browser implementation for WINE. So far this is actually coming
> > along quite well, and besides a few points it definatly makes an effective
> > browser and IE compatability seems to generally be good enough to keep the
> > majority of IWebBrowser using applications happy. I've since abandoned my
> > earlier hopes to keep the changes minor (in order to make it easier to
> > backport fixes from the main KDE cvs), simply because it was making the
> > code quite messy.
> >
> > Hopefully I'll have some beta code ready in a week or two, depending on
> > how my free time goes.
> >
> > I have a few questions however, mostly I'd like to hear from Alexandre
> > on whether he'll consider accepting this into CVS. A working IWebBrowser
> > implementation is, in my opinion, a must - and my HTML Help work does
> > require it - but there are a few points to consider:
> >
> >  - It is C++. So far, all of WINEs dlls are plain C. Is this really a
> > rule, or just a result of the current areas of focus? I can't really
> > de-C++ khtml and co, but I'm unsure as to whether it's okay to add a
> > requirement for a working C++ compile environment on core dll's.
> >
> >  - It is somewhat big, several megabytes of new code. Hopefully I can chop
> > it down after removing a lot of the unneeded KDE and QT code I currently
> > have #ifdef'ed and commented out.
> >
> > Cheers,
> > 	Ender
> 
-- 
Mike Hearn <m.hearn at signal.qinetiq.com>
QinetiQ - Malvern Technology Center