| |||||||||||||
|
| |||||||||||||
KonquerorKonquerorPosted Dec 7, 2009 6:07 UTC (Mon) by Sho (subscriber, #8956)In reply to: Konqueror by Kit Parent article: KDE Software Compilation 4.4 Beta1 Released
FWIW: The WebKit KPart will be shipped with KDE SC 4.4 (and is in this beta, too), so using WebKit in Konqueror is in fact an option now.
(Log in to post comments)
Konqueror Posted Dec 7, 2009 11:44 UTC (Mon) by Sho (subscriber, #8956) [Link]
Whoops, it appears I got that wrong. The KPart has, in fact, not been moved into the Software Compilation so far. What is shipping with 4.4, however, is KDEWebKit, a library sitting on top of QtWebKit that provides various forms of KDE integration and is described here:
http://techbase.kde.org/Projects/WebKit/Library
The KPart makes use of this library, and is still being worked on.
Konqueror Posted Dec 7, 2009 12:20 UTC (Mon) by wstephenson (subscriber, #14795) [Link]
I'm following the WebKitPart development, and noticed that KWallet support for form completions went in a couple of days ago - now the only feature needed for KDE integration parity with KHTML is the the ability to update the status bar.
It's in playground/libs, so build it and give feedback!
Konqueror Posted Dec 7, 2009 15:47 UTC (Mon) by drag (subscriber, #31333) [Link]
One of the major goals in KDE should be dropping the KHTML dependency and
moving entirely to Webkit...
Konqueror Posted Dec 9, 2009 10:37 UTC (Wed) by jospoortvliet (subscriber, #33164) [Link]
Oh, many agree with you (including me). However this is an area where the
Free Software nature of the KDE community makes things a bit harder. We can't decide what the Konqueror/KHTML developers work on - that's their prerogative. Luckily some are working on the WebKit KPart, as is said, and once it is good enough (tm) it might become default one day.
Konqueror Posted Dec 7, 2009 12:43 UTC (Mon) by alankila (subscriber, #47141) [Link] WebKit is amazing. It has by far the best javascript engine out there when I've tested it with some crazy hacks like this:
HDR in javascript In particular, KHTML is able to use pretty much optimal amount of memory in the HDR experiment (where each image takes 25.6 MB if it's implemented as a double array). Firefox consumes something past 2 GB of memory when trying to calculate Fattal tone mapping operator, while WebKit runs in about 400 MB all the time, most of which is spent by the raw image data arrays. Chromium was just as bad memory-wise. The "blitting effect" doesn't run properly on Linux firefox because someone must have been lazy with the canvas tag. And let's not forget that 64-bit firefox doesn't have JIT.
Konqueror Posted Dec 7, 2009 12:44 UTC (Mon) by alankila (subscriber, #47141) [Link]
When I said KHTML, I meant WebKit. Sorry.
|
|
||||||||||||