In a press release today, Nokia announced a new web browser in the works for the Series 60 application platform. The interesting tidbit about the browser is that it is based on Apple's WebKit which is of course based on KDE's very own KHTML (wp) rendering engine. KDE is fully acknowledged in Nokia's announcement. Update: Roland Geisler, Head of Strategy for the Series 60 Browser at Nokia, wrote to the Konqueror mailing list.

Which again is kind of overenginered for embedded uses. On the other hand maintaining widgets in its own renderer instead letting a toolkit handle them leaves more room for optimizations which is why the webkit team wants to abstract out the use of Qt widgets in their khtml fork.

Guys, I just have to words. Congratulations to all my K brothers, and of course especially those involved in KHTML/KDOM/KJS. Remember, everything you have in your life is what you deserve. And you guys rock, keep it up!

Now if I could afford one of those mobiles... :-P Okay, no, I'll better wait till I can hold a whole KDE-powered Linux in my palm.

As long as they still are a major pro-software patent supporter in Europe you shouldn't be mislead by their action elsewhere. (Please note that the reason that they offered patents coverage to the original Linux kernel sources a couple weeks ago is that they would invalidate their own use of it through the GPL if they ever enforced their patents against it otherwise; same with KHTML/KJS now. But that still doesn't protect any OSS project they aren't involved in, so software patents are very dangerous even in cases like ambivalent and contracticting software patent supporters like Nokia is.)

It would have been nice from NOKIA having gone with QT/KDE rather than GTK+/GNOME. Money haven't been an issue as they have shown by spending 50k USD to GNOME-Foundation and the 99USD sales of their 770 to developers. Someone being able to act like this could easily have purchased licenses from QT. Norway and Finnland are quite close together they would have helped to improve european Software and IT industry quite a lot. Keeping their BIP and BSP in their country too.

GNOME has got a lot of 'corporate backing' and, _I_FEEL_, it didnt work out for them. Their project structure is now quite hirachic and the project get pushed into something that has to look 'simple' so it can be 'sold' as simple. In the meanwhile the framework (libraries/ technologies) is not simple at all, and very inconsistent. Often different parts of the project cannot agree on the use of technologies/ libraries and then the wheel has to be invented again. By trying to attract corporate backing GNOME is putting itself in force fields that are not healthy for the project.

This is the total opposite of the KDE 'way'. Not that in KDE everyone easily agrees on using a certian technology, but when the decision is made it is supported to a certain level.

I think when a capable handheld is running some GPL software it cant be too long before it will run other GPL software. If this handheld is going to be COOL, but, running some GPL software that is NOT COOL, it will not take long before there is a distribution of COOL software for that particular hardware and OS.

Good points. Too often people have spoken as if corporate backing for a free software project was some sort of definitive advantage that would make any other competing projects irrelevant.

Truth is, significant corporate backing can be a powerful influence, and unless it is harnessed by a strong, well established, respected project leadership, it can make the project lose its direction and afflict it with all the problems of corporate projects (such as lack of long-term focus).

GNOME was never the most organised or focused project, but left on its own it could have got better. However, it got too much corporate backing too soon and now they are slaves of the "get something out of the door" and "redefine the project every six months" mentality.

Good points, no Gnome bashing. However the Gnome framework also has advantages because of its bazaar style serving everybodies needs with bindings for x languages etc. I would like to see the same binding support for KDE. Often KDE bindings such as for Java exist but nobody seems to know about them or use them.

From my perspective more KDE - Gnome bridges are needed. E.g applications such a Gnumeric with Chrytal Icons look very similar to KDE ones. I don't think it is good that we do not have common theming and colour schemes. Also the other GUI design specifications could be harmonised.

When bindings are created but not used, should they be maintained? I dont think so. I do like the way KDE sticks to C++, Qt and its own libraries. I had a lot of installation nightmares with GTK/GNOME apps that where written in the most diverse programming languages. Spending time on maintaining bindings has to be worth it. I dont forsee any core KDE apps being written in anything but C++, that somehow keeps it simple -- allthough Python and Ruby rock the simplicity scene these days.

I do agree on your points of shared (Icon) themes and GUI specs, but it has to be sane (contrary to the, IMO, insane button order debate[1]). There are gtk-qt[2] and plastig[3] but it will never really blend.

I think you are buying the myth that since Gnome is written in C it somehow magically gets bindings for all other programming languages. The reality is that KDE has more well maintained and up to date bindings. And the available bindings are for both the core toolkit and the desktop, Qt and the KDE libs. For Gnome most of the bindings are only for GTK+, while the bindings for the Gnome libs are either absent or outdated. The main reason the Qt/KDE bindings are kept up to date are the hard work the developers have put into making automatic tools for generating the bindings. Making the amount of manual labour needed for creating bindings for new versions of the libraries relatively small.

"I think you are buying the myth that since Gnome is written in C it somehow magically gets bindings for all other programming languages."

Actually it's moved on from that, these days it's

"..that you write a GTK# binding for Mono and somehow you magically get bindings for all other programming languages"

Another variation:

"..you use a CORBA based component system and somehow you magically get bindings for all other programming languages"

I've found it's better to have just a few well maintained bindings, than large numbers of half finished efforts. So in KDE we have python, java and ruby, and I'm not sure we need much more. Maybe C# and perl too would be nice, but they aren't essential for KDE 4 in my opinion

You also need an IDE like KDevelop with support for your language, along with tutorials and documentation and a community of people who actually want to use the binding. For instance, I spent six months doing Objective-C bindings for Qt/KDE, only to find no one was slightly interested in using them.

Well maintained bindings are the key, and just as important it has to be common knowledge. As an example take the Java bindings. I don't think it's used by many, even if it has a long history of being well maintained and up to date. The Python bindings are much more visible, and 3rd party applications have been emerging for some time. What the Qt/KDE bindings need are more hype, making more developers aware. Perhaps KDE 3.5 should become a hype the bindings release:-)

You also have Javascript in addition to the Python, Java and Ruby bindings you mentioned. And I thought Perl bindings was well maintained using Smoke, same as with Ruby. Since I don't follow the development of those to closely I may have gotten the wrong impression.

Both Linux and Qt suck on small devices such as mobile phones since neither is (out of) memory safe. I've worked with Qt embedded long enough to know.
I'm not sure how KHTML handles this, but if it doesn't they can expect lots of problems on real world websites, which will ultimately crash the browser.
(If it were linux based, it would usually kill a random process due to the infamous OOM killer).

A call to malloc() will not return 0 as it should when out of memory,
resulting in a random process being killed when trying to access it.
There are ways to tune the OOM killer, and the overcommit behaviour, but still it does overcommit frequently.

This is very bad for embedded applications where memory usage is dynamic, such as in a browser. It's not as bad for other applications that use a fairly constant or predictable amount of memory.

There was GNOME/KDE discussion all along. KDE2 and GNOME were both planing on using COBRA for a long time. Eventually the KDE hackers gave up on ever making it work (or should I say work fast enough to be useful), designed DCOP on a napkin (maybe not that simple, but just about), and implemented it in a afternoon or so. A few months latter and KDE settled on DCOP for everything, much to the displeasure of the GNOME people.

GNOME seems to have given up on COBRA as well these days. I don't know what their side of that story is. The compromise is D-BUS, which fixes some of their objectsions to DCOP (though I'm not sure which), and undoubtedly fixes some things KDE learned after a few years of DCOP.

I would be really interested what KDE learned and what parts of DCOP it is supposed to fix. Especially since it seems that no KDE developer is involved ATM in the DBUS project (except for the Qt bindings).

DBUS uses a more sane marshalling format that is tied less closely to the Qt stream operators and Qt class names, it is also better in separating individual arguments which makes it easier to perform sanity checks. The message protocol is also a bit easier and more extensible than DCOP, leading to more flexibility in how messages can be handled. Asynchronous calls for example are easier to implement with DBUS, in DCOP it's a bit of a hack. The improved message protocol also makes it possible to use DBUS from threaded applications, the DCOP protocol has message sequence restrictions that makes that very difficult.

KHTML/KJS seem more alive and kicking then ever.
I remember not so long there was lots of buzz about
Gecko replacing KHTML etc.
Great that it's not so! Konq feels so much faster
and KDEish IMHO.
In my company we've been developing a _very_ complex
web application for years now with tree views,
toolbars, dialog boxes, you name it. It almost feels
like a normal application that runs inside a window.
Unfortunately it's for internal use only, so there is no demo.
We've focused on supporting IE and Mozilla. Dont talk about
standards here. They unfortunately dont work well enough if you really
need those bleeding edge features. So there is lots of trickery put
in. Personally I always used Konq for surfing as it is much faster.
So I really would have liked to support Konq too for our web app.
I gave up quickly because Konq used to not even show the line number
of a JavaScript error before so I figured it would be to complex
to find all those errors and lots of things just werent supported
at that time. Only recently I tried again to support KHTML since
Konq now shows the line number if you enable debugging.
What's still stupid IMHO is that if you disable those dialog boxes
you lose the line number information as well. It is not shown if
you double click on the "bug" symbol. So you have to click aways
lots of dialog boxes again and agin. Well, you get used to it.
Anyway, to my amazement with only some minor glitches to fix and some things
where Konq was right and our page just plain wrong, the main screen (which is already quite complex) did show up and work correctly. I really did not
expect this. The KHTML/KJS engine seems quite advanced, now.
In Safari the whole web app now works correct. Unforunately, there is
still one bug left in KHTML which spoils the whole thing: IFrames always
appear on-top of everything else. Menus, dialog boxes disappear behind
it. That makes our web app useless in Konq so far but I found there is
a bug filed in bugs.kde.org on this already so I guess it's just a
question of time before Konq is supporting this. It's really come a
long way IMO and usage by Nokia confirms that it's a competitive
and light-weight HTML/JS implementation.