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.