Buried under hundreds of emails on the Konqueror mailing list, was this little gem from Ming Poon of Corel. Apparently, Corel has been working for months on a Qt port of Mozilla. The results are reportedly impressive with QtMozilla turning out to be more stable than the official Linux GTK version. Corel plans to port QtMozilla to KParts so it won't be long before you can embed even that in Konqueror. Honorable mention goes to Roberto Alsina who had begun his own Mozilla port the weekend before.

I think it's not the QT library that is the big deal, but the KParts thing. Having Mozilla as a Konqueror embedded component would be really great (in my opinion), something which is obviously hard to achieve (if possible at all) using GTK.

It would let you choose between two browsers within one single user interface

there was a slashdot-article a few month ago about gnome and kde sharing a component model. in the discussion, somebody (sorry, i dont remember) said: "hey, lets make a 4-way bridge between windows(com/dcom), mozilla(xpcom), kde(kparts/dcop) and gnome(bonobo). I think he got a "funny" rating.

this idea is bothering me from this day. isnt it possible to make such a thing ? take for example a gnome component. what does it take to accomplish this task.

in my understanding, there has to be a parser that generates a kparts/dcop interface from the bonobo-idl and a wrapper-app(possibly generated, too), that maps the bonobo components functionality to the generated kparts interface. this wrapper app acts like a bonobo enabled app to the component and as a kparts/dcop component to the kparts using application and the dcop-server.

i cant really estimate the complexity of such a parser/generator nor the difficulties based on the different designs, but in theory it sounds feasible.

if i am not totally off the ground, such a system could be used for xpcom components and even other component systems. think for example of java-beans inside konqueror...

The great benefit is the internal support of Qt in Mozilla. This means that programmers can e.g. embed the Gecko engine into Qt programs. Or someone could produce a version of Mozilla that replaces these incredible xml-rendered GUI elements with fast Qt.

It will be interesting when gecko becomes an embeddable Kpart. Then a fair comparison of its rendering engine with khtml can be made. I bet khtml uses less memory, important to us with low-end machines.

This news site is great. If this post goes through and passes the lameness filter I'll be very surprised. Testing now....