Nokia Engineers on KHTML
Rich writes "KDE could soon be making its way into your mobile phone. At aKademy in August David Carson and Deepika Chauhan from Nokia presented the work they've done in integrating KDE components into the latest version of the company's mobile phone software. Philip Rodrigues discusses this work with them on dot.kde.org."
Yes, WebCore is Apples fork of KHTML. Read here for an explanation on how the collaboration between the projects works.
WebCore is LGPL. They have to make their changes available to people who buy their 'phones (they also have to allow their customers to use a different version of WebCore, which could be interesting). They do not have to contribute their changes directly back to Apple, but they probably will since it is usually much easier to contribute patches than maintain a fork (note that this didn't apply to Apple when they forked KHTML, since they were throwing more developer time at the codebase than KHTML had in total, so it was easier to fork).
I am TheRaven on Soylent News
Yes. If you think specifically of KDE/QT - check out what runs on zaurus, ipaq, and whatnot, but you have to remember that this is Qtopia, not the same thing you have as a kde desktop, although resourcewise, KDE is becoming lighter and lighter...
Also, they speak about a rendering engine, not a GUI/OS solution (and afaik Nokia did a browser using khtml but with GTK UI).
As I understand it -- and have read elsewhere -- Nokia became interested through Apple's interest in kHTML.
After all, Apple have had some success with Quicktime on mobile devices and Nokia like that kind of stuff.
There's been all kinds of talk of Apple and Nokia gettin' all cozy on some smart phone stuff, but nothing has been confirmed, yet...
Sigh, this again. In X when the client and the server are on the same machine, communication is by local Unix sockets, which are the fastest form of IPC on Linux. Keith Packard wrote a new X server (kdrive) to demonstrate that X doesn't have to be slow, and he was right: the "overhead" of the client/server communication is nothing compared to the time it takes smaller systems to draw.
it's not KDE. It's KHTML.
KHTML has a far lower footprint than something like GECKO(mozilla firefox).
...and that is all I have to say about that.
http://jessta.id.au
RTFA:
Bogtha Bogtha Bogtha
There are two ports, one from Apple and one based off the work from Apple by Nokia. Here's the link I think you're referring to:
http://gtk-webcore.sourceforge.net/
From the page: "Gtk+ WebCore is a Linux/Gtk+ port of Apple Computer Inc.'s WebCore KHTML html rendering engine including a web component. A reference browser implementation is included in the project. Gtk+ WebCore is a standards compliant (X)HTML rendering engine, javascript interpreter and an embeddable web component. The purpose of the web component is to be a light-weight, easy-to-compile and embed, open source rendering component.
The project work is done at Nokia Research Center (NRC) as part of ongoing internet browser-related research activities. By releasing the source we hope to support in open source communities interested in using KHTML rendering engine component."
Since that was written, the world has moved on. Apple launched the WebKit open-source project as part of OpenDarwin. This means that WebKit bugs are now being tracked in bugzilla (in addition to Apple's internal bug tracking system), and WebKit, WebCore and JavaScriptCore have moved to a publicly accessible CVS server.
What the hell phone do you have that goes flat after 1 day?!
I run a Microsoft / Orange SPV C500 and its loaded with features.. MSN Messenger, Internet Explorer, Media Player, etc - I use it heavily for SMS texting (250/month roughly) and make about 2 or 3 calls a week on average and it usually lasts me about 5 days between charging. Its small too!
"Hey! Unless this is a nude love-in, get the hell off my property!!"
Sigh, this again. In X when the client and the server are on the same machine, communication is by local Unix sockets, which are the fastest form of IPC on Linux. 1. Why do you need IPC? Because the X drwaing code is in a diferent process. This is not the case in many embedded platforms, where the drawing code is in the OS kernel or the application itself. In such situations, the overhead of local Unix sockets is rather significat (and most of the time unacceptable). 2. Because you have to deal with the case where the client and the server are not in the same machine with the same code, code for X that uses bitmaps tends to store both "local" and "server" copys of images, thus doubling memory usage.
True.
That's an interesting but (IMO) false interpretation of the LGPL.