Linked by Thom Holwerda on Sun 15th Aug 2010 18:22 UTC, submitted by Debjit
KDE "We always knew that WebKit is going to make Konqueror fast; but how much faster? Today we test that by putting Konqueror with KHTML through the SunSpider JavaScript Test and the then do the same with WebKit. To get an idea of how fast they are compared to other browsers, we also decided to put Firefox 4.0 Beta 2 through the tests."
Thread beginning with comment 436897
To read all comments associated with this story, please click here.
Why only now?!
by usr0 on Sun 15th Aug 2010 19:21 UTC
usr0
Member since:
2006-10-27

WebKit is out for years and for years there were plans to drop the home-brewed KHTML in favor of WebKit. In fact it wasn't difficult at all. I've build a WebKit-enabled Konqueror version myself years ago.

But the KDE crew have done this step only now. And there are still people complaining about big evil corp's policies that inhibit tech progress...

Reply Score: 1

RE: Why only now?!
by ssokolow on Sun 15th Aug 2010 19:40 in reply to "Why only now?!"
ssokolow Member since:
2010-01-21

As I understand it, QtWebKit didn't expose APIs required for feature parity when KDE 4.0 was released and their API stability policy requires that all APIs present in 4.0 remain throughout the release cycle, so that might have been a drag or disincentive on KWebKit development.

(That API stability policy and having been burned by an earlier GStreamer release is actually what lead to Phonon... apparently at least one GStreamer dev showed quite a lack of maturity at that development.)

Of course, API stability and functional stability are two different things. As much as I like the idea of KDE, I switched to LXDE after waiting through 4.4, still having too many bugs, and discovering that one guy in a basement can easily have a more thought out release testing plan than the KDE guys. (It also doesn't help that they see no problem with the "chuck it all out and start over" pattern that appears at every major version increment with regards to features and stability)

Edited 2010-08-15 19:41 UTC

Reply Parent Score: 4

v RE[2]: Why only now?!
by tyrione on Tue 17th Aug 2010 03:46 in reply to "RE: Why only now?!"
RE: Why only now?!
by _xmv on Mon 16th Aug 2010 01:12 in reply to "Why only now?!"
_xmv Member since:
2008-12-09

i'd like to point out even if it's easily forgotten that KHTML has had a HARD time getting proper code from Apple, so yes, they're big evil corps, thankfully the license prevailed and we now have a very good engine which is getting contributions from everywhere.

And that's why *GPL* OSS > x (call this flamebait if you wish, it stands true here)

Reply Parent Score: 2

RE[2]: Why only now?!
by KAMiKAZOW on Mon 16th Aug 2010 02:34 in reply to "RE: Why only now?!"
KAMiKAZOW Member since:
2005-07-06

Much code in WebKit has been completely replaced since KHTML. That code is BSD-licensed without the need to release it.
Collaborative open development is just beneficial for all involved parties, including Apple.

Reply Parent Score: 2

RE[2]: Why only now?!
by bousozoku on Thu 19th Aug 2010 00:57 in reply to "RE: Why only now?!"
bousozoku Member since:
2006-01-23

i'd like to point out even if it's easily forgotten that KHTML has had a HARD time getting proper code from Apple, so yes, they're big evil corps, thankfully the license prevailed and we now have a very good engine which is getting contributions from everywhere.

And that's why *GPL* OSS > x (call this flamebait if you wish, it stands true here)


Ahhh, yes "proper code", whatever that is. You mean that the code wasn't returned in the same messy state that Apple had to start with it? That it was in a completely different messy state?

Yes, they returned the code in a different way than the KHTML developers wanted and there was much moaning, despite wholesale improvements in the code.

Reply Parent Score: 2