218

I do not see any useless Konqueror-features.
Don't you like KParts?

I said it would be possible to create a separate browser (although I wouldn't prefer it) but rekonq would be a bad solution because it does not share the code base. The should be a common base like between Konqueror and Dolphin. There should not be anything like "one part of the addons are only for Konqueror and another part is only for the other browser".

I think KHTML is sometimes faster. I am not a KHTML developer: Are there special KHTML-features which should be merged with Webkit-Features?

The User wrote:I do not see any useless Konqueror-features.
Don't you like KParts?

Yes I do, I think they're great, but their implementation on Konqueror is quite clumsy, however, this could change, on the other hand, I don't 99% of the users need all of them in their browser, the PDF KPart is good, the GWenview KPart, if improved, could be good, the rest is just annoying XD.

The User wrote:I said it would be possible to create a separate browser (although I wouldn't prefer it) but rekonq would be a bad solution because it does not share the code base. The should be a common base like between Konqueror and Dolphin. There should not be anything like "one part of the addons are only for Konqueror and another part is only for the other browser".

Rekonq uses Qt-Webkit directly, that's true, it would be better if it use the Webkit KPart, I agree.

The User wrote:I think KHTML is sometimes faster. I am not a KHTML developer: Are there special KHTML-features which should be merged with Webkit-Features?

Mmm, I have never feel that KHTML is faster than WebKit, however, it does seems faster than Gecko, on the other hand, Opera and the beta Firefox are really improving.

I think the solution would be: A simple button to switch between Webkit and KHTML.
The default one isn`t important. All the other features I think will get into konqueror soon.

Jeremy wrote:I think the solution would be: A simple button to switch between Webkit and KHTML.
The default one isn`t important. All the other features I think will get into konqueror soon.

Such a swtich exists... The problem is what to use by default (which imo more important than the simple button). Also, the problem is in Konqueror interface.

I definitely support the move to using Webkit (QtWebkit). I know that the Kubuntu devs, as part of discussion for Jaunty, even considered bundling Konqueror to use Webkit by default. Webkit, after all, is originally based upon KHTML, but it has been far more actively developed because of Apple's Safari development team. I think the job that the KHTML devs have done is wonderful, but it quite frankly is a waste of resources to continue "duplicate" development.

BTW, I downloaded the QT 4.5 SDK today, I ran the demo browser using QtWebkit. Javascript is extremely fast, and it scored 100/100 on the Acid3 test, although the LinkTest failed. Flash also rendered fine, although I couldn't get the sound to work. Scrolling though a web page was similar to Firefox, although far from KHTML's smooth scrolling. All the end of the day, QtWebkit is not perfect, but I believe it is still a better alternative to KHTML. I seriously hope that this is integrated into Konqueror in the near future.

We don't just "need to mantain KHTML"

That's not actually what I said... someone's getting a bit ahead of himself, aren't they?
I actually said it would be easier to maintain KHTML and improve it (as it has been a huge amount between KDE 4.2.1 and KDE 4.2.2). If it made such leaps and bounds in terms of performance and compliance every minor release - hell, maybe even every other minor release - then it could easily be up-to-scratch with WebKit in the space of a few months.
Since you're taking the quote-and-shoot-down stance, I may as well start as well:

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

Unless you can prove the, "Not really" bit, I'll continue being, "free to believe it."

Yes I do, I think they're great, but their implementation on Konqueror is quite clumsy, however, this could change, on the other hand, I don't 99% of the users need all of them in their browser, the PDF KPart is good, the GWenview KPart, if improved, could be good, the rest is just annoying XD.

That's down to opinion, and how you use them. Konqueror, my preferred website design platform: http://imagebin.ca/view/2xzHd1.html. I use several KParts integrated into Konqueror very often and find them only a pleasure to use. I couldn't live without.

... and pass the Acid3 test with 100/100.

See, that actually annoys me a bit: it turned out that the build of WebKit that passed Acid3 was heavily flawed and unstable, and the implemented, "features" were actually only implemented enough to pass the test, making them just about useless in any other testcase. http://blog.codedread.com/archives/2008 ... t-smiling/
I prefer a browser that doesn't pass all the tests but has more full implementations of the standards it DOES have, myself...

But of course, I'm so ashamed that I can't use Konqueror for all those sites out there using animated SVG images. Oh, wait...

I use the KParts-stuff to have a full feature FTP-client.
Left: Local filesystem.
Right: Remote filesystem (ftp), edit some configuration-files with the editor...
Bottom: Display the Website via http
And you can use it for much more things.

I think it'd would be good to have an independent render-engine controllable by KDE. But it would also be good to remerge some of the Webkit-stuff to KHTML.

Madman wrote:

We don't just "need to mantain KHTML"

That's not actually what I said... someone's getting a bit ahead of himself, aren't they?
I actually said it would be easier to maintain KHTML and improve it (as it has been a huge amount between KDE 4.2.1 and KDE 4.2.2). If it made such leaps and bounds in terms of performance and compliance every minor release - hell, maybe even every other minor release - then it could easily be up-to-scratch with WebKit in the space of a few months.

KHTML feels amazingly inferior, and I'm not even using 4.2.2, I'm using trunk.

Madman wrote:

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

Unless you can prove the, "Not really" bit, I'll continue being, "free to believe it."

I did it. If the number of developers, and the current features, aren't enough for you to realize that KHTML won't ever catch WebKit then you're just blind

Madman wrote:

Yes I do, I think they're great, but their implementation on Konqueror is quite clumsy, however, this could change, on the other hand, I don't 99% of the users need all of them in their browser, the PDF KPart is good, the GWenview KPart, if improved, could be good, the rest is just annoying XD.

That's down to opinion, and how you use them. Konqueror, my preferred website design platform: http://imagebin.ca/view/2xzHd1.html. I use several KParts integrated into Konqueror very often and find them only a pleasure to use. I couldn't live without.

Yes, yes, those are such an "average Joe" most used features. Also, I'm saying they are bad implemented, and most of them are badly used as default (also, they make Konqueror amazingly cluttered), this, however, can be changed.

Madman wrote:

... and pass the Acid3 test with 100/100.

See, that actually annoys me a bit: it turned out that the build of WebKit that passed Acid3 was heavily flawed and unstable, and the implemented, "features" were actually only implemented enough to pass the test, making them just about useless in any other testcase. http://blog.codedread.com/archives/2008 ... t-smiling/
I prefer a browser that doesn't pass all the tests but has more full implementations of the standards it DOES have, myself...

Well, in any case, WebKit works better, since it passes the test, it's faster with JavaScript, and renders more sites, so... No argument there.

The number 1 reason I still think KHTML should stay remains the same: the KDE devs have greater control over it. When a bug is filed about KHTML, the KDE devs can directly modify the source without obstruction, compared to the hoops they'd have to jump through to fix bugs in WebKit... which is actually what you were supposed to be proving wrong when you said, "Not really". Go look over your post again and you'll see what I mean.

Besides, having compared konqueror with Rekonq on various sites including Youtube and Myspace, the difference in speed was so minute I could barely tell.

If the massive changelog, speed improvements and bugfixes between 4.2.1 and 4.2.2 and the speed of KHTML development (a direct result of having direct access to the code without obstruction) hasn't convinced you that KHTML is still alive and still has great potential, then you're just blind

And I still don't understand how the KParts interface is, "amazingly cluttered". The top toolbar changes depending on the KPart, the main window shows the KPart and... that's about it. What IS cluttered is when you try embedding a spreadsheet into a word document in MS Office... Now, THAT is nightmarish, with 5-odd toolbars appearing and disappearing every time you sneeze. I don't see how the KParts interface is cluttered, and it means Konqueror can replace any number of other applications I could need (Above, Quanta Plus is easily replaced...). One thing that niggles me a bit is ambiguous shortcuts, but that's already being fixed, I believe.

Just my personal opinion, i think khtml, kjs themselves stand at the same level with gecko and webkit.
Konqueror mainly lacks a powerful extension architecture compared to Firefox.

If implement such things, it will also help fix rendering of non-standard site by provide an script extension to alter the page before render (such as Firefox's greasemonkey, gmail helper etc..)

There should be Gecko KPart.

I love konqueror (no, don't give me a new browser) and I wonder if it would be possible to let the user choose between different rendering engines, say KHTML, Webkit and Gecko, so he/she can use the one that prefer from time to time.

For example, since I know that firefox is really resources-hungry, I browse mostly with konqueror, that is faster for me, but for some pages I need to switch back to firefox, since they aren't rendered correctly by KHTML.

But if I could switch the rendering engine to Gecko in konqueror, I could always get a perfect page, without opening another browser, or even without opening another window!

I repeat: don't give me a new, simplistic, browser, just make konqueror better!

gerlos wrote:I repeat: don't give me a new, simplistic, browser, just make konqueror better!

I completely agree with this, we just need to make konqueror more usable, fast and efficient of web 2.0 sites.

I don't think not functioning of web 2.0 sites is not a khtml or konqueror fault it is the fault of the big names (like google, yahoo ) who intentionally make them don't work. other wise heavy and complex web 2.0 site like zoho office wouldn't work on konqueror. Though i still agree that there is many small issues that needs to be fixed in khtml and konqueror, it is a great browser.....which is memory efficient,fast compared to firefox...

It does frustrate me that websites think a browser isn't W3 standards compliant, just because they don't recognize it. If the website's W3 standards compliant, then they shouldn't have to worry about whether a browser supports it or not: that's the user's responsibility.

Of course, anyone using IE would be left in the dust, but I'll be damned if they don't deserve it.

I'm also hoping of a stable webkit browser, ideally konqueror or arora...
Kde devs may have khtml over control, and can change it as they wan't, but I'm using it almost 6 years, and it is still not compatible with a lot of websites, and still slowe !! (even if on website you always can read that it is always more compatible...)
I think Kde can't afford to wait 5 years more until they have a good browser... I'm already often installing gnome by friends, even if I prefer kde, because I know konqueror is unusable for a lambda user, that won't understand why pages are making problems, and I know it is pretty difficult for a user to understand why firefox under kde is bringing a gnome file picker where all his shortcuts are missing...

I think it is difficult enough to bring web developper care about firefox, ie, and safari... it is not possible to bring them take care for khtml only for linux user that are using kde !! (how many % is that ?)

For me the only realistic way is to use a backend used by other browser : webkit or gecko.
If konqueror is not going quickly that way, it will be too late...

Who want's really khtml ? I think only kde devs...