218

Primoz wrote:I wouldn't agree with 2 and 3.
I have both webkit and KHTML and tried both for most of webpages that I use. And came to realise that for now KHTML is still better than qtWebKit.

Javascript Benchmarks:

Google V8 (the more, the better):
Firefox 3.0.8: 183
Konqueror 4.2.69 (4.3 trunk): 159
Rekonq 0.0.4 (Qt 4.5): 623

SunSpider (the less, the better):
Firefox 3.0.8: 3892.8ms +/- 4.2%
Konqueror 4.2.69 (4.3 trunk): 5488.6ms +/- 2.1%
Rekonq 0.0.4 (Qt 4.5): 2786.2ms +/- 2.3%

Acid3 tests:

Firefox 3.0.8: 71/100
Konqueror 4.2.69 (4.3 trunk): 87/100 (linktest failed)
Rekonq 0.0.4 (Qt 4.5): 100/100 (linktest failed)

I think it's quite clear which engine behaves better, as of compatibility, obviously webkit and gecko are far better, since the web devs actually test them (Firefox/Gecko and Webkit with Google Chrome, Safari, iPhone, Nokia phones, Symbian, Android, etc)

I agree that WebKit is better, but KPart in Konqueror has more problems than KHTML.
It crashes alot and behaves strangely sometimes.
So for now I use KHTML and if it fails I use WebKit, and if it fails I use FireFox .

So I'm not agains Webkit as such, I just want that KPart WebKit gets better.
And I would like to keep Konqueror I'm really starting to like all of it's options.
(I'm a recent Konqueror convert were using FireFox up to a week ago, and used konqueror as make-shift "web-developing" tool)

Primoz wrote:I agree that WebKit is better, but KPart in Konqueror has more problems than KHTML.
It crashes alot and behaves strangely sometimes.

Indeed. But Rekonq use Qt-Webkit directly as far as I understand. Howver, keeping KHTML (and waste resources on it) is completely stupid based on "the KPart of webkit isn't ready" since the hard, complex, and important part is the engine itself. KHTML should be dropped in favor of WebKit, and all man-power redirected to Webkit and its KPart.

Primoz wrote:So for now I use KHTML and if it fails I use WebKit, and if it fails I use FireFox .

Of course, but this is an idea for KDE > 4.2.

Primoz wrote:So I'm not agains Webkit as such, I just want that KPart WebKit gets better.
And I would like to keep Konqueror I'm really starting to like all of it's options.
(I'm a recent Konqueror convert were using FireFox up to a week ago, and used konqueror as make-shift "web-developing" tool)

Again, I don't think nobody is suggesting to kill Konqueror, just to use something else as default.

augustofretes wrote:Indeed. But Rekonq use Qt-Webkit directly as far as I understand. Howver, keeping KHTML (and waste resources on it) is completely stupid based on "the KPart of webkit isn't ready" since the hard, complex, and important part is the engine itself. KHTML should be dropped in favor of WebKit, and all man-power redirected to Webkit and its KPart.

Which is a moot point, if I've understood things correctly. As I've understood it, it is not possible to drop khtml (regardless of whether it's worse or not than webkit) for the forseeable future (during the entire lifecycle of KDE 4.x.x as I recall it). Too many other things require it to be present.

Now, I'm not sure if I remember things correctly but if I do khtml at the very least needs to be maintained for quite a while.

Kryten2X4B wrote:

augustofretes wrote:Indeed. But Rekonq use Qt-Webkit directly as far as I understand. Howver, keeping KHTML (and waste resources on it) is completely stupid based on "the KPart of webkit isn't ready" since the hard, complex, and important part is the engine itself. KHTML should be dropped in favor of WebKit, and all man-power redirected to Webkit and its KPart.

Which is a moot point, if I've understood things correctly. As I've understood it, it is not possible to drop khtml (regardless of whether it's worse or not than webkit) for the forseeable future (during the entire lifecycle of KDE 4.x.x as I recall it). Too many other things require it to be present.

Now, I'm not sure if I remember things correctly but if I do khtml at the very least needs to be maintained for quite a while.

What requires KHTML to exist? I don't think such a thing exists, specially since WebKit can easily replace KHTML, and they have a similar code base (because, as all of you know, WebKit is a derivate from KHTML)

augustofretes wrote:

Kryten2X4B wrote:

augustofretes wrote:Indeed. But Rekonq use Qt-Webkit directly as far as I understand. Howver, keeping KHTML (and waste resources on it) is completely stupid based on "the KPart of webkit isn't ready" since the hard, complex, and important part is the engine itself. KHTML should be dropped in favor of WebKit, and all man-power redirected to Webkit and its KPart.

Which is a moot point, if I've understood things correctly. As I've understood it, it is not possible to drop khtml (regardless of whether it's worse or not than webkit) for the forseeable future (during the entire lifecycle of KDE 4.x.x as I recall it). Too many other things require it to be present.

Now, I'm not sure if I remember things correctly but if I do khtml at the very least needs to be maintained for quite a while.

What requires KHTML to exist? I don't think such a thing exists, specially since WebKit can easily replace KHTML, and they have a similar code base (because, as all of you know, WebKit is a derivate from KHTML)

I think that KHTML is needed in any KDE app that demands that HTML is rendered, as it's much more Qt and KDE integrated as WebKit or WebKitQt.
At least for now.
I know that at least Dolphin would be affected, AFAIK it's HTML preview is rendered using KHTML, but I'm not usre.
It's true that KHTML is very similar to WebKit infect WebKit is just KHTML optimized and without Qt specific dependancies.
So maybe KHTML could be droped in KDE5.
But that's up to developers, if they want to start developing on WebKit instead of KHTML, it's OK. But if they still mantian KHTML we still have WebKit KPart and Arora and ReKonq.

augustofretes wrote:What requires KHTML to exist? I don't think such a thing exists, specially since WebKit can easily replace KHTML, and they have a similar code base (because, as all of you know, WebKit is a derivate from KHTML)

I don't know what it may be. I only know I've read it on some developer's blog or even in this very forum (sorry, can't remember where). I can't vouch for the validity of the claim, only that I've seen it discussed/mentioned.

Easily? Maybe, maybe not. I don't know the inner workings of either one, but webkit has been around for a while. It's not unreasonable to think that it has diverged so much from its khtml origins that it would be very hard to merge the changes back without causing regressions somewhere along the way. Actually, I suspect that is why the webkit kpart, so far, is inferior to khtml.

Kryten2X4B wrote:I don't know what it may be. I only know I've read it on some developer's blog or even in this very forum (sorry, can't remember where). I can't vouch for the validity of the claim, only that I've seen it discussed/mentioned.

Easily? Maybe, maybe not. I don't know the inner workings of either one, but webkit has been around for a while. It's not unreasonable to think that it has diverged so much from its khtml origins that it would be very hard to merge the changes back without causing regressions somewhere along the way. Actually, I suspect that is why the webkit kpart, so far, is inferior to khtml.

They even used to share improvements and patches, they probably still do it. The KPart is inferior because it isn't really getting much attention.

Primoz wrote:I think that KHTML is needed in any KDE app that demands that HTML is rendered, as it's much more Qt and KDE integrated as WebKit or WebKitQt.
At least for now.
I know that at least Dolphin would be affected, AFAIK it's HTML preview is rendered using KHTML, but I'm not usre.
It's true that KHTML is very similar to WebKit infect WebKit is just KHTML optimized and without Qt specific dependancies.
So maybe KHTML could be droped in KDE5.
But that's up to developers, if they want to start developing on WebKit instead of KHTML, it's OK. But if they still mantian KHTML we still have WebKit KPart and Arora and ReKonq.

I think WebKit can handle HTML rendering XD. I don't understand why it couldn't handle what other KDE apps could possibly demand (this doubles as a question).

augustofretes wrote:They even used to share improvements and patches, they probably still do it. The KPart is inferior because it isn't really getting much attention.

Now they do. As far as I know, it wasn't like that in the beginning. If they had, the need for a fork wouldn't have been as necessary I'd say. Still, those months/years may have introduced things not easily backported.

augustofretes wrote:I think WebKit can handle HTML rendering XD. I don't understand why it couldn't handle what other KDE apps could possibly demand (this doubles as a question).

For one thing, webkit is more generic than khtml. Khtml requires Qt and/or kde-libs as far as I know. Webkit doesn't (as evidenced by the fact that gnome and windows apps, as well as MacOS X) can and does use it. Generic is usually a good thing, but what if something in khtml (or the rest of the KDE-stack) requires something that was stripped away in webkit to make it more generic?

Few interesting links I found (they might be old, but they are still more or less accurate):
http://blue-gnu.biz/content/khtml_vs_we ... _not_merge
http://blog.froglogic.com/2007/10/the-khtml-future-faq/

Will post more if I found anything interesting.

Why should be rekonq the default webbrowser? Which rekonq-features are missing in Konqueror?
I think it's good for newbies and professionals to have the KPart-based Konqueror. Newbies like the PDF-integration, professionals like the ftp- and ssh-features. Why should it be replaced by a buggy browser which does not provide most Konqueror-features.
We have Webkit-part, we don't need a completely new browser. And if anybody want's to have a webbrowser without all those filemanagement features, this new browser should be created with Konqueror code so that both would profit from improvements in one application.

The User wrote:Why should be rekonq the default webbrowser? Which rekonq-features are missing in Konqueror?

First of all please remember that rekonq is in very early stage and it's under heavy development (it's 0.0.x for a reason...). So you can't consider it as "default browser".
It's not about features, but more about doing things different. Konqueror and rekonq have different goals.

The User wrote:I think it's good for newbies and professionals to have the KPart-based Konqueror. Newbies like the PDF-integration, professionals like the ftp- and ssh-features. Why should it be replaced by a buggy browser which does not provide most Konqueror-features.

If you've found a bug or have feature request please report it:
http://code.google.com/p/rekonq/issues/entry
but remember to compile from branch that is currently under development (mainline don't get much attention recently)
Here is the list:
http://gitorious.org/projects/rekonq

The User wrote:We have Webkit-part, we don't need a completely new browser. And if anybody want's to have a webbrowser without all those filemanagement features, this new browser should be created with Konqueror code so that both would profit from improvements in one application.

It is created with lots of code that Konqueror uses as well (KDE libs like KIO and KBookmarks, etc.), but it doesn't share the code base. You propose to use Konqueror's code, but unfortunately it's not so simple because Konqueror was written with very different goal in mind. But I'm sure there are things that can be generalized.

Remember that if someone is making this software that means that someone needs it.

The User wrote:Why should be rekonq the default webbrowser? Which rekonq-features are missing in Konqueror?

Nobody is saying it should be replaced now. And, actually, Rekonq does have one feature Konqueror doesn't (Private Mode).

The User wrote:I think it's good for newbies and professionals to have the KPart-based Konqueror. Newbies like the PDF-integration, professionals like the ftp- and ssh-features. Why should it be replaced by a buggy browser which does not provide most Konqueror-features.

Most Konqueror features are just confusing for a new user, and to be fair, most of them are useless (as far as web browsing is concerned).

The User wrote:We have Webkit-part, we don't need a completely new browser. And if anybody want's to have a webbrowser without all those filemanagement features, this new browser should be created with Konqueror code so that both would profit from improvements in one application.

Yes we do, Konqueror interface, menus, and everything all around is a mess. It's cluttered, confusing and clumsy. It won't be created with Konqueror code, I don't think is an easy task (see Dolphin), but, they could share the WebKit Kpart.

I wouldn't say, "Useless": the Okular KPart easily outperforms any other web-browser's built-in PDF viewer, and the Gwenview KPart for viewing Images works perfect.

I actually have been browsing YouTube with Konqueror since 4.2.2 was released - because now I can, it's faster then Firefox and the damned videos work. I also just checked GMail in Konqueror - other then an orange strip at the top that complains that the browser isn't recognised, it does everything I tried exactly the same as Gecko.

From my perspective, it looks like it would be a damn-site easier to just improve KHTML. If we started using WebKit, then any patches by our devs would first have to go to Apple, who would have a different release schedule to KDE, then we'd have to wait for them to be applied or rejected, then wait some more for the next stable release, then wait for that release to hit Qt... with KHTML, it gives the KDE devs much greater control over things like bug-fixes, patches, features and releases compared to if we started using WebKit. Besides, if we were to change to WebKit it wouldn't be over-night (we saw what happened with KDE 4.0) and would require more resources then to just maintain KHTML.

The only thing that's lacking in KHTML is interest. Personally, I prefer it over current rivals right now (especially considering my last encounter with Safari...)

Madman wrote:I wouldn't say, "Useless": the Okular KPart easily outperforms any other web-browser's built-in PDF viewer, and the Gwenview KPart for viewing Images works perfect.

The only one that makes sense is the PDF KPart, the GWenview KPart is bad.

Madman wrote:I actually have been browsing YouTube with Konqueror since 4.2.2 was released - because now I can, it's faster then Firefox and the damned videos work. I also just checked GMail in Konqueror - other then an orange strip at the top that complains that the browser isn't recognised, it does everything I tried exactly the same as Gecko.

KHTML has always been better than Gecko on my eyes (except for compatibility of course).

Madman wrote:From my perspective, it looks like it would be a damn-site easier to just improve KHTML. If we started using WebKit, then any patches by our devs would first have to go to Apple, who would have a different release schedule to KDE, then we'd have to wait for them to be applied or rejected, then wait some more for the next stable release, then wait for that release to hit Qt... with KHTML, it gives the KDE devs much greater control over things like bug-fixes, patches, features and releases compared to if we started using WebKit.

Not really, but you're free to believe it.

Madman wrote:Besides, if we were to change to WebKit it wouldn't be over-night (we saw what happened with KDE 4.0) and would require more resources then to just maintain KHTML.

We don't just "need to mantain KHTML", since it's way inferior to WebKit, if we are going to use KHTML is should be as good as WebKit, and that's most likely impossible. Also, nobody is talking about magic changes.

Madman wrote:The only thing that's lacking in KHTML is interest. Personally, I prefer it over current rivals right now (especially considering my last encounter with Safari...)

Google Chrome and Safari are both faster than Konqueror using KHTML, more compatible with websites, and pass the Acid3 test with 100/100.

There isn't one single reason to use KHTML over WebKit (for web browsing), improving the KPart, or simply using Qt-WebKit are far better options.