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