RW posted on Mon, 19 Mar 2012 22:36:08 +0000 as excerpted:
> On Mon, 19 Mar 2012 16:01:33 -0600 Wood Jeff wrote:
>
>
>> so exactly how are webkit and khtml linked? how are they different?
>> is one just a fork or a port of the other?
>
> http://en.wikipedia.org/wiki/WebKit
>
>> is the Mac OSX just a variant of KDE or based in part on KDE?
>
> Nothing to do with KDE.
OSX the OS? Indeed, nothing to do with KDE the DE.
The webkit rendering engine for their Safari web browser, a single app
(tho the rendering engine may be leveraged for use with other apps in the
system) on that OS? That was indeed forked from KHTML, the rendering
engine behind konqueror.
I too will refer you (Wood Jeff) to the wikipedia webkit article. It
seems accurate based on what I know as of my reading it just now, altho
any good debater will know the limits of quoting wikipedia and the value
of quoting other sources as well. But the wikipedia webkit article's a
good place to start, and you can follow and quote its references
directly, if you prefer.
http://en.wikipedia.org/wiki/WebKit
While you're at it, look up khtml as well:
http://en.wikipedia.org/wiki/Khtml
And, the google for both terms together should be useful:
http://www.google.com/search?q=webkit+khtml
A few bits that can be found in the references above but that I'd like to
emphasize:
While initially there was some friction between the Apple/webkit and KDE/
khtml folks, they eventually worked things out and were able to
cooperate /reasonably/ well. Altho the coding styles are different and
they remained separate projects, the kde/khtml devs were able to
incorporate many of the webkit improvements... improvements that wouldn't
have been made or that would have taken rather longer had the khtml devs
had to develop them from scratch.
Qt incorporated webkit into its own qt-webkit module. Of course, kde is
qt-based, so that gave kde devs a choice of rendering technology to use.
At first that was in only relatively light and new code, qt-webkit for
rendering web content in plasmoids (plasma desktop widgets), for
instance, but a webkit kpart was developed, and with recent kde with the
appropriate components installed, it's possible to select either the khtml
or webkit kparts for konqueror html/web rendering. (There's also a newer
and less mature kde browser, rekonq, that's webkit only, AFAIK.)
For kde4 at least, khtml will remain, as it's part of what defines kde4
and failing to provide it would break compatibility for third party kde4-
based apps. While I'm not sure what the khtml status is for kde
frameworks aka kde5, I can certainly speculate. =:^)
I DO know that frameworks is supposed to be MUCH more modular (thus the
name). Based on that, while it was previously speculated that khtml may
be deprecated or phased out in kde5, with the more modular frameworks,
it's quite possible that it'll remain, but only as an optional framework
component, pulled in if you're running anything that depends on it, but
not as part of the much smaller core.
Also note that some of the current kde4 kdelibs functionality will be
incorporated into qt5, which is supposed to be much more modular as
well. So the kde frameworks core should be MUCH smaller, with parts of
it being incorporated into qt5 while other parts are split off into
optional components.
It follows that with qt5-webkit becoming stronger and more mature on the
one hand and the modularization of kdelibs on the other, I personally
don't see khtml's place in the frameworks core, tho as I said, it's
likely to remain an optional component, pulled in as an optional or
mandatory dependency by some kde apps.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
