According to internal email correspondence, TrollTech, makers of the Qt widget set on which KDE is based, has decided to use JavaScript and Mozilla technology as core components in the next versions of their products. The KDE core team appears quite enthusiastic about this novel development. In one of the emails, Matthias Ettrich, KDE founder, explained: "Now we're pushing the envelope, making KDE more flexible and themable than ever before. By replacing C++ with JavaScript and HTML/XML where possible, KDE will become easier to program and to theme, sometimes with the simple editing of a stylesheet!". Most KDE developers agreed. A draft press release is included below.

OSLO - The K Desktop Environment (KDE), in conjunction with TrollTech, makers of the Qt Cross-Platform development kit, announced that Qt will be switching to JavaScript and Mozilla technology in the next versions of their products. The change will affect all Qt-based products, including KDE.

"It's well known that the K stands for Kuaint," commented KDE project founder Matthias Ettrich in a private email circulated to the core KDE developers. "Now we're pushing the envelope, making KDE more flexible and themable than ever before. By replacing C++ with JavaScript and HTML/XML where possible, KDE will become easier to program and to theme, sometimes with the simple editing of a stylesheet! This is the natural conclusion of previous XML User Interface efforts."

Almost all developers agreed to replace QPainter and KHTML, key components of the two systems, with Gecko, the Mozilla rendering system. "The technology", explained Haavard Nord, TrollTech CEO, "has been made possible by our long-awaited switch of QPainter to Gecko technology, which will appear in the next major Qt release (Qt 4.x). Work on the Qt-3.x branch will stop shortly in favor of Qt 4.x. We wish the best of luck to KDE, and hope KDE 3.0 will be a great success when it is released with this new technology."

Roger Lawrence, Mozilla JavaScript maintainer and Netscape employee, noted that the increased usage of JavaScript in Qt and KDE will be a great boon to its speed and robustness.

Following Matthias Ettrich's brief announcement, a long series of posts appeared from a variety of developers, almost all supporting the plan. Discussions are continuing regarding the continuation of
the KDE 2 branch, including suggestions that Waldo Bastian work on a new KDE release schedule which drops any further KDE 2.x releases in favor of an immediate jump to the new technologies.

David Faure argued in favor of branching immediately, and just releasing bug fixes to the 2.1 branch.

Charles Samuels, multimedia director for KDE, remarked "I think it's a great idea, as long as they make sure to indent with tabs! They'd better, or I'll claim my vengeance!" Samuels was sedated by his nurse at this point.

Waldo Bastian, known KDE curmudgeon, was unavailable for comment. When we asked "Where's Waldo?" on the kde-core-devel
mailing lists, no response was received, save for a terse "ADMIN: Literature Discussion belongs elsewhere."

Update: 04/02 10:50 PM by N: Yes, this is an April Fool's joke. It was so good, many are still falling for it! Meanwhile, those of you waiting for some real news might want to check out the latest KDE apps. I hear new Opera and Aethera betas are out.

Don't forget the Javascript! I for one think this is a great idea! This will lower the bar to the level that KDE can be written by anybody... maybe even with Frontpage. Although there is now the possibility that KDE may be difficult to use with legacy konqueror and IE.

Using a widget/theme engine which can import CSS would not be a bad idea.

It would not require a full implementation, but basic CSS would indeed make it easier to create a theme "with the simple editing of a stylesheet".

To keep performance, the engine could read the CSS defintions once, then convert it to native format for actual use. If KDirWatch notices a change in any of the theme files, there will be a rebuild to native format.

That way we can have both ease-of-use in creating themes (HTML/CSS is probably more well-known than current theme configuration) and speed, not requiring an actual run-time parser.

You programmers think to difficult, as far as I know Intel is developing a ne wgeneration microprocessors that understand plain american so no need anymore for assemblers, compilers and all kinds of esoteric programming languages, it will have an audiointerface and you just tell your computer what you want it to draw on the screen. I heard they will name it after a well-known celebrity from Redmond , gatesbillium, and microsoft will be the only company that will be allowed to sell systems based on that processor, because they are allready familiar with plain american as the only way to do programming (and business).

Sure glad this was a joke. I could read the headline for a while, but the Dot wouldn't load - it made me so nervous I had to write the KDE-General list to see if anyone knew if this was an April Fool's Day joke or not...

I get how the Javascript/XUL stuff would be just plain ridiculous, and hence appropriate for an April Fool's joke, but what about the Mozilla layout engine? I prefer it to konqueror's any day (it just works better on more sites, period).

Stability and speed are no longer issues with mozilla, and I would not mind at least having the _option_ to use Mozilla's layout engine for web surfing in konqueror (or other K* components).

Qt support for mozilla (e.g. using Qt for widget drawing instead of GDK) is in the works (I know, I know, this seems like its NEVER going to arrive) but check out bugs 70511 and 70509. They include patches (which I have not had time to try yet) but I look forward to them anyway.

Even though I choose KDE as my primary desktop, I still launch Mozilla for my web browsing needs. Why? Because Mozilla has much better Javascript support (which will actually benefit Konquerer if this article is true), faster GIF animation rendering, faster DOM implementation, more stable, and most important of all, it renders pages correctly.

I would really like to see Konqerer having the option to use Gecko as the rendering engine. The GNOME camp is doing this with their new file manager, and I would hate it if KDE's HTML rendering engine couldn't keep up with them.

Do you realize how long it's taken the Mozilla programmers to get their codebase to the point that it's at? Do you realize that the KDE developers (mostly Lars Knoll) have managed to bring out a browser with almost the same feature set, in only a few short months?

I agree that Mozilla has better JavaScript support for the moment, and *maybe* it has a better DOM implementation, but these issues are under heavy development with Konqueror. I doubt that Mozilla is more stable than Konqueror (it hasn't been for me, anyway) and if you think that Mozilla renders pages more correctly than Konqueror then you obviously haven't looked at KDE.org much. With regards to your comment about animated GIF support - all animated GIFs should be shot on sight anyway.

As for using Gecko instead of KHTML, have you checked out XParts yet? I doubt it.

"Do you realize that the KDE developers (mostly Lars Knoll) have managed to bring out a browser with almost the same feature set, in only a few short months?"

To claim that Mozilla & Konquerer have almost the same feature set is narrow-minded. I'm just gonna point out the most obvious example: the Mozilla technology is built around the idea of cross-platform & portability, while Konquerer is only built with KDE in mind. That's why Mozilla has all those XUL, XPCOM, etc., which critics call "junk". But hey, I keep a copy of Windows on my computer for things that Linux doesn't do, and guess which browser I use on Windows? It's not Konquerer for sure.

"if you think that Mozilla renders pages more correctly than Konqueror then you obviously haven't looked at KDE.org much."

I'm not sure what you're referring to. Mozilla has always rendered KDE.org fine. It even renders the web designer's mistake where the "go" button (next to the search field) is rendered as white text, which is very hard to read (unless you also specify a background for the button). Maybe the web designer should have checked the page with Mozilla instead. Konquerer didn't render the text white as specified, and it couldn't do the hovering effect until KDE 2.1.

"all animated GIFs should be shot on sight anyway."

You would say that, but what are you gonna do? =) A browser without good animated GIF support seems ridiculous by today's standard. Actually I take back what I said about animated GIF. Visit "http://www.cts.com.tw/". I originally thought animated GIF was slowing down Konquerer, but it seems like turning off image loading doesn't help either.

"As for using Gecko instead of KHTML, have you checked out XParts yet?"

Ah, I remember that. I saw the kdebingds-kmozilla RPM package in KDE 2.1 but couldn't find much information on it. Or maybe I just haven't looked hard enough.