Comments on: The KHTML Future FAQ http://blog.froglogic.com/2007/10/the-khtml-future-faq/ A company weblog Fri, 12 Mar 2010 16:10:57 +0000 http://wordpress.org/?v=2.5 By: We need WebKit http://blog.froglogic.com/2007/10/the-khtml-future-faq/#comment-14619 We need WebKit Thu, 28 Aug 2008 03:46:47 +0000 http://blog.froglogic.com/2007/10/the-khtml-future-faq/#comment-14619 You don't need to drop KHTML, what we want is WebKit support, that's all we need. You don’t need to drop KHTML, what we want is WebKit support, that’s all we need.

]]> By: Max Howell http://blog.froglogic.com/2007/10/the-khtml-future-faq/#comment-12980 Max Howell Thu, 05 Jun 2008 12:55:47 +0000 http://blog.froglogic.com/2007/10/the-khtml-future-faq/#comment-12980 I respect your decision. But you must realise, everytime there's a bug in KHTML, everytime it misrenders a page. Everytime it is slow, or it crashes, people will say "WebKit wouldn't do that". Not using WebKit is not to the benefit of KDE. That is not to say that KHTML should not live on. The best ideas come from active projects with different design goals. But the best option for the entire KDE userbase is for Konqueror to use WebKit. And you know it. I respect your decision. But you must realise, everytime there’s a bug in KHTML, everytime it misrenders a page. Everytime it is slow, or it crashes, people will say “WebKit wouldn’t do that”.

Not using WebKit is not to the benefit of KDE. That is not to say that KHTML should not live on. The best ideas come from active projects with different design goals. But the best option for the entire KDE userbase is for Konqueror to use WebKit. And you know it.

]]> By: There's still time http://blog.froglogic.com/2007/10/the-khtml-future-faq/#comment-10927 There's still time Mon, 31 Mar 2008 05:51:48 +0000 http://blog.froglogic.com/2007/10/the-khtml-future-faq/#comment-10927 KHTML maintainers should have been a role model for freedom and openness value in Free Software by welcome WebKit along side KHTML as an option for distros/end-users. And there's still time :) KHTML maintainers should have been a role model for freedom and openness value in Free Software by welcome WebKit along side KHTML as an option for distros/end-users. And there’s still time :)

]]> By: ben http://blog.froglogic.com/2007/10/the-khtml-future-faq/#comment-8874 ben Tue, 12 Feb 2008 04:13:08 +0000 http://blog.froglogic.com/2007/10/the-khtml-future-faq/#comment-8874 I Know It Seems So Easy To Accept Webkit, But From The KDE Developers Prospective, If Apple Decides To Not Give Them SVN Access, They Can't Make Changes, Which Screws Them Up Until They: 1) Regain SVN Access OR 2) Fork Webkit. As This Would Be Extremely Disruptive, Retain Control By Using KHTML Is The Best Option. I Know It Seems So Easy To Accept Webkit, But From The KDE Developers Prospective, If Apple Decides To Not Give Them SVN Access, They Can’t Make Changes, Which Screws Them Up Until They: 1) Regain SVN Access OR 2) Fork Webkit. As This Would Be Extremely Disruptive, Retain Control By Using KHTML Is The Best Option.

]]> By: Harri Porten http://blog.froglogic.com/2007/10/the-khtml-future-faq/#comment-3374 Harri Porten Wed, 24 Oct 2007 18:45:23 +0000 http://blog.froglogic.com/2007/10/the-khtml-future-faq/#comment-3374 Jakob: Of course we are willing to compromise. It might not be visible to an outsider but we already spent hours of patching, martyring our brain and discussions on that. niko: A KDE branch sounds like the best option to me, too. m.dev: Whoever added the doc entry must have been mislead by whatever talk picked up somewhere. Hence the need for the FAQ;) Jakob: Of course we are willing to compromise. It might not be visible to an outsider but we already spent hours of patching, martyring our brain and discussions on that.

niko: A KDE branch sounds like the best option to me, too.

m.dev: Whoever added the doc entry must have been mislead by whatever talk picked up somewhere. Hence the need for the FAQ;)

]]> By: Dan http://blog.froglogic.com/2007/10/the-khtml-future-faq/#comment-3362 Dan Wed, 24 Oct 2007 15:04:13 +0000 http://blog.froglogic.com/2007/10/the-khtml-future-faq/#comment-3362 Andreas: yes, it would be really great and unique feature! However, the question I cannot answer is, if it can be implemented. I do not know the codebase of Konqueror, but I can imagine that there might be some design differences which makes it impossible :-( Andreas: yes, it would be really great and unique feature! However, the question I cannot answer is, if it can be implemented. I do not know the codebase of Konqueror, but I can imagine that there might be some design differences which makes it impossible :-(

]]> By: Jan Olšan http://blog.froglogic.com/2007/10/the-khtml-future-faq/#comment-3356 Jan Olšan Wed, 24 Oct 2007 14:07:28 +0000 http://blog.froglogic.com/2007/10/the-khtml-future-faq/#comment-3356 From the point of webpage compatibility, Gecko with its ever-rising share would be much better option - and its not controlled by corporation. It would be far more level relationship with Mozilla.org... I know though, that Gecko has heavier (memory) footprint. It is quite likely, that, form the reasons posted here, it would soon become necessary to fork (Qt)webkit again, meaning that Safari-driven compatibility with webpages would be lost again. Also note that Safari is less supported by pages than Firefox. What is important is, that KDE must not let go control over the development of its central component - the html rendering engine. Spice must flow, as they say. From the point of webpage compatibility, Gecko with its ever-rising share would be much better option - and its not controlled by corporation. It would be far more level relationship with Mozilla.org… I know though, that Gecko has heavier (memory) footprint.

It is quite likely, that, form the reasons posted here, it would soon become necessary to fork (Qt)webkit again, meaning that Safari-driven compatibility with webpages would be lost again. Also note that Safari is less supported by pages than Firefox.

What is important is, that KDE must not let go control over the development of its central component - the html rendering engine. Spice must flow, as they say.

]]> By: m.dev http://blog.froglogic.com/2007/10/the-khtml-future-faq/#comment-3354 m.dev Wed, 24 Oct 2007 13:51:23 +0000 http://blog.froglogic.com/2007/10/the-khtml-future-faq/#comment-3354 Btw. on KDE 4.0 API Reference KHTML page is written: "KHTML is likely to be superseded by WebKit in KDE 4.1 / Qt 4.4." This is great! So there is really chance that KHTML will be replaced by QtWebKit in KDE 4.1 (despite injured ego of remaining KHTML developers). Btw. on KDE 4.0 API Reference KHTML page is written:

“KHTML is likely to be superseded by WebKit in KDE 4.1 / Qt 4.4.”

This is great! So there is really chance that KHTML will be replaced by QtWebKit in KDE 4.1 (despite injured ego of remaining KHTML developers).

]]> By: Peter http://blog.froglogic.com/2007/10/the-khtml-future-faq/#comment-3353 Peter Wed, 24 Oct 2007 13:48:55 +0000 http://blog.froglogic.com/2007/10/the-khtml-future-faq/#comment-3353 I love Konqueror, and spend most of my day in a Konqueror session, because of the easy access to ioslaves and the fantastic embedded document viewers. However, I honestly believe that moving to Webkit would be the best thing to do for KDE. Why? Many eyes, many users. There'd be more people developing the HTML renderer, meaning that bugs would be fixed slightly more quickly and that it would be more likely to survive people losing interest in the project and moving onto other things. There'd be more people using the renderer, meaning that there would be a greater incentive for website owners to go the effort of compatibility. We'd end up with Konqueror being just as powerful, but with better support from developers and website owners. And that can't be a bad thing for users; quite the contrary. On the other hand, *not* using Webkit as the engine would likely alienate users who expect KDE's web browser to work well with all the websites they like to use, leading them to shun Konqueror completely, and thus miss out on its many awesome features -- I know several such users personally. What are the *downsides* to moving to Webkit as the rendering backend -- given that a Webkit kpart already exists? I love Konqueror, and spend most of my day in a Konqueror session, because of the easy access to ioslaves and the fantastic embedded document viewers.

However, I honestly believe that moving to Webkit would be the best thing to do for KDE. Why? Many eyes, many users. There’d be more people developing the HTML renderer, meaning that bugs would be fixed slightly more quickly and that it would be more likely to survive people losing interest in the project and moving onto other things. There’d be more people using the renderer, meaning that there would be a greater incentive for website owners to go the effort of compatibility.

We’d end up with Konqueror being just as powerful, but with better support from developers and website owners. And that can’t be a bad thing for users; quite the contrary.

On the other hand, *not* using Webkit as the engine would likely alienate users who expect KDE’s web browser to work well with all the websites they like to use, leading them to shun Konqueror completely, and thus miss out on its many awesome features — I know several such users personally.

What are the *downsides* to moving to Webkit as the rendering backend — given that a Webkit kpart already exists?

]]> By: m.dev http://blog.froglogic.com/2007/10/the-khtml-future-faq/#comment-3347 m.dev Wed, 24 Oct 2007 12:56:02 +0000 http://blog.froglogic.com/2007/10/the-khtml-future-faq/#comment-3347 KHTML is dead. Long live WebKit! KHTML is dead. Long live WebKit!

]]>