- BIG Con: The KDE libraries are GPLed. We can ask the team to perhaps
allow us to use it under the LGPL. As far as I am aware, the only reason the libraries are under the GPL is because QT is under the GPL. Since one of the major factors in using KHTML/KJS in WINE will be removing the QT dependency, I see no legal problems to it.. only a matter of if they are willing.
Unfortunately in KDE code Qt is used extensively, and I mean like everywhere. For instance Qt defines its own string classes. I don't know how much they are used, finding out would be easy enough, but you'd find it almost impossible to remove the Qt dependancies without having to go through every line of code. It may be worth talking to the KDE folks about this, whether it's really necessary for it to be GPLd or whether there is a way around that.
If not, the workaround is to implement it as an executable and just use IWebBrowser to send messages/RPCs/whatever to the executable. Using this as a general approach actually has many benefits anyway:
Yuck :( That'd be slow, and how do you get the rendered graphics back? Turning whatever rendering engine is chosen into a DLL that can be dynamically linked in is the best way imho.
: The browser can be upgraded easily, without having to worry about version conflicts against other DLLs. This is a major plus, IMHO
Upgraded by who? Remember there will probably be lots of wine-specific mods to make it compatible with IE, and those patches will never be accepted upstream, so only wine can upgrade the renderer anyway
Any IPC mechinism would simply require IWebBrowser calls to be passed from a fairly stubby DLL and COM interface to the browser. The only real modifications needed to a browser would be to understand these calls, and to be able to render to a specified GDI context/hwnd/whichever.
How does an external process render using the GDI to a window outside its ownership? In X this is handled with XEmbed.
- Pro: Startup speed is fantastic, and while Gecko is fast while loaded,
I really don't think we can use the method Mozilla uses to keep it fast (always run a configured Gecko instance in the background). I don't think WINE should have the overhead or code mess that it would cause.
Yeah, KHTML is a lot simpler and smaller than Gecko. Mozilla on Linux btw doesn't use fastload, that's windows only.
- Pro: I know that KHTML is easy to expand in the realm of supporting
other URL schemes (res:// etc will be needed in IWebBrowser). I'm not sure how Gecko's architecture works in this respect.
No, sorry, HTML doesn't deal with IO, that's part of KIO which is a separate KDE module. you just pass KHTML some markup and it goes and renders it - I don't know how you would deal with replacing KIO, depends entirely on how pluggable the code is. If KIO is a hard dependancy, then maybe KHTML isn't so suitable after all.
thanks -mike