Sunday, April 26, 2009

Why isn't there a problem to be Konquered

Recently there's been a couple of posts by Kyle Cunningham suggesting, for the n-th time, that KHTML should be dropped.
That seems to be a recurring topic in the planet, and already some answers have appeared to the most recently discussion, both of which shows that people is tired of that topic, of course by people I mean, in this case, Benoit Jacob the writer of both posts and also those who have answered the very same question in the past. Of course I must disagree with him in one central point: every opinion should be heard and as such no policies should be applied to the PlanetKde.
So in my opinion, why isn't there a problem to be konquered? well simply because Konqueror, and KHTML by extent, is being maintained. So?, that's it?, yes, basically. We can elaborate it more: Konqueror and KHTML offer the integration with KDE that Webkit lacks, and, if we can believe the opinion of a KHTML developer whom I discussed during the last akademy, actually has a cleaner codebase.
I'm not saying that the points raised by Kyle Cunningham aren't valid, but they've been answered over and over in the past. And, to be honest, this is Open Source Software after all, not because someone decide to let die a project it will actually die. In the end, those who code have the last word, and are those who decide whether to continue or drop the towel. Right now the KHTML developers have decided to continue, and actually I'm trying to join them, but I should tell you in a later post; so please stop trying to hurt the community. Either that or work in your own alternative, if such a project is proven to be more viable, then the community will stand by it. Yes, in that aspect I agree with Benoit Jacob.
So I'm left with nothing more to say other than: please stop trying to kill good, and mantained, projects.


Tom said...

KHTML might be a lot of things (well integrated, have a clean codebase)

_But it isn't good_ as a browser for normal people.

KHTML is buggy and lacks so many features it isn't funny.

It just does not work with modern websites and I don't think it ever will.

And it is holding KDE back, because for every normal user a pure KDE desktop is broken with so many important websites not working properly.

Why can't the KDE project see that? You should try to offer your users a useful modern desktop. Reallocating developers to archive that goal would be a wise thing. (As in keep KHTML, but make WebKit the default rendering engine for Konqi. Even if that means loosing a bit of integration. That integration is worthless if you e.g. cannot use your Netvibes, Digg, Google start page etc.)

Zayed said...

@Tom: to make tall story short: who is coding, he will rule. There is no developers work in webkitpart. DO NOT ASK KHTML DEVELOPERS TO DEVELOP WEBKITPART TILL YOU PAY THEM.

Tom said...

@Zayed: No need to yell. And I didn't ask the KHTML devs. I stopped asking them to fix the rendering bugs I filed a long time ago. And I sure as hell won't pay those jealous stubborn kids.

Tim N said...

> so please stop trying to hurt the community.

If they stop that will you stop beating your wife?

ZeD said...


Reallocating developers to archive that goal would be a wise thing.are you joking, right?

If you really want a better "browser for normal people." just WRITE it.
You cannot "reallocate" volunters work.

Tom said...

From the KDE website:
"The KDE project aims to change all that. KDE now provides an easy to use contemporary desktop environment available for UNIX and compatible systems. "

So if fixing a major bug like a totally broken browser is not possible then KDE has failed.

People can't even read their emails out of the box with KHTML.

Porcel said...

Why not do the opposite?

Ship a working browser for every day use and keep khtml around for kdelibs and then if khtml proves itself to be superior to webkit at some point in the future, it would be easier to switch back to it.

But right now, the first thing every single kde user does after a new installation is install firefox. And I have feeling that once chromium is released that too will see higher use than Konqueror. The web has changed and konqueror hasn't kept up.

You can continue living in la-la land or you can begin dealing with reality, but right now maintaining konqueror as the default browser is hurting KDE

Anonymous said...

+1 on Konqueror is hurting KDE.

I love Konqueror as a browser but using KHTML for the rendering makes it unusable for anyone who has to use JS-heavy site. I hate using Firefox and I miss Konqueror but until it works out the box with GMail I won't use it again.

Feel free to bury your head in the sand and pretend that the web developers will start testing with KHTML or KHTML will have less bugs than Webkit. Until either of them happen (which neither will) then KDE is going to have a bad browser and KDE-orientated distributions are going to look poor and less people are going to use KDE and instead use GNOME.

John van Spaandonk said...

I'm a strong believer in evolution by natural selection on organisms.
Konqueror might contain good genes (codebase, ideas, ...) but it will be selected (I think: rejected) by its
users on the basis of how it performs. And its performance is not good. So ultimately it will die, because I think a handfull of part-time people cannot keep up with the multitude of people working on netscape, webkit, .... A
nd if the kde developers are stubborn enough to push a not correctly working webbrowser as essential part of KDE, users will associate it with KDE (like my wife is starting to do) and then that will die too. It's as simple as that...
Currently if I want to have an good working _and_ integrated browser, I am forced to use KDE but use Gnome or Apple computers.

Users do not base their judgment on arbitrary measures of goodness like gene (clean code) but on how those elements come together in an application.

John van Spaandonk

Iuri Fiedoruk said...

Just because developers still work on it, and like code it, does mean that USERS must suffer from using an inferior tool?
You know, I can get the netscape4 code and developt it, this does not mean that people should have to use it as default instead of firefox ;)

If you assert that KDE is meant for developers to use, it is ok, but last time I checked it was for users.

derdestiller said...

I really think that KHTML is a long grown codebase and shouldn't be pushed away just like that. In fact, i am using it for my everyday browsing (also on facebook and other heavy js-sites).
I boosted networking speed by using the Polipo Proxy which supports http pipeling.
Despite some few Bugs here and there, i have to say that i don't see a big difference compared to Firefox 3.0. And beeing maintained by a couple of skilled people who improve on those bugs and performance i (as a user) really think KHTML should be kept... in fact KHTML-Code has seen more browser engines and companies rise and fall, than almost any other modern browser today.

seanlilmateus said...

I real love the community Ideology, but in discussion like this I real miss some professionalism; The Konq+KHTML developers don't act with the brain but with the Hearth! they love what they do.
It's not about KHTML been better than Webkit; it's all about the Developer hearth!

we can not obligate any one to develop something they don't want! so we (User only, not Developer) must accept it or switch to something else.


dada said...

I have to disagree with you. I can`t wait for a native KDE 4 Webkit Browser. In the time of Web 2.0 the most used program is the browser. There are even some plans for a future without a normal desktop and just with a web interface. With Khmtl KDE will never take part in the progresses of the coming time.

Webkit is developed by a lot of people in a full time job. Khtml will never catch up with Webkit.

maninalift said...

Making no judgement as to the value of KHTML and Konqueror you must admit there *is* a percieved problem.

Many users who would prefer a more integrated (into KDE) browser still feel happier using firefox.

The argument should not be whether KHTML is *good enough*, that can be batted backwards and forward endlessly to no gain. The real questions are:

(1) what are the perceived problems atm
(2) what are the reasons for those
(3) what are the possible solutions
(4) what resources are available to us
(5) what is the best way to proceed given 1-5

Apart from (1) these questions are primarily for (a) the developers who would be directly involved in any change in strategy and (b) the people who are involved in the overall architecture of KDE.

Stormy said...

I will support KDE Dev's response on taking up webkit. Yes, KHTML do have bugs, but so does gecko and webkit. I dont see all the sites working in arora as well with all the browser specific code. The choice is given to the user with qtwebkit package. You can try that with konqueror to see what state it is in.. ;) Most of the problem that konqueror faces are because of the browser specific code, which will not solved even if webkit is good to use and integrated with konqueror. But from what I had seen from 3.5.X to 4.2.2 is a vast improvement/bugfixes on konqueror/KHTML and its only going to improve. Lets be patient guys!! For me it works for mail/RSS reader/quick browsing. Only thing firefox lacks for me is krunner integration. I dont need a monster for mail/RSS rendering.. ;)

Carlos Licea said...

@Tom, we cannot realocate anyone, you know, this is open source. Also I keep hearing "Konqueror is a completely flawed browser", but honestly, I use it every day. Yes I keep firefox just in case, yes there are sites which can't be visited with Konqueror, but honestly, they are not as many as you claim.
@Zayed, I agree but there's no need to yell =).
@Porcel, ok, when someone steps up and code the Webkit KPart needed we can discuss whether to integrate it by default or not.
@Mike Arthur, really? is there such a problem with JS?, honestly I don't have that many problems, I conced that it might be that I just don't use sites with "enough" JS. And about "then KDE is going to have a bad browser and KDE-orientated distributions are going to look poor and less people are going to use KDE and instead use GNOME.", do you really choose your distribution, and your Envyroment (KDE, GNOME, XFC...) by extend, based on just one program?.
@John van Spaandok, if a user can associate a program's behavior with a whole desktop is not really a problem of KDE. That being said, why not just using firefox and live with its bugs instead of KHTML's ;).
@Iuri Fiedoruk, USERS must not suffer anything, USERS are free to choose another browser.
@derdestiller, I must totally agree, as I said I keep Firefox around just in case, but I do use Konqueror for my 99% browsering.
@dada, "With Khmtl KDE will never take part in the progresses of the coming time.", why not?, KHTML is growing, every few days there's a commit implementing something new, the problem, in the majoriy of the cases, is that we aren't bug compatible ;).
@maninalift,yes, I admit there's a percieved problem, but, is it really solved by pushing Webkit?, if so, why isn't anyone of those who want it doing it?, why, for exmple, Arora still has just a few developers (1 IIRC) and users instead of just everyone making the jump.
@Stormy, moustly my opinion too, what really hurts the interoperativility is the poorly implemented standars and coding using the bugs.

maninalift said...

@Carlos Licea "I admit there's a percieved problem, but, is it really solved by pushing Webkit" I don't know, which is why there is a need to clearly lay out the apparent problems and the possible solutions.

@Carlos Licea "if so, why isn't anyone of those who want it doing it?, why, for exmple, Arora still has just a few developers"
If there were were a strong community project to create a webkit-kde browser out there now there would be no need to make any sort of a plan, one could just let "market forces" sort it out. Arora, rekonq and foxkit are all "pet projects" at the moment but if a consensus was reached that if say rekonq acheives X, Y & Z in 6 months time then it should become the default KDE browser then I'm sure more people would be motivated to contribute. On the other hand, the consensus might be konqueror just needs to fix A, B and C, the rest is marketing.

...of course that assumes that the problems can be clearly defined and a consensus reached... but I think a proper debate is valuable whatever the outcome.

bryce said...

If KDE people can't reallocate resources(if that's the only way to push webkit to KDE), then KDE will drown slowly until it hits the bottom of the ocean. By then, where would you use KHTML for? Port it to Windowsville? It's as simple as that... I'd rather take webkit and survive. :)

Vladislav said...

Thanks for the clear post Carlos. I am a long standing KDE user and agree with you.

Whoever hacks --> creates.

Tom said...

Well, maybe the problem is that the KDE developers frequent very different sites than the general public.
Most people use webmail and are acustomed to the JS heavy version of those sites. Yahoo mail, Gmail etc DO NOT WORK out of the box with KHTML. People have netvibes etc. start pages. Not working with KHTML. People work on Calendar, Spreadsheets in the browser. Not working with KHTML. People watch lots of videos on youtube. Crashes KHTML 99% of the time if you open lots of videos.

Simple test: Give a casual Windows websurfer KHTML and see what happens. They will tell you it is broken. _And it is_!

But you guys are hopeless, it does not matter if webkit, trident and gecko support bugs or not. They fucking work with 99.999% of the sites people use.
KHTML works with maybe 80% (guesstamate) of the sites people use.
Bottom line: Web devs don't care for KHTML and tbh why should they? Just adopt a working rendering engine or become obsolete.
That is all I will say about it. You guys are living in Lalaland.
Over and out.

Iuri Fiedoruk said...

All this discussion remembers me of the 4.0 problem. users told developers: "do not use 4.0, use 3.8, 3.9 or test-version 4 instead". Developers did not cared at the time, and the ending result was very ugly.

Now users are telling the developers that KHTML isn't good enought anymore, and they want a first class browser in KDE - because most simply use Firefox already - and KDE developers are making deaf ears again.

All in all, KDE is loosing market, and I'm looking forward the gtk based google chrome. Sad history, I'm already hoping for a good gnome/gtk 3.0 to drop KDE as things are turning users agains developers :-(

k said...

Why don't merge KHTML and QWebKit? I think it could be interesting solution for KDE and QtSoftware.
I don't thing that compatibility with Aple is now priority for Nokia.
I don't know how many differences are made after fork, but I think both shod be still similar.
I mean that Qt could have independent web engine, and kde's engine could it inherit.
What do you think about it.

Sunil K said...

Konqueror is steadily improving over time. There's a big difference between 3.5.10 and 4.2.0. I'm glad I find myself using Firefox less and less each update. I'm hoping that they can improve at a faster pace though, especially with javascript. I wish I could use Gmail, jquery or the new yahoo mail soon.

test said...

funny to see than people think webkit is the solution.... when there are a lot of problem with it to navigate on the web...

if you're not happy use something else.. or code

Iuri Fiedoruk said...

I have MUCH less problems with arora then with konqeror.

And, yes, we do use something else, or in some cases code as the reqonk author is doing. But it is a lame for the projet to use something inferior just "because" (sorry, till now no good reason from a user perspective was given other than devs like khtml)

Anonymous said...

@k: Agree, and some progress has been made on this (one of the reasons KHTML is, to quote Sunil K, improving immensely over time). This is IMHO probably the one and only true answer: fix KHTML.

I have worked on WebKitPart, however more manpower would definitely be appreciated. A reasonable large amount of bugs exist in QtWebKit, almost approaching
the supposedly buggy KHTML :). For example, text-shadow does not work; try it if you don't believe me.