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.
More choices, I see nothing negative in that.
The one thing I'd actually like to see in my GNOME environment is a KHTML based webbrowser, the html rendering feels much snappier than Gecko/Mozilla browsers.
There must be a reason why Apple desided to go with KHTML for their Safari browser instead of Gecko/Mozilla.
Actually it ran in X before it ever did in Windows. IE is the browser formerly known as NCSA Mosaic.
The best news here is that Firefox will also now be able to use the native KDE widgets, etc. Sweet.
*Fortitudo, aequitas, fidelitas.*
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.
... that we will finally have OK/Cancel buttons in the usual (correct) places in the Qt version of Firefox!
bash: rtfm: command not found
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.
It's KDE! They'll just add a checkbox to the Prefs dialog.
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.
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"
It might be a good idea to make khtml as standard compliant as possible and switch to the gecko enigne whenever konqueror detects a page, which has incorrect html.
khtml would be very clean and probably easy to develop and konqueror would still be able to show all pages.
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?
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.
While your argument may have merit, I fail to see the connection between the 'Windows Driver Foundation' and getting stoned before browsing Slashdot.
"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?
Be bloody careful if you really do this: make sure the HTML control is sandboxed every bloody way imaginable.
Personally, I'd rather port the viruses directly. It's more honest.
Mr. Gates, is that you?
Seriously, I'm a professional web designer. I build everything 100% XHTML and CSS standard; my designs usually work immediately without tweaking in Safari and Mozilla/Camino/Firefox. A good 25% of my time, however, is spent fixing the IE 5 and 6 bugs afterwards. That happens *every* time.
Maybe you're just trying to do some things the wrong way. It's possible to write code that is valid but still done the wrong way.
You mean Ars Technica web site bad rendering? That it's also solved in KDE 3.3
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
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