making a point to mention those images to me. When I told a friend this he wrote, "I suspect the bike post appeals as something 'real' and 'fun' as opposed to the perfect-abs-boy-staged-photoshopped-picture that dominates gay media today". I quite agree with both that being the reason and the sentiment, and I hope we went for a way more natural feeling with this. Way, way more. I also think there's something universally appealing about riding a bike:
Assicurazione auto

I think KDE should have a completely new webbrower based on the WebKit engine.

Konqueror should remain an advanced file manager with window splitting, view profiles and such (very useful) possibilities.

For simple file management Dolphin is already out there.

Konqueror is the best browser when it comes to configurability, KDE integration and lightness, and it's very comfortable to be able to do file management with my web browser, I miss that very much if I work with any other system. Konqueror is one of the main reasons I use KDE, and also KHTML is a really good rendering engine.

It certainly lacks manpower, but it would be the worst decision possible to shift away resources from Konqueror and KHTML. Webkit is nice, but it would be a lot of effort to maintain a own branch of it, which would certainly be a must if KDE chose it as default, and be it only to be able to make improvements that get to the user *before* the next Qt release.

I know that a lot of people out there think that "konqueror sucks", but after many years using KDE, I still think that konqueror is a really great piece of software. I love the fact that it does a lot of things in an integrated way.
Actually, I use it to browse the web for most of my time, switching to firefox just for some websites that don't work with konqueror (they are really a small number, almost imho).
For me, konqueror is one of the main reasons to use KDE.

I understand also that maybe it could be a smart move to switch to a rendering engine that is more widely used (webkit?), so there will be more people looking at the code, but I think is pointless to put away all the application (that works quite well, at the moment) and work on something totally new.
I'm not sure I understand the technical differences between webkit and khtml, it would be sufficient for me that the pages were rendered correctly and without eating too much resources like firefox does.

So why don't let the people (and the developers) choose between the rendering engines for konqueror *without* changing the app? Maybe, after some time, we will see which engine performs the best, and move more resources to work on it. So, instead of "switching" konqueror from KHTML to Webkit, the smartest move could be integrate *also* Webkit in Konqueror.

My two cents.
gerlos

I strongly agree with your points in this post and i think they're very valid.

We have dolphin now and it does a great job. I think we already figured out that it's good to have integration by having common backend stuff, but use different specialized GUI's for the tasks we are trying to achieve.

I talked with a lot of web coders and we agreed that KHTML must be killed with fire. I'm really looking forward to Arora AND having it as a default webbrowser in KDE. Webkit FTW.

IMHO, KDE4 series is really dragged down by konqueror/KHTML and kopete (most kde users use firefox + pidgin, because they're more popular and more polished and usable)).
Also graphic artists still use gimp and inkscape in KDE... i'm really hoping at some point i'll actually be able to use krita/karbon but atm they are very alienating, because of the lack of polish and design usability as well as not stable enough.

Technology just gets deprecated, we need to know when to let go of some of the pieces and replace them with fitting ones in the bigger image of the puzzle.

GO KDE! Kudos to all the "K-Warriors" out there and KDE users!

While I agree with your general point that KHTML does not necessarily fit into a "big plan" for KDE, I want to point out two issues:

1. Really, the order in "The Way Forward" is wrong. For all successful open source projects, it goes "first develop a viable alternative, *then* deprecate the old stuff". You propose the other way round - with a bit of bad luck, that might leave us with a standstill on the one side (e.g. KHTML devs leaving for a lack of public recognition) while on the other side the kdewebkit is still not ready for widespread use.

So the first thing that needs to be done if you want to replace/deprecate KHTML is to 1. get kdewebkit on feature parity with KHTML in terms of KDE integration (obviously, rendering bugs are different for both so a switch without rendering regressions won't really happen), and 2. build a viable community around kdewebkit, taking care that it doesn't fall behind if new KDE changes require adaptions in kdewebkit.

Then, proceed with deprecating KHTML and all the other stuff. I consider these blog posts part of "build a community around kdewebkit" so no criticism about you blogging at this time, but do try to get some active movement behind kdewebkit development as otherwise it'll all have the same outcome as every "let's get rid of KHTML" discussion before - the KHTML people will just outcode kdewebkit because they actually take action nevermind the future outlook, or "futility" if you want, of their undertaking.

2. KHTML might have a large bug count, but seriously the KHTML crew is the most responsive and cooperative bunch of bug maintainers that you'll find all over KDE's bugzilla. You got a problem, and they'll actually take care of it. You just need to ensure that you can come up with a reproducible bug report. KHTML's number of bugs might be as large as it is because unlike with other KDE projects, bugzilla actually works for KHTML issues.

That said, I still have no idea how the KHTML devs plan to keep up with the developement speed of other browsing engines, ever. But anyways, they're committed to doing it, and even given the advantage of "outsourced" engine development, it'll still be a challenge to come up with a viable replacement to KHTML. And it should work just as well in Konqueror, even if developed mainly as part of another (new?) dedicated browser.

Also, with Dolphin taking on the dedicated file manager role, Konqueror is practically free to occupy the "browser" role. I don't see a pressing need for an even more dedicated browser, because that should be Konqueror's aim anyways.

Nice plan. Now we need developers to implement is :) ( the core problem for khtml and webkitpart)

GNOME has Epiphany using Webkit and it renders pages well... even better than firefox. This is how I like GNOME. They seem to be more aware of what is right for certain areas. They seem to have no ego. They just use what's best out there regardless of who gets dumped. Why can't KDE be like it? I have been trying hard lately to use KDE as my DE, but I just can't stand the looks of firefox in it. Sure Plasma, Oxygen, etc... look cool, but they're useless without a good Web Browser to compliment them. After all, all people do with their computers are mostly done through a web browser...

Sorry guys, but I'll be VERY straightforwand :

--- No user gives a flyin' shit about what backend we use. ---

Let's come back to reality : users just want to access all their websites with no trouble like in Safari/IE/Firefox. Gnome has Firefox, and we have nothing to counter-attack. How are we gonna improve KDE's market share when we can't even provide a browser that just works?

At first they will use Konq, but after realizing they have to use Firefox for many sites, they just move to the latter. That's what everyone I've installed Linux on their computers tell me.

Statistics recently posted on PlanetKDE show this pretty well -- KDE users tend to use Firefox more than any other browser. Personally I just can't stand Firefox as it has too many quirks in KDE, doesn't integrate into it AT ALL (not even after all those years !!!). Since Arora has been out there, I've been using it as a replacement and put the WebKit kpart in Konq as default. It's not perfect, but now my pages look like they do in all the other browsers and they work.

What we need now is to use what manpower we have to develop a cutting edge browser for KDE and forget all those painful KHTML years. KHTML simply doesn't have enough persons working on it to be considered a worthy alternative. WebKit will bring us multiplaform automatic compatibility. WebKit will bring us awesomely fast JavaScript. WebKit will bring is more CSS features. WebKit will bring us more stability (in the future).

Let's focus on usability and awesome features, not backend stuff nobody cares about.

Where would be a new web browser, which uses KDE technologies, different from Konqueror (using a WebKit KPart)? A web browser, in addition to HTTP, can browse FTP. If also SFTP etc., even better. Of course, in KDE, we'll use KIO, why not?

A good web browser can integrate a PDF viewer, media file viewer etc. Is there any point in not using KParts for those?

A web browser can also browse local files, typically displaying folders as webpage-like lists. Does it hurt if we have a fully functional file manager instead?

That is, even if we want just a web browser, we have no simpler and better option than rewriting Konqueror. By the way, it is said that the Konqueror codebase is pretty messy and that's why sometimes implementing simple features takes a long time, so rewriting Konqueror might be a good idea. (I mean the same way, using KIO and KParts.)

There have been all these calls to 'advance kdewebkit' etc etc but the only difference that seems to exist between it and KHTML is that there is healthy, active developer community around KHTML while the various webkit browsers appear to be small projects and the kdewebkit component is incomplete and ready for broad production use.

Perhaps the author along with the other like minded individuals should stop blogging about how other people's work should be deprecated etc and start producing a viable alternative. Show everyone something worth using as a replacement (and not just small browser projects like aurora, the html engine, the JS engine and most importantly the active, healthy developer community) and you might get more people to come around to your ideas. Anything else isn't worth much in scheme of things.

I think it is very arrogant to forget that some people actually LIKE konqueror!

And that for us, konqueror IS a reason to use KDE, for the love of god!

Let us not forget that ever since KDE 2.0, the idea was to have a unified experience - web, local files, FTP, network shares, embedded file viewers, etc. Maybe this idea is not fashionable anymore, but for me (and for a lot of people I think) it is actually a killer feature of this desktop.

Heck, that's the reason (some) people hate dolphin and use konqueror as default file manager!

Plus, let us not forget that Arora's stated goal is NOT to become a full-featured browser, rather to implement basic functionality only. Unfortunately konqueror's "web shortcuts" are... pretty basic to me, and only konqueror implements that.

Anyway, the simplest and fairest solution: implement a WebKit KPart and -why not- use it as default rendering engine in konqueror. People can choose then. Developers, too.

I won't post a comment as long as I originally wanted (when the Captcha didn't work). My opinion is partly expressed in your blog and partly in other comments already, namely that it makes sense to push forward the use of Webkit in KDE, but to also keep Konqueror as the default browser because many people just like that they can do web browsing, file management and document viewing in one application.

I would like to add another point though: IMHO, the number of open bug reports is not a very good measure of software quality. But if you point people to the number of open Konqueror bugs (2695 as I write this, many of which are not related to KHTML at all), you should also say that Webkit has 4849 (http://preview.tinyurl.com/dx7m8p, including UNCONFIRMED, excluding enhancements, just like the default Konqueror bug count). I do not think that these numbers tell us that Webkit as a rendering engine is worse than KHTML (I think the opposite is true), I just don't think it's fair to tell people "Look how many open bug reports Konqueror has, this is a serious issue" without saying that Webkit has even more.

Seriously, its not like someone is magically in charge of this sort of thing. People who do the work get to decide. People are working on khtml. I don't see them just magically changing their minds from a few ranted blog posts from someone no ones heard of.

If this comment seems harsh then perhaps a few less blog entries and few more mailing lists discussions would be in order.

I think your point is very clear and well thought. For me personally, the step towards Webkit will improve the experience of KDE as a complete DE quite a lot. But not being personal, dropping KHTML in favour of Webkit is (with the points you mentioned) imho the best thing for the value of KDE as a whole.

There's only one point you miss in your argument. The integration of Konqueror is loved by everyone (KHTML lovers and haters). The point of discussion is and has always be the render engine. The most issues with Konqueror are related to KHTML, so what's wrong with dropping KHTML and insert Webkit as the default / another render engine of Konqueror? KHTML can still be supported during the existence of KDE4, but there is an option in the preferences to use Webkit instead of KHTML.

This has several positive results in contradiction to the other suggestions:
1) The use of Webkit makes the behaviour of Konqueror more standards compliant
2) Not completely drop KHTML because of the current userbase of Konqueror and the dependency of KDE4
3) Still a good integrated webbrowser. Using Arora will gain performance with the better render engine, but loose the integration of KDE.
4) When KDE5 is coming, the KDE developers community can drop KHTML at all, because maintaining a render engine is not the primary task of a desktop environment.

Konqueror is a mature browser, so why do you want to drop it? Just make the option to switch to Webkit and this will make everyone happy. I am not a developer, so I don't know any difficulties with this issue. But I don't think it's a really hard job to get it fixed. And it will make an end to this very long disccusion.

" Konqueor [sic] is a bit of a strange beast. It's a web browser, file browser and a file manager. However, I can see no clear reason why these things should be brought together"
Neither could I but I'm very glad they are. What I'm saying is that I never considered it to be possible (WinXP; limitations are features ;-) ) until I worked with Konqueror and now I find it backwards if such basic functionality isn't in one app.

I don't (really) care about the rendering engine, I care more about the web being usable in a fairly safe and convenient way. To me, Konqueror is still preferred over another solution but I'd welcome improvements. Haven't tried Arora but if that is an independent browser without all the extra things Konqueror does aside of being a webbrowser, I wonder where the extra value is. Based on Webkit and Qt, naturally, and minimal by design but I see no reason to use it over Iceweasel/Firefox.

For me the Konqueror is a STRONG argument AGAINST Kde adoption.
"- Use KDE, oh god, it cannot even access my Gmail account"

The WebKit is the Way to go, the KHTML have to recognize that WebKit IS superior to it´s Father.
I not talking about talking to KHTML to stop doing it work, but to KDE shot shipping Konqueror.

WebKit is already shipped with Qt , so no Overhead is made to the tree, Arora is a >1000 Lines browser and as a Browser take Konqueror to dust.

I not againt kde, i´m an evangelist but i have to Spot the mistakes and the Konqueror is a big failure.

A few years ago there was a plugin to use gecko engine inside konqueror, I'd love to have a full (page based configurable) rendering engine switching capability in Konqi.

I really love the idea of being able to manage files/browse web/browse lan/read document etc in one application in different tabs and the way how all this is transparently integrated together in Konqueror. But I am not very pleased how konqueror behaves like a web browser (it can often crash or stop painting itself) - and even with all this problems I can't stop using it - this is how comfortable it is.

I see the following future, which would satisfy everybody and would perfectly fit in konqueror initial design.:

1. Aurora (or something like that - probably something more kde-integrated) would be standalone KDE browser - like Dolphin is now file manager.
2. Konqueror would be promoted not like a web browser, but like an all-in-one application which combines all KDE parts in one place - it would browse web with Aurora kpart, browse files with dolphin kpart etc. So this just would not be WEB-browser with file management functionality - this would be a combine with WEB browser kpart integrated among others.