I'll just add my specific reasoning (plus pro's and con's) for supporting Konq, and some words on how IWebBrowser may be implemented:
- 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.
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:
: The browser can be upgraded easily, without having to worry about version conflicts against other DLLs. This is a major plus, IMHO
: It's far easier to merge upstream changes, as less major modifications would need to be made to the browser core
: The rendering engine CAN be replaced easily between Mozilla, Konq, or any other browser code suitably modified to support our IPC mechanism. Even so, we do need to decide on a default to use in WINE cvs.
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.
---
Other ideas:
- 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.
- Con: KHTML and KJS do have a dependency on QT or at least QT-Embedded. Getting a quick and nasty implementation of KHTML (+KJS, which we will need for DHTML/Javascript support, almost all applications that use IWebBrowser use JS) running will be easy, replacing the QT dependencies with Windows GDI/Commctl calls is somewhat more work.
- 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.
- Ender
- Gecko: the best (in terms of features/compatability/speed) rendering
engine around. Also benefits from being very widely deployed at least on Linux. Note that soon Mozilla will be splitting into a GRE (gecko runtime environment), then an XRE (xul runtime) layered on top, with Mozilla being an "application" on top of that framework. When this happens, making the GRE a dependancy of Wine would not be such a big deal IMHO, it's only a few megs at the moment.
- Pros: We get a high quality rendering engine that we know is
powerful enough to do what we need, and when the GRE thing happens it'll be relatively easy to embed too. Already has IWebBrowser interfaces(bitrotted afaik).
- Cons: Gecko codebase is huge and complex, adding whatever IEisms
are necessary may be hard. Overhead of XPCOM etc.
I'll add something else here.
Mozilla is an absolute pain to run on OpenBSD. The porting team have recently worked out that they can get it to run as long as they statically link it.
I have no idea if the Gecko part is affected by this, and I'm aware that Wine does not currently run on OBSD anyway, but why make things more difficult.
Konq runs happily so KHTML is probably no problem and I have not heard of any problems with GtkHTML.
- 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
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.
I've done it before, it's actually not that hard to write wrapper classes for most of the QT stuff. It's not the first time I've de-QT'ed an application. I'll probably base most of the work off the stuff done in Atheos, if we can resolve the licensing issue.
The libraries must be GPL'ed at this point, because they use QT so heavily. And QT is GPL'ed. This doesn't allow the libraries to be LGPL as long as they use QT.
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.
I don't believe it'd be that slow.
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.
GDI allows this, it's not a problem. Windows isn't very security oriented, remember :)
I'm not sure how far WINE supports this however, it may be one of the reasons various app's only work in Desktop mode (X11 limitations on writing to other Windows?)... Alexandre would have to answer this one.
And no, KIO shouldn't be a hard dependency. If we can work out an arrangement on licensing, I'd have to do some experimentation on KHTML/KJS without QT and KDE support libraries. I need to look into Konq-embedded more and see exactly what it uses from KDE's core.
That, again, is the only big bonus Gecko has over KHTML in my opinion - the license just lets us use it without worrying about licensing. But also in my opinion, KHTML is a far smaller and cleaner choice. Also, Gecko aims at STRICT standards compliency, whereas KHTML tries to make midway in support IE specific stuff also. So it would probably be less work to make the specific hacks to KHTML then to make similar changes to Gecko.
- Ender
I've done it before, it's actually not that hard to write wrapper classes for most of the QT stuff. It's not the first time I've de-QT'ed an application. I'll probably base most of the work off the stuff done in Atheos, if we can resolve the licensing issue.
Good point, I'd forgotten atheos was using it also. OK, you seem to know more about this than me, i'll take your word for it :)
How does an external process render using the GDI to a window outside its ownership? In X this is handled with XEmbed.
GDI allows this, it's not a problem. Windows isn't very security oriented, remember :)
I'm not sure how far WINE supports this however, it may be one of the reasons various app's only work in Desktop mode (X11 limitations on writing to other Windows?)... Alexandre would have to answer this one.
I know the wineserver supports IPC between wine applications. Perhaps if it doesn't already support it, Wine could be extended to allow a DC to be drawn to by another process that's connected to wineserver. Not sure really. Although I don't think X11 gives an easy way to draw to another window, you can embed one window seamlessly inside another using reparenting. One solution might be for the WebControl to be a simple "socket", that allows other things to be plugged into it. The browser server then creates a window containing a KHTML control and reparents it. That way you'd avoid having to rewrite KHTML to use GDI, instead it can just use X11 directly. Or would that cause issues with Wine?
in my opinion, KHTML is a far smaller and cleaner choice. Also, Gecko aims at STRICT standards compliency, whereas KHTML tries to make midway in support IE specific stuff also. So it would probably be less work to make the specific hacks to KHTML then to make similar changes to Gecko.
Yeah, also the KHTML code is far easier to read and understand than Gecko from what i've seen. Does the licensing thing mean that if you write a KDE app it must be GPLd?
"socket", that allows other things to be plugged into it. The browser server then creates a window containing a KHTML control and reparents it. That way you'd avoid having to rewrite KHTML to use GDI, instead it can just use X11 directly. Or would that cause issues with Wine?
It'd cause issues with Wine. Remember, X11 is the only real output device right now, but there's also the prototype SDL one. Also, ideally all Wine dlls (besides very specific ones) should be compilable under Windows and be able to be used as replacements for real Windows DLLs.
in my opinion, KHTML is a far smaller and cleaner choice. Also, Gecko aims at STRICT standards compliency, whereas KHTML tries to make midway in support IE specific stuff also. So it would probably be less work to make the specific hacks to KHTML then to make similar changes to Gecko.
Yeah, also the KHTML code is far easier to read and understand than Gecko from what i've seen. Does the licensing thing mean that if you write a KDE app it must be GPLd?
Technially yes.
However I've looked into this some more: kdebase MAIN directory, COPYING states it's under the GPL Various subdiretories are under the GPL or LGPL, as far as the headers read. This is quite inconsistant (eg, libkonq is under the LGPL according to headers)
Kdelibs, the thing we are intrested in, includes both GPL and LGPL (and BSD for that matter) licenses. According to headers, khtml/*, kjs/* and possibly to some extent kio/* are under the LGPL.
This means we can do what we want. YAY!.
I was initially confused, because from TrollTech's website, KDE is illegal. It links QT, a GPL'ed library as far as TrollTech claim, against LGPL'ed libraries. Which is in violation of the GPL. [See: http://www.trolltech.com/developer/licensing/gpl.html]
Basically, KDE and TrollTech are being quite inconsistant. As long as we remove QT dependancy from the khtml/kjs libraries, we can implement it in WINE. As the code currently stands, khtml/kjs (and a bunch of other KDE libraries) are in violation of their own licensing :)
- Ender
I was initially confused, because from TrollTech's website, KDE is illegal. It links QT, a GPL'ed library as far as TrollTech claim, against LGPL'ed libraries. Which is in violation of the GPL. [See: http://www.trolltech.com/developer/licensing/gpl.html]
Basically, KDE and TrollTech are being quite inconsistant. As long as we remove QT dependancy from the khtml/kjs libraries, we can implement it in WINE. As the code currently stands, khtml/kjs (and a bunch of other KDE libraries) are in violation of their own licensing :)
HUH???
When did you look last time at your linux distribution, specifically at the glibc license... yup, it's... LGPL'd... does it means that linking a GPL'd program against LGPL library is illegal? nope, it's very legal..
Same case here. kdelibs are LGPL'd (some with artistic license, some with BSD license, etc) are ALLOWED to be linked to GPL'd program, which is also what QT is - a GPL (and QPL) license.
Do you think that TrollTech wouldn't do anything if it was illegal? after all, the KDE is their number 1 "customer" ;)
Thanks, Hetz
Who am I to argue with you over KDE licensing? :)
But while I know TrollTech wouldn't do anything, technically I'm pretty sure I'm correct.
The problem isn't linking a GPL'd program against an LGPL library (which is fine for two reasons, in this case glibc is a 'system library', and secondly the LGPL has a 'under the terms of this license, OR the GPL' clause.. so when included in a GPL'd program it's automatically GPL'd)...
The problem is linking a LGPL'd library against a GPL'd library. Eg, in this case kdelibs (LGPL'd) is linked against a GPL'd library.
In your example ProgramX (GPL'd) was linked against a LGPL'd library. Completely different cases.
I'm not a lawyer and all that, but the way I read it, you simply cannot link in that direction. Expecially statically linking, as that makes kdelibs a derivitive work of QT. Which means kdelibs must adapt the GPL. Clause 3 of the LGPL would thus cause kdelibs to revert to the GPL, not the LGPL.
Hence why I was so confused about which license it was under.
Now, this isn't a bad thing for kdelibs - reverting to the GPL means nothing important... but it thus creates a condition where anything using a LGPL->GPL'd reverted library (which is every library in kdelibs, pretty much, as I'm fairly sure they all use QT headers) must also be GPLed. Thus non-GPL'd kde apps are illegal.
Confusing, isn't it? :) And this conversation is getting pretty OT, so we should probably dump it from the list.
Maybe I'm wrong, but that's the way it reads to my sleep-deprived mind. I know nobody will enforce it, but it does create an intresting conflict which could have numerous ramifications (if I am correct).. such as KDE not being included in Debian again (*cry*).
- Ender
Basically, KDE and TrollTech are being quite inconsistant. As long as we remove QT dependancy from the khtml/kjs libraries, we can implement it in WINE. As the code currently stands, khtml/kjs (and a bunch of other KDE libraries) are in violation of their own licensing :)
HUH???
When did you look last time at your linux distribution, specifically at the glibc license... yup, it's... LGPL'd... does it means that linking a GPL'd program against LGPL library is illegal? nope, it's very legal..
Same case here. kdelibs are LGPL'd (some with artistic license, some with BSD license, etc) are ALLOWED to be linked to GPL'd program, which is also what QT is - a GPL (and QPL) license.
Do you think that TrollTech wouldn't do anything if it was illegal? after all, the KDE is their number 1 "customer" ;)
Thanks, Hetz
On November 12, 2002 02:37 am, Ender wrote:
Clause 3 of the LGPL would thus cause kdelibs to revert to the GPL, not the LGPL.
Yes, but if you remove the the code that forces the conversion to GPL, you can use the remaining code as LGPL.
In other words, say you have: -- Source A which is licensed GPL -- Source B which is licensed LGPL
A + B = B + A = GPL A = GPL B = LGPL
-
Dimitrie O. Paun -
Ender -
Hetz Ben Hamo -
Mike Hearn