Help support

[Ender]

> 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