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.
Dot Categories:
Comments
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
instead?
Matthias
--
no signature today
Making sure that people have Qt and KDE installed ;o)
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
Martijn
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?
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.
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.
This is really good, more Kparts Komponents!
Now if only someone will port Sun's OpenOffice to Kparts (when it gets released)....
Well, it looks like it won't be the same guys!!!
They will want to sell Corel Office 2000...
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...
Better idea, take any of the good stuff out of OpenOffice and put it into KOffice.
Erik
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.
Well , *IF* OpenOffice becomes Kparts compatible then stuff from one office will work on the other anyway!
The post says it's at opensource.corel.com
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 ?
The post doesn't say it's at opensource.corel.com. 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 :)
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!)
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.
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.
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....