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?