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."
I'm waiting for IE's rendering engine to be ported, possibly with some help from Wine.
Also read this blog entry by one of the developers which answers the most common asked questions.
Now if only those KDE devs would port the Safari rendering engine us Linux users would be happy.
Perhaps more interesting than porting Gecko to Konqueror is integrating Qt and KDE with Firefox. It sounds like this porting fest has gained a couple of talented developers for the Mozilla project. This is good for both KDE and Mozilla.
The best news here is that Firefox will also now be able to use the native KDE widgets, etc. Sweet.
*Fortitudo, aequitas, fidelitas.*
"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.
Think of Mozilla's platform as Java-lite. You can write very small programs that utilize many built-ins that the browser supports. It has a deployment framework through 'extensions', etc..
.NET or Java in order to do their work.
.NET Runtime ~25MB
.NET installed (trust me from experience, they don't). Less means better in this case. The smaller the release, the more likely an admin would choose your solution.
Not everyone needs a fully library supported language like
As long as you can learn JavaScript, you can write mozilla extensions. I'm just wish that the Mozilla folks would make it easier to find info on how to develop the platform as a platform. From what I've read on their site, they target the 'Mozilla as-a platform' over 'Mozilla is-a platform'. They might find that free/comercial entities could find use in their platform and help develop it if they think there's more for them to use from it.
Think of thin-apps niche for a moment:
Java Runtime ~15MB
Mozilla Runtime ~5MB and that includes a browser
If you want to deploy Thin Client App xyz, which one do you choose? You can't assume that your customer has either Java or
Mozilla has less surface area which means there's less functionality built id but its more simple to develop for. The language is JavaScript which is used by throngs of web developers (the target market of this technology). You can look at the debate over web based Application distribution to see where Mozilla fits into things. (The new MS web services model, Java Web Start, Mozilla)
Bye!
Oh come on, that never happens.
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"
Zack Rusin, one of the authors of this port, has written some more information about it in his blog.
See his blog
Can we have the rendering speed of KHTML (Konqueror's rendering engine) and the relatively-small memory footprint of Konqueror with the compatibility of Mozilla?
I mean, switching between rendering engines just to access a particular site sounds annoying. Almost as annoying as having to open an IE window for sites that don't work well w/ Mozilla or a Moz. window for sites that don't work in Konqueror...
Is Capitalism Good for the Poor?
The full (updated) text of Creating Applications With Mozilla, along with all the example source, is available for download at http://books.mozdev.org.
"hasn't anyone ever tried to write a validated webpage that works in mozilla/firefox? it's nigh impossible, if you expect to use all of the features of html4.01 transitional or css1.0"
Smoke crack much? Writing validated HTML or XML pages in Mozilla is easy as hell. It's getting IE to render em right that is the hard part.
"have a look here: Mozilla's quirks mode. It's actually necessary to trick the browser into getting even somewhat close to standards compliant, and even then the formatting is all screwy by half."
I hope you were trying to be funny. Otherwise you could only be considered a retard. Actually read what the page says.
" Because existing content on the web is not standards-compliant or would appear in unintended ways on a standards-compliant browser, Mozilla handles some content in a backwards compatible way and some content according to standards.
There are three modes used by the layout engine: quirks mode, almost standards mode, and full standards mode. In Quirks mode, layout emulates nonstandard behavior in Navigator 4 and MSIE for Windows that is required not to break existing content on the Web. In full standards mode, the behavior is (hopefully) the behavior described by the HTML and CSS specifications. In almost standards mode, there are only a very small number of quirks implemented: those that break real pages on the web that use the DOCTYPEs that trigger almost standards mode."
Mozilla quirks mode is not about rendering pages in a standards compliant way. It is about rendering broken pages in broken ways to match the rendering of the worlds most popular broken browser Internet Explorer. Which has it's own quirks mode so as to be backwards compatable with it's own broken ancestors.
" No problems in ie 4, 5 or 6. no problems in Opera or with khtml. I have no trouble testing sandards-validated pages QNX browser, mac OS/X, netscape 4 or with any other damn browser. Just the unholy troika of moz-firebrid-netscape. I'm like, wtf?"
And after reading all that the rest of us are all like wtf was he smoking?
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