Help support

[Mike Hearn]

>  - 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