Slashdot Mirror
KDE Gets Gecko/Mozilla Support
Sivar writes "Ars Technica reports that not only has the Gecko engine been ported to Konqueror, but the developers were able to finish the port in only four days during the week-long Akademy conference. With this port, Konqueror users now have a choice between two mature, powerful rendering engines."
>Now if only those KDE devs would port the Safari rendering engine us Linux users would be happy.
I see this is a joke, but for those who doesn't know, Apple is indeed contributing their enhancements of KHTML -- on which Safari is based -- back to the KTHML-team.
"Based on NCSA Mosaic. NCSA Mosaic(TM); was developed at the National Center for Supercomputing Applications at the University of Illinois at Urbana-Champaign."
Maybe you should tell someone at Microsoft that.
Anyway this wasn't the same than a KDE port, but given that the Kecko Team have not integrated KIO, KWallet and KCookieJar already, they aren't there either.
Actually there are many companies and projects using the Mozilla platform these days. I use it every day at my job these days. Some examples out there:
Sunbird -- calendaring system
Nvu -- web authoring system
Oeone -- Linux desktop
Komodo -- programmer's editor/IDE
And tons of other small projects are available as Mozilla or Firefox extensions at www.mozdev.org and other sites.
The best thing is that Firefox will have a completely native look and feel. This means that they are making sure the entire Mozilla platform runs as native KDE applications. This is not only Firefox/Gecko, folks, this means Mozilla, Thunderbird, Sunbird and anything based on Mozilla will in the future look and act as a native KDE app.
Awesome!
Are we really moving away from the Desktop Environment holy wars, and towards interoperability?
Not really. You can draw GTK+2 apps using Qt widgets but that doesn't magically give the applications DCOP interfaces, KIO support, and things like that which really make KDE what it is.
At one time, Gecko was the creme de la creme of fast rendering engines. Now it's just the most compatible as well as being damn fast. Look how times have changed.
The KDE project takes a lot of flack for the way they integrate applications. Most people call it 'bloat'. Some call it 'Microsoftesque'. As the conventional OSS wisdom goes, apps that live outside the KDE project are usually better. But, as we see in the Windows (and Mac) world, integration and consistency is what sells. Fortunately, KPart has emerged as the best of both worlds.
Thesis: small applications doing specific tasks.
Antithesis: large applications that do everything.
Synthesis: apps seamlessly integrated via an open framework.
For years we witnessed proprietary software get more and more bloated and more and more expensive. That was due in no small part to the monopolies created by proprietary formats and standards. Now, with OSS, we are witnessing capitalism in action. Choice and open standards lead to constant improvement.
The next time you think about removing choice, think "where would OSS be without this competition?" Would we have KPart if it weren't for Gnome? Would we have great, cross-platform Gnome apps if it weren't for KDE? Many people look at these projects and see redundancy. I look at them and I see innovation.
The argument that someone needs to "manage developer resources" in OSS is completely bunk. OSS didn't get where it is today by forming a central economy of software projects. OSS is about freedom and fair competition. A defining quality of Open Source has been: there are no managers! The downside is that you may not get to tell a developer what to work on unless you're willing to pay her. The upside, though, is that we all reap the benefits of creative freedom.
"I assumed blithely that there were no elves out there in the darkness"
Then IE would be standards compliant, and so would all the Windows apps that rely on the IE rendering subsystem for HTML rendering.
I THOUGHT that it was pretty clear, and other people seem to have got it, but I hope that makes it even more clear for you.
Zack Rusin, one of the authors of this port, has written some more information about it in his blog.
See his blog
You also may want to consider Rapid Application Development with Mozilla instead. It's more recent and a better read, I think. You can also download the entire book (PDFs) from the above mentioned link (hint: see Downloads). If you like it, don't forget to buy it.
The full (updated) text of Creating Applications With Mozilla, along with all the example source, is available for download at http://books.mozdev.org.
Even M$ admits its broken. They've decided to scrap Windows Driver Model (WDM) and replace it with Windows Driver Foundation (WDF). Here's what Redmond has to say about their current driver model: But you'll have to wait till the mythical Longhorn comes out before you see the vaporware^H^H^H^H^H^H^H^H^Hfeature.
If you look at KDE changelogs, you see "fixed from apple" in there fairly often. Safari work is going upstream.
So... grandparent poster, while what you said was technically correct, your post was wrong in that you said that the GGP poster was wrong. MSIE is based on SpyGlass Mosaic - but that's in turn based on NCSA Mosaic.
Got time? Spend some of it coding or testing
From http://www.netvalley.com/archives/mirrors/eric/Er
Phillip
On Linux, you can compile Mozilla (and related products, like Firefox, Thunderbird, Sunbird, etc.) to bind for GTK1 or GTK2 (and now, hopefully, Qt). On Mac and Windows, it binds to the native toolkit.
True, it still uses XPFE, but it uses the other toolkit as a backend and to get certain information (colours, fonts, and dialog widgets if the Moz theme isn't comprehensive).
It's one of Mozilla's greatest strengths--it still has its own theming capability and cross-platform compatibility, but it also integrates with the native desktop. Adding another toolkit (i.e. Qt) to the possible options will only help increase its acceptance, without sacrificing anything.
I support the Center for Consumer Freedom