Corel ports Mozilla to Qt

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 just recently read that mozilla will be
binning GTK right after the First Official release in favour of pure xlib calls.

The reason was, that mozilla rarely uses gtk
as it creates its own user interface.

What benefits would mozilla gain by using QT

no signature today

By Matthias Lange at Thu, 2000/09/21 - 5:00am

Making sure that people have Qt and KDE installed ;o)

By M_at at Thu, 2000/09/21 - 5:00am

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


By Martijn Klingens at Thu, 2000/09/21 - 5:00am

wouldn't it be more appropriate to give access to gecko, the HTML rendering engine, by a kpart, and not the whole mozilla app? Or am I missing a point here?

By raphinou at Thu, 2000/09/21 - 5:00am

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...

By Mathias Henze at Thu, 2000/09/21 - 5:00am

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.

By Heiko Stoermer at Thu, 2000/09/21 - 5:00am

Corel would not be replacing just a tiny bit of GTK for a tiny bit of Qt, but dumping a tiny bit of GTK and a whole mass of Xlib in favor a Qt.

By David Johnson at Thu, 2000/09/21 - 5:00am

This is really good, more Kparts Komponents!
Now if only someone will port Sun's OpenOffice to Kparts (when it gets released)....

By t0m_dR at Thu, 2000/09/21 - 5:00am

Well, it looks like it won't be the same guys!!!

They will want to sell Corel Office 2000...

By The SFinX at Thu, 2000/09/21 - 5:00am

You're right, but for corel I would be happy if at least they did a port of their (commercial) office suite to Qt and Kparts...

By t0m_dR at Thu, 2000/09/21 - 5:00am

Better idea, take any of the good stuff out of OpenOffice and put it into KOffice.


By Erik Severinghaus at Thu, 2000/09/21 - 5:00am

That would be cool. A OpenOffice/KOffice hybrid.

I imagine that any such effort might be more complicated then it is worth, so probably just using the OpenOffice code as a guide would be better.

By Ian M at Thu, 2000/09/21 - 5:00am

Well , *IF* OpenOffice becomes Kparts compatible then stuff from one office will work on the other anyway!

By t0m_dR at Thu, 2000/09/21 - 5:00am

The post says it's at
However, That site dosn't mention it at all.

Do I have to grab the huge CVS tree to get just that one application ?

Memo to Corel... How about posting a tarball of the source and maybe a Linux binary built against KDE-2.0 ?

By Forge at Thu, 2000/09/21 - 5:00am

The post doesn't say it's at Ming was answering my question about where I could find the SMB implementation done by Corel (the mail thread is actually about SMB slaves).

I don't know where you could find it however :)

By Jelmer Feenstra at Thu, 2000/09/21 - 5:00am

Wouldn't it be a better idea to make the Geckho Engine a KPart, so that Konqueror users get to choose which component they wish to render their HTML with?
(I'd choose Konqueror!)

By Coptain Cack at Thu, 2000/09/21 - 5:00am

That's what Corel's doing- they're making Gecko a KPart. BTW, technically, you'd choose KHTML, not Konqueror; you'd still be using Konqueror, but with Gecko instead of KHTML. Hope that helps.

By Chris Lee at Fri, 2000/09/22 - 5:00am

a heve a problem in the pc hardvare end cd its not vorking,aj delet the file cofig system,have jur ken help my,thenkju from vehbi.

By vehbi at Sat, 2004/10/09 - 5:00am

First Post! Sorry, forgot this isn't Slashdot.

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....

By John Califf at Thu, 2000/09/21 - 5:00am