Linked by Thom Holwerda on Thu 2nd Jul 2009 12:19 UTC
Permalink for comment 371353
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 06/18/13 22:33 UTC
Linked by Anonymous on 06/18/13 22:26 UTC
Linked by Thom Holwerda on 06/18/13 22:25 UTC
Linked by Thom Holwerda on 06/18/13 17:45 UTC
Linked by Thom Holwerda on 06/18/13 17:32 UTC, submitted by poundsmack
Linked by Thom Holwerda on 06/17/13 17:58 UTC
Linked by Thom Holwerda on 06/17/13 17:52 UTC
Linked by Thom Holwerda on 06/14/13 21:03 UTC
Linked by Thom Holwerda on 06/14/13 20:46 UTC
Linked by Thom Holwerda on 06/14/13 17:32 UTC
More News »
Sponsored Links



Member since:
2005-07-09
It depends on what "too dependent of KHTML" means. If it means, that there are 10 small classes where there are deep dependencies on KHTML, then sure. If it means, almost every part of Konqueror has deep dependencies on KHTML, then no. If this is the case, then your approach would the equivalent of making a plaid shirt one colour by cutting out all the non-red fragments and replacing them with red patches. Sure you could do it, but you'd end up with a shirt that was more patches than shirt. There comes a point when you either have to accept that you have to accept legacy for what it is, or dump legacy and start from scratch.
I don't know what's the case here, but even if the decision is to keep legacy, this doesn't have to be bad. It could be just another case where the The Bolden Rule (i.e. "If you can't fix it, feature it.") can apply. Okay, KHTML isn't as extensive as Webkit. That's a feature. It's not supposed to be any more than elinks is supposed to be anything other than a text mode web interface. Using the Bolden Rule, KHTML can focus on being more secure and lighter and even included desktop specific features.