KDE developers have ported the Gecko layout engine of Mozilla to Qt/KDE, in order to provide a more powerful, but KDE-friendly, alternative to Konqueror.
aKademy Hackers Port Gecko to Qt/KDE
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Truly amazing. I’ve looked at some of the code, and it’s beautiful. Certainly much better to use Gecko than KHTML, don’t get me wrong KHTML is a good engine, but gecko is long tested, and develeped. Kudos to the aKademy folks!
“Truly amazing. I’ve looked at some of the code, and it’s beautiful. Certainly much better to use Gecko than KHTML, don’t get me wrong KHTML is a good engine, but gecko is long tested, and develeped. Kudos to the aKademy folks!”
Not to mention that it just works better. It has tighter standards complience, faster, and more stable.
Side by side: Gecko blows the doors off of KHTML.
I’m amused that this should happen several months after Apple began seriously improving KHTML for use in their Safari browser.
So now we may see KHTML running on OSX while Gecko runs on KDE. Oh well, variety is what strengthens OSS I guess….
I suspect they’ll end up renaming to kGecko though, as Kecko is a surname in some countries and consequently is probably trademarked already.
we might see Epiphany/GNOME using khtml.
http://cvs.gnome.org/viewcvs/gnome-webkit/
Both of the open source rendering engines are quite good:
gecko’s advantages:
handles almost all pages
very standards compliant
runs on windows, so more users
khtml’s advantages:
little memory usage
fast loading
elegent design (good for expansion in future)
This is a good news, and this shows how advanced is the KDE framework. Though, I can’t see how Gecko could improve user experience. If this was done years ago, it could be useful. But nowadays Konqui has improved a lot, and I mean A LOT. It renders most of the pages very well, and some IE-only sites, which don’t render in Mozilla, render just fine in Konqueror. I have both of them installed, but since KDE 3.2 (and now 3.3) I have never started Firefox, so I don’t see the point of having an additional html engine when the one in KDE just works, and it’s much faster.
Anyway, choice is always a good thing.
Some sort of Gecko/Mozilla Qt port existed before, Trolltech people made it in 5 days, IIRC, as proof of concept and power of Qt.
But then it lost attention and was removed from Mozilla tree
>> we might see Epiphany/GNOME using khtml.
Once Firefox gets HIG compliance and tighter GNOME integration (will happen), Epiphany will be looking for a reason to exist.
It won’t find one.
so.. um.. when are we going to see libgecko that any program can load as its rendering engine instead of having to port it each time.
>If this was done years ago, it could be useful.
No, because Mozilla sucked big time “a few years ago”. It is only 1-2 years now that Mozilla/gecko is really usable. In fact, going back to 2001 or 2002, I much prefered to use Konqueror over Gecko. Today, the tables have turned the other way around.
> But nowadays Konqui has improved a lot, and I mean A LOT.
I disagree. Konqueror in the recent KDEs is not as advanced as Mozilla is, plus, it is very buggy. In fact, pre-kde 3.1 (before the kde developers do a very poor job migrating the Apple patches), konqueror used to have fewer bugs in CSS. After they migrated Apple’s patches (Safari works great btw, Apple has cleaned up the khtml engine better than kde devs have), a lot of problems appeared, and a lot of sites would not render as nice as mozilla/ie would do them. CSS problems.
> Mozilla-based tech won, hands down.
Really? I wasn’t aware of a war between Mozilla folks and khtml/KDE/Apple folks. There are many people in both communities these days. The real war is between open source engines and IE, which still has 90%+ market share.
> Once Firefox gets HIG compliance and tighter GNOME
> integration (will happen), Epiphany will be looking for a
> reason to exist.
>
> It won’t find one.
What about providing the simplest possible browser for Gnome? I am glad that Firefox aims to step up HIG compliance, but I find the claim that it will ever replace Epiphany quite dubious.
Before people get carried away, you might like to read Zack’s recent blog entry about the mozilla port:
http://www.kdedevelopers.org/node/view/615
>> What about providing the simplest possible browser for Gnome?
Epiphany doesn’t support Firefox’s huge array of plugins and has a retarded bookmarking scheme (try using it for a non-trivial bookmark list)
And the label “simple” is erroneous anyway…Epiphany loads up Gecko and most of the other stuff….the lightweight label I think is bogus
Well, it might if my comment had got modded down or if Zack’s blog entry had been there for a while, but as things stand I don’t agree. Zack wrote the blog in response to people writing about this, not before they did so.
And so, the winner is (Oscar-like suspance): KHTML.
One of the fathers of Mozilla works for Apple.
And Apple chose KHML for Safari.
This is enough for me: if one of the fathers of Mozilla chose KHTML for Safari, KHTML is better than Gecko.
No, it’s not a dirty word, it’s just the only one I thought I could express what seems to me a positive step, even though nobody knows for sure what will ensue: take your toys and try to make them play together to see what happens. Before anybody complains about waste of effort (well, they already did…) I salute the people who endeavoured to try reusing Gecko in KDE, because they had in mind the fact that software is not ultimately a one-design approach.
I for one have an optimistic dream of seeing software work as lego blocks connecting via standards, not as an egomaniac cathedral of quirks.
> Epiphany doesn’t support Firefox’s huge array of plugins
> and has a retarded bookmarking scheme (try using it for a
> non-trivial bookmark list)
Epiphany supports many .xpi plugins, I use many of them myself. Also I have a non-trivial bookmark list, and I don’t find it “retarded” at all.
> And the label “simple” is erroneous anyway…Epiphany
> loads up Gecko and most of the other stuff….the
> lightweight label I think is bogus
You said lightweight, not me. I said simple, because it uses a simple interface.
I don’t care if you prefer Epiphany or not — I do and you don’t, a simple disagreement. My point is that there is a very good niche for Epiphany, one that Firefox will never fill.
But when will we see a khtml browser that runs on windows? There was a project awhile back, but I haven’t heard anything about it recently.
If there were a KHTML windows browser, then there would be much more users and then the rendering engine could really be tested and mature quicker.
Gecko is slow, buggy and bloated compared to khtml. Gecko’s memory footprint is more than double the size of khtml’s. However gecko is more used and is generally a bit more compatible with the various flawed web pages that exist.
> But when will we see a khtml browser that runs on windows? There was a project awhile back, but I haven’t heard anything about it recently.
Likely before KDE 3.4 comes out. Last week, large parts of the KDE libraries were made X11-free in an ongoing port to win32. It should let any KDE applications be run natively on Windows.
Try kexi on windows, for example:
http://ibiblio.org/pub/mirrors/kde/unstable/apps/KDE3.x/office/kexi…
@Eugenia
No, because Mozilla sucked big time “a few years ago”. It is only 1-2 years now that Mozilla/gecko is really usable. In fact, going back to 2001 or 2002, I much prefered to use Konqueror over Gecko. Today, the tables have turned the other way around.
That is strictly *your* opinion, and not factual. If anything, Konqueror was practically unuseable two years ago due to it’s lack of support for most advanced CSS rendering techniques and several basic DOM features.
I can’t even begin to imagine why two years ago you would claim Konqueror was better when I know for a *FACT* that it’s support for CSS, Javascript, DOM and even HTML rendering was far inferior to Mozilla’s at the time.
First http://www.trolltech.com/qtmozilla/
later http://www.mozilla.org/ports/qtmozilla/
Then KMozilla (no HP),
now this.
Nice try, but it won’t be a success.
OK, it took them 4 days – one day faster than Trolltech’s port. New record. Great. Look at http://www.mozilla.org/ports/qtmozilla/
First entry: 13 Feb 2003
Last entry: 25 Feb 2003
The project didn’t even survive a full month. I doubt this try will be different.
@KAMiKAZOW
The project didn’t even survive a full month. I doubt this try will be different.
I think you’re horribly wrong. The big difference is that two of the major KDE developers are involved in this port. That makes a huge difference. I for one could scream with joy over this development. KHTML while much better than it was two years ago, still has very poor support for the ‘upper regions’ of CSS2. Opera, Mozilla and even Internet Explorer often have better DOM, JS and CSS support than KHTML.
> Well, it might if my comment had got modded down or if Zack’s blog entry had
The Blog was not necessary. It would have been sufficient to read the dot story talking about adding Qt as platform for Mozilla.
Some years ago Mozilla was technically far superior, but it was dogslow and buggy, while KHTML was clean and fast, very usable for most websites of that time.
Today, Mozilla is also clean and fast and still technically superior. KHTML has certainly catched up to IE and is a great alternative to it (no reason not to use it if you like the low memory usage or KDE integration), but Mozilla has far surpassed IE in features long ago. Today, when I use the latest in CSS and JavaScript/DOM standards, then the results are usually close to perfect with Mozilla and Opera 7, but rather average with KHTML (and it doesn’t work at all with IE).
I think that the free software and web development community should rally around Mozilla, because right now it’s our best chance to ever be able to actually use some of those new standards, which were introduced several years ago… And further integration into KDE can only be a good thing.
In the blog that somebody linked, the guy said that Firefox would run natively in KDE. If this is the case, does that mean there’s going to be a Firefox written in QT? And if that is the case, will they make a QT version for Windows as well ?
Lets hope they make a better job of integrating Qt than has been made of integrating GTK+. This form looks so ugly in firefox.
The Mozilla organization was supportive: “We are delighted to work with the KDE community […] Making Qt another platform for Mozilla, and Gecko another option for KDE is a win for both users and developers” commented Mitchell Baker, President of the Mozilla Foundation.
Very happy to see that. This is what we get when we work from a user’s standpoint rather from an investor’s. Once again, the FOSS world is united to provide the best to users. I’m telling already many of my friends to switch to alternative browsers. I personally use Opera (sorry it’s not OS, but hey…), and most of the time, sites designed for IE are visible now in alternative browsers, that’s what imports most. I also use Konqueror, and it can only get better now. I know Firefox is the best for rendering buggy web pages.
—
Charles.
“Did you have your Win dose today?”
@Shawn:
Hey, if I’m wrong, that’s fine with me.
I just want to say, that you guys should not have too high expectations.
IIRC KMozilla was dropped, because KHTML became “good enough”.
Once KHTML becomes “good enough” again (IMO not unlikely because of Apple’s support), this project may no longer be supported by KDE.
enough said oh, except for cross platform and standards compliance.
Mozilla-based tech won, hands down.
I agree there is a time for competition but there is a time to admit when there is a winner and go forward.
The KHTML folks can waste their time trying to keep up with Gecko, or they can throw in the towel and move the leader further forward.
Sorry, but KHTML has won hands down. Gecko has been very bloated and slow since the day it was born at Netscape. Apple chose KHTML because they needed a fast reason to get people off IE on MAC – they succeeded. They could quite easily have used Gecko, but they didn’t. All that is required now is ironing out the inconsistencies in the many web pages out there, so it’s all downhill.
Once Firefox gets HIG compliance and tighter GNOME integration (will happen), Epiphany will be looking for a reason to exist.
Sorry to point out the obvious here, but Firefox will never be Gnome HIG compliant. It is a cross platform app.
I disagree. Konqueror in the recent KDEs is not as advanced as Mozilla is, plus, it is very buggy.
You obviously haven’t used it if you think it is buggy. I don’t use any other browser within my Linux install now, and I was picky about Konqueror pre-3.2.
In fact, pre-kde 3.1 (before the kde developers do a very poor job migrating the Apple patches)
Wow. Really? The ubiquitous ‘I love Apple’ comment.
After they migrated Apple’s patches (Safari works great btw, Apple has cleaned up the khtml engine better than kde devs have), a lot of problems appeared, and a lot of sites would not render as nice as mozilla/ie would do them. CSS problems.
That’s called collaboration Eugenia. I’m detecting some desperation here here Eugenia, and that isn’t good.
After using Konqueror I can’t go back to Firefox on any platform. It is just way too slow.
There did you find the source code?
KHTML is faster, more responsive, and in general, a better engine.
There’s one main reason I’ve not switched to Konqueror–it doesn’t support AdBlock, and I can’t stand browsing without it. There are also some other Mozilla/Firefox extensions I really like, as well, and I don’t want to lose them.
This is still a good thing tho–I like to use as many Qt apps as possible, for consistency’s sake. Most likely, a Qt compile-time option will be added to Firefox now, along with the existing GTK1 and GTK2 options, and if that happens, you bet I’ll recompile Firefox with the Qt option enabled.
I really hope this will result in a Qt-compile-time option, and preferably a KDE option. When I’ll ditch Konqueror again, and only use it for what it’s really good at; filemanagement.
The reason I use konqueror is load-time, but mostly consistensy, forms, file dialogs and printer dialogs. All things that I don’t think Firefox is offering.
How about Settings -> Configure Konqueror -> Java & Java Script -> Java Script -> Open new windows: smart
Except that’s not what AdBlock does. If Konqueror has something that will block any non-HTML URL that matches a list of regexps from loading in any form, please let me know.
The goal is not to create an alternative to Konqueror, but an KPart alternative to KHTML that would be used by Konqueror (and other KDE apps).
Not only misleading, but also incomplete: It’s also about a Qt port of Mozilla/Firefox with KDE integration.
At Akademy, the Novell/SUSE guy said in his keynote, that they need a better alternative to Konqueror/khtml for their upcoming Novell desktop because Konqueror/khtml is not supported by the industry. So I guess this port is probably mainly done because of Novell.
> So I guess this port is probably mainly done because of Novell.
No, it was started independently. When first SUSE employers heard about the port, they mentioned that SUSE had thought about this too. When the Keynote speaker (re)arrived at aKademy (and still didn’t know about it, the KDE hackers had asked the SUSE guys to keep quiet because they wanted to tell him personally), it was already running.
Bit i hope they will not turn their efforts off KHTML.
I started to use Konqueror/KHTML ~half year ago and found that i rarely start mozilla and opera, just getting better with konq.
It is really fast and comfortable.
It does not have plugins/featurecreep of Mozilla, but i don’t use them anyway. I prefer it work good bu default rather than great after a *lot* f configuring, which i will not do anyway.
I switched to KDE nine months ago and at the beginning used Mozilla Firefox. Some day started using Konqueror and I only have had to launch Firefox a couple of times since that day.
Best regards
The big advantage of Konqueror/KHTML is, that it’s fast. It’s really fast. Mozilla/Firefox is slow as hell. If I switch virtual desktops, firefox need one or two seconds to draw it’s windows. Konqueror is just there.
KHTML is really great. Ok, I have to admit that there are a few pages that render better in gecko, but that’s still no reason for me to use firefox daily and khtml is getting better with every release.
Maybe gecko is usable when it’s embedded in Konqueror but I think khtml will still be faster…
While we’re waiting that Konqueror developers implement this feature natively, you can use http://www.privoxy.org.
Since it is a proxy, it works for any browser, and it’s really good. It takes a while to configure it, though.
So… is it going to be called… um… Kecko?
Victor.
If this means Mozilla or Firefox can be compiled with KIO support, it’s great. Mozilla’s network layer, “necko”, while it works, doesn’t compete with versatility of KIO.
It just occured to me, that some of KHTML zealots here, seem to they never used gecko based web browser since they abandoned it…
Of course, gecko WAS slow and buggy as hell from the day one. But the consequent development and improvement made it one of the great web engine ever…
One more thing…it is my humble, or somewhat stupid, opinion that the technical superiority doesn’t mean that the end-product is alwas superior…
Of course, gecko WAS slow and buggy as hell from the day one. But the consequent development and improvement made it one of the great web engine ever…
Nope, I’ve been using Firefox and Gecko on Windows a Linux recently. It has to think about many pages for far longer than KHTML (why did the Mozilla/Netscape people working on Safari use KHTML?), but of course, Gecko has had more hacking for all those brokwn web pages out there.
In which is more important for something to work properly than to be very fast and work in a defective manner.
This is the pourpose of having Gecko on KDE, to have the best of both worlds.
‘more important for something to work properly than to be very fast’ unfortunately in my experience, gecko does neither of those. eg. It has had bugs in it’s handling of CSS display for table cells for ages (it loses spanning information when the stylesheet is changed from js). That said, it’s a cool hack and offers gecko to those who want it.
I don’t know what is up with all the zealotry in this thread, these are, after all, just boring rendering engines…
I mean, really, how many users cares which rendering engine it uses as long as the web pages they go to works? I am even developing for the web, and *i* don’t care since IE pretty much always seems to be the lowest common denominator.
I guess i do care about the speed factor, but with a semi-recent machine i can’t register much difference, except konqueror start up is very fast, but since i only start my browser once a day, that is totally irrelevant.
Now the user interface, thats a totally different matter, i like consistency and integration, which is the main reason i don’t use gecko browsers on linux. (i do on windows however as i “need” tabbed browsing) If i used gnome instead of kde, i probably would use ephipany or galeon.
While many seem to claim that KHTML is inferior, i would like to add that the only websites that i have found/used that worked in only KHTML (konqueror) or gecko (and that wasn’t just test pages) is a few sites with javascript pull-down menues, that does not work in mozilla, but do in konqueror. That doesn’t prove that KHTML is better/worse than gecko, but i would just like to point out that while standards compliance tests, etc, is a good thing, it unfortunately doesn’t really say anything about whatever a rendering engine, as perceived by the user, is any good. And in my case, i was lucky that KHTML did a better job interpreting the pages, but i am sure someone can point me to examples showing the opposite.
But as a web developer, i would like for all the browsers to be as standards complient as possible, that would make my job easier, but whatever i make must also work with the de facto standard web browser, which unfortunately makes many standards irrelevant at this time.
…alternative to Konqueror.
I think and hope what was meant is
…alternative to KHTML.
Maybe a good idea – especially if nobody is working on KHTML as a recent post I saw somewhere indicated.
It’s nice to have the choice but KHTML in Konqueror is still the best choice. Reasons would include:
1) Integrated with KDE’s spell checker
2) Load’s fast. Super fast. On my 1.4GHz Athlon XP, konqueror takes about 4 seconds (not preloaded) while firefox takes at least 10.
3) The UI is still slower than a native QT UI. This may be partly due to GTK, I don’t know, but it’s definitely slower.
In my experience, if your machine is fast, then firefox will be fast. But if it’s a little bit out of date, firefox reveals its bloated mozilla roots. Firefox is completely and totally unusable (about a second lag between typing a character and it appearing in the address bar) on my 333MHz Celeron while Konqueror runs somewhat slowly but still nicely useable. It is on that kind of machine that one really sees which applications are efficient and which are slow.
3) The UI is still slower than a native QT UI.
I mean of course, the Firefox UI is still slower than a native QT UI (as used in Konqueror).