Wine folks interested in a CHM spec?

Mike Hearn m.hearn at signal.qinetiq.com
Wed May 28 06:19:42 CDT 2003


On Wed, 2003-05-28 at 11:56, Ender wrote:
> I've already written the major chuck of a CHM viewer - to the point I have
> a native Windows viewer using nothing but the WebBrowser ActiveX control.

This would be a good thing to submit anyway. It's been possible (though
not easy) to install IE into Wine for some time now. If this is all it
takes to get CHM support up and running then this is cool - we don't
want to block CHM help on needing a webbrowser control.

> The secondary problem is how to display the HTML + JavaScript needed for a
> CHM viewer. I've started work on this several times, and so far the *best*
> (in terms of existing compatability with IE's CSS/JS/HTML 'features') has
> been KJs and KHtml from the KDE project.

> Gecko doesn't cut it - it's quite slow, bulky and worst of all too strict
> on standards compliance. Nothing you want in a Windows system component.
> Well, not the last one anyway :)

I've been reconsidering this lately. Originally I argued for KHTML, for
the above reasons. They are still valid, but we overlooked the issue of
editing support. My recent work with IE in Java (where IE is used as an
embedded html-enabled word processor) has made me realise that this
feature is used a lot in corporate scenarios. You'd be surprised at the
number of IE-specific web apps that utilise the contentEditable feature
of the rendering engine. KHTML simply does not support this as far as I
know, and I have no idea how easy it'd be to make it support it. Gecko
does. This is a significant + in favour of Gecko.

On the other hand, I'm not doing the work, and forking KHTML is probably
easier than Gecko. Adding editing support to KHTML would be quite a bit
of work, but still maybe less over all.

> However KHTML and KJS -are- tied to the QT library. It's quite possible to
> decouple them (the embedded konq suite already does this to some extent,
> as does WebCore from Apple's Safari project)... however it is somewhat
> time consuming. Using WebCore can probably greatly speed this up of
> course.
> 
> I ran into two other problems. First, I have gotten a Windows-native
> KHTML/KJS viewer running - however splitting it into an API mapping to the
> existing dll structure is complicated... and I know next to nothing about
> writing ActiveX objects.

Simply getting KHTML/KJS working under Win32 is a great start. Are the
patches for this available anywhere online?

> The second is that I never could get an answer from Alexandre as to adding
> C++ code to WINE itself. It would be possible to write it as a seperate
> non-core implementation, but many of these DLLs also have non-browser
> related APIs that need to be in WINE itself. Again, diverting api calls
> between the versions in WINE and our browser versions is complicated and
> in this case plain ugly.

I think if it was a choice between accepting C++ into the tree, and not
having a large set of crucial APIs in Wine, AJ would accept C++. But I
don't speak for him.

For some of the DLLs/objects that IE provides I guess C could be used,
that isn't really a problem, IE provides a load of stuff that pure
KHTML/KJS doesn't and that would probably be provided by core Wine in C.

If it comes down to it, a WineTrident installer that is tested against
and known to work with Wine would be possible. It'd be highly annoying
for users to install it separately, but that's something good packaging
can take care of.

> Anyway, that's all rather off-topic... we can already build a CHM viewer,
> it's displaying the HTML/JS that's the problem :)

Good to know you're still around! Simply getting a super-basic
WebBrowser implementation up and running, in Wine, no matter how it's
built/installed would be a good first step.

Writing COM objects in C is a PITA but not all that hard, although if I
remember correctly ActiveX controls have to implement about a gazillion
interfaces which could get painful. Anyway, I think Wine supports COM
objects written in C++, it's in the documentation somewhere.

-- 
Mike Hearn <m.hearn at signal.qinetiq.com>
QinetiQ - Malvern Technology Center




More information about the wine-devel mailing list