Rhaaa again this discussion show up.
I liked konqueror in KDE3 when it was just working both as web browser and file manager. In KDE4 i used dolphin because i find the UI very powerful but i never used Konqueror. The reason is (at least the last time i checked) that it doesn’t support properly gmail, doesn’t work that well with youtube (sometimes the flash plugin is not loaded), a LOT of AJAX website are borked, not rendered properly. Of course i don’t speak about official website from governments that are working/rendered properly in Arora/Firefox but not in Konqueror. This is a show stopper for Mr EVERYBODY and this is the kind of users we are targeting (not advanced users with crazy workflow using features that almost nobody uses). And yes Mr EVERYBODY sometimes use proprietary thingy, that is the way it is. I think giving away some features for a time and make 90% of people happy is a good deal.
Me as an OSS user i don’t like Firefox because it is lacking with KDE integration but i prefer to use it than tweaking KHTML with identities or to avoid having a poor surfing experience. The bad thing as well is that Kubuntu ship konqueror as default, Firefox is not installed unless you go to the package manager. What a poor experience for user when he start browsing for the first time.
I think pretty much everybody agree that we still want Konqueror but with a different engine that just works with very active maintainers. I really appreciate the work that has been done in KHTML in the past but now it’s time to focus elsewhere.
I also hear devs : “gna gna Qt Webkit lacking this and this” but i have to say :
This link can improve Qt/Webkit
I am sure that the webkit team in Oslo will be happy to review patches as well as APIs to access what is missing. (Btw Qt Webkit in 4.6 come with a full DOM API). I am also pretty sure that a KHTML developer will find quickly his way to webkit in order to help in that area. Working together seems to be a good option i have to say.
That’s all for me, i just wanted to remember the Qt open repository to make what is missing happen in order to deprecate KHTML and to stop wasting resources on a double work. Man we don’t have two times our spare time.
DarKtears 
June 30, 2009 at 9:06 pm
You cannot reason with the current KHTML devs. Reason does not work. KHTML works for the websites they use so it must be fine.
You will need to find other devs to do the QtWebkit work, but devs are hard to come by.
So … no solution in sight. Be ready for this discussion to be repeated in 5 months.
June 30, 2009 at 9:15 pm
@Tim
They would be much more collaborative, IMO, if people stopped saying “KHTML sucks, go for WebKit” instead of:
– helping KHTML get better
– helping WebKit get better
It’s that simple.
July 1, 2009 at 4:48 pm
Well said!
June 30, 2009 at 9:16 pm
You are right!
June 30, 2009 at 9:37 pm
I’m a basic KDE user.
And I can’t reasonnably use konqueror as a web browser too. That’s a shame.
What the KHTML guys have to understand is that the basic user doesn’t care at all about developpers’ fun.
Anyway, who uses konqeror nowadays? Nobody, because of… KHTML. KHTML devs are actually developping a tool nobody’s using but them.
That’s just ridiculous.
June 30, 2009 at 9:39 pm
I don’t understand the KHTML devs either.
I mean we have widely used, well supported engine (Webkit) which is used and developed by at least two big companies. Why shouldn’t KDE try to benefit from their development?
KHTML will fall further behind because the few KHTML devs are not able to keep up because of lacking manpower.
I understand that KHTML is their baby and that the people who write the code decide which direction will be choosen, but it really doesn’t make sense anymore (?) and it hurts the KDE platform as a whole.
Maybe some leading KHTML devs could try to explain their actions so that we all could understand the reasoning behind it…
I’m going the check my emails at GMail now.
Oh no, I have to stard Firefox to do this! (This sucks!)
June 30, 2009 at 9:53 pm
Just use the html interface to gmail. (I know people using Firefox on Windows prefering it due to speed.)
Last time I tried the AJAX interface worked in konqueror when changing the user agent.
June 30, 2009 at 10:21 pm
So we want to stick our heads in sand and not recognize the problem..Why user should have to do a hack to perform simple task like viewing a webpage..
July 1, 2009 at 5:36 am
psst. kmail can use gmail.
…it’s not exactly stable, but it’s close enough for me. except that google won’t let me report spam from there.
June 30, 2009 at 9:43 pm
Of course the KHTML people have a good point too, in that no-one has so far stepped up to replace it, but I think the first step is for KDE to agree that KHTML is a dead end, and the focus should be to figure out how to replace it.
I think the past 2 years have proven that keeping up with the modern web is just too much for the KHTML team. No slight against them, they are all far superior developers to me, but that is the situation and all indications are that it will only get worse in the future.
KHTML does not work for the average user, since very many popular sites are broken. This is not debatable, and whether it still works for some people is not relevant to the discussion when it is proven not to work on the popular, modern sites.
So lets not pretend that KHTML is even still an option. It is not, and it is very unlikely that will change anytime soon (and definitely not without a big new influx of full time developers).
Of course this doesn’t solve the problem of getting more devs to work on Webkit or FF integration, but the first step is consensus on what the course of action should be. Once that consensus is reached, then at least people will be clear on where KDE is trying to go in the browser arena, and it might encourage new developers. It would also discourage wasted effort, for example, why is there a GSOC project to backport SVG to KHTML? To get KHTML up to speed would require 50 gsoc projects, which isn’t going to happen, so lets not make a half-effort down that road with resources that could be “spent” elsewhere (GSOC being one of the rare cases in OSS when you can actually allocate resources to a certain extent).
June 30, 2009 at 10:04 pm
You’ve made a very good point there. I was just on writing about the same text as you did.
And I can second that the KHTML developers have done a great job for a really long time, but it’s nowdays hard to catch up with the more superiour and very actively developed web engines which exist in the world.
That shall not be an offense against the KHTML developers, but they don’t have as many resources. Even being really good developers, which they are without a doubt, it’s as it seems not really possible to catch up.
Of course, they can proove me wrong, and if it happens, and KHTML works with just everything (standard compilant), I’ll be happy as well.
June 30, 2009 at 10:10 pm
+1
June 30, 2009 at 9:52 pm
I do not have anything extra to say other then what people have already said..
Count this comment as +1 for webkit…
for god’s sake atleast make gmail work correctly
June 30, 2009 at 9:54 pm
Webkit is KDE technology! So everyone just embrace it and be f***ing proud of it!
June 30, 2009 at 10:05 pm
Please, stop this. This has been beaten past death. There are no new points being made here that hasn’t already made a million times over.
We all get that people want a webkit part for konqueror. Those that have the motivation to do so will work on it. The khtml devs have demonstrably never prevented, are not preventing, and will not prevent anyone from working on that webkit part. The facts are simple: The existing KHTML devs are directing their free time where they are motivated and interested: in KHTML. Whatever the demand is for the webkit integration into konqueror, not enough talented people are motivated or interested in stepping up to work on it.
So here’s the bottom line: For those of you who have some programming skills who would like webkit integration for konqueror and have the time and motivation to work on it, as has always been the case with open source, please please please feel free to “scratch your itch” by working on the current webkit part or creating a new one. Till then, I’m eternally grateful that the KHTML developers continue working on KHTML. Without their efforts the situation would be much worse: KHTML without the many bugfixes and improvements they have made AND no Webkit integration because no one else has stepped up to work on it.
As an aside, it is depressing to see this kind of non-development rants clutter up planetkde.
June 30, 2009 at 10:16 pm
This has been repeated and has become established now – USERS OF A OSS PROJECT ARE NO LONGER DEVELOPERS THEMSELVES(UNLIKE IN 90s)..
Unless KDE wants to a project that only developers use, konqueror/kde bigwigs have to heed to the user’s rants..
June 30, 2009 at 10:35 pm
That does not change the fact that OSS projects are developed by DEVELOPERS. Those DEVLOPERS work primarily in their free time on what interests them. If there are no developers that are motivated to work based on user rants (no surprise) then, guess what, the reasons for ranting won’t addressed. Like it or not, THAT is the harsh reality of open source.
If the users do not have the skills to scratch your own itch then all you’ve got to rely on is your capacity to convince people to work on your behalf. Good luck getting that with incessant, obnoxious, repetative ranting…
June 30, 2009 at 11:17 pm
Of course an open source project primarily depends on developers but it also needs USER.
Why would someone write software if nobody is using it.
Please don’t misunderstand me, I appreciate the work of the KHTML devs but the harsh reality
is that KHTML is inadequate for a lots of new Web 2.0 pages, so the user are asking why the KDE project isn’t using an existing and working solution like Webkit.
I’m not a developer and I can’t write code but I’m trying to support the KDE project, too (making donations, filling bugreports, promoting the project), so I think that the people who do this “small” things should be also listened to.
And the KHTML project has reached the point where it really doesn’t make sense to put ressources into it, when there is a better solution.
July 1, 2009 at 5:32 am
What solution? Tell me where there is a better working solution for konqueror and I’ll use it. Again, the fact is that there is no satisfactorily working webkit solution for KDE. We could have 6 billion users clamoring for it with pitch forks, it makes no difference if not a single one of them is either willing or able to step up and do the work to get a satisfactorily working KDE webkit solution. Till then, I invite you and others to stop demanding that KHTML developers stop doing what they enjoy doing.
Oh and in case some people don’t understand, there are no KDE “bigwigs” deciding where “resources” should go. It is open source. People work on what they’re interested, or otherwise motivated, to work on. Make the effort to absorb that simple fact. Until you and everyone else does, you’re invited to continue making bug reports, help with bug triaging, help fix KHTML bugs or help develop the webkit part or an alternative webkit browser. Any or all of these activities are welcome and appreciated by developers and users alike. If those don’t suit you or other then please, shut… up… and move on…
Good grief, if you selfish, short-sighted grumps cost me, another user, the valuable work the KHTML devs are doing by driving them away with this incessant nonsense and leave me and other users with an unmaintained KHTML AND no satisfactorily working webkit solution…. grrrrrrr…
June 30, 2009 at 10:19 pm
I don’t see what the problem is with using Firefox, the only real integration problem is the attrocious file picker but everything else seems to work very well.
June 30, 2009 at 10:46 pm
kwallet
June 30, 2009 at 11:38 pm
Firefox ist not
– use the same bookmarks as KDE
– does not allow to subscribe Feeds in Akregator
– does not share proxy settings
– does not use the same cookie-settings as KDE
– can not use KGET directly
– …
Is think there are a lot if reasons for having a real Konqeror
June 30, 2009 at 10:22 pm
“Btw Qt Webkit in 4.6 come with a full DOM API”
Ok, that’s one big thing off my list of things that Webkit apparently lacks compared to KHTML.
July 1, 2009 at 8:19 am
NOTE: It does not expose the standard W3C DOM, but is probably good enough that most of the things you do with that can be done with Qt’s one.
See e.g.
http://chaos.troll.no/~tavestbo/webkit/domapi/qwebelement.html
June 30, 2009 at 10:25 pm
Why do i like Konq:
because it is well integrated with KDE, and particularly because it is well integrated with akregator.
Why don’t i like Konq:
because it isn’t a very good web browser when using khtml
keep konq, and use whatever rendering engine has the most developer input.
June 30, 2009 at 10:36 pm
Hi,
Just a question: What will we do when we found a problem with webkit ? We wait next qt release ?
We can backport fix to kde4.x and release it.
But we can’t release a new Qt when we need it.
Ok we can add patch in qt-copy (or qt-kde.git) but all distro doesn’t use qt-copy.
Ok KHTML is not perfect but we (kde guy) knows it and we can fix it.
And perhaps Qt doesn’t have same priority for html bugs as KDE and it’s a problem and we can’t force Nokia to fix them if you don’t want…
For me we must continue to maintain it. And we can’t remove it before kde5
June 30, 2009 at 11:13 pm
Hi laurent,
This is another issue, we can also backport patches to a patch release of Qt also and have a special security release. What about phonon? Another alternative will be a remote to webkit with a git repo shared with Qt Software (require git for KDE).
But laurent isn’t it the same for any class in Qt, like QWidget? What happen if you find a big bug? You can’t also release Qt when you want even with the fix…For me here this is not a problem, Qt Webkit modules are like other classes in Qt nothing more.
The problem here is that there is almost nobody to fix it. Bugs are there and stay there.
But you can still ask for merge request for any bug fix you do in webkit/qt and it will be probably integrated way faster. We are paid for that.
Of course we keep it until kde5 but i was talking about deprecation.
June 30, 2009 at 10:48 pm
You miss two things:
* Contributing to QtWebkit requires you giving your copyright to Nokia, not all of us like to work for free for big corporations
* Time has shown nobody wants to work on a webkit kpart, so unless you do it your words just create noise
June 30, 2009 at 11:02 pm
*Qt is a GPL/LGPL no? So it means a free software no? Have you sent any patch to Qt before Nokia? It was even worst when it was Trolltech, a small company.
*You create noise! If we don’t have a SOC, a sponsored code camp (by perhaps Qt Software) and people like you, yes it won’t help.
June 30, 2009 at 11:04 pm
@Contributing to QtWebkit requires you giving your copyright to Nokia, not all of us like to work for free for big corporations
Hmm… so utilizing QT in KDE is okay… but dont contribute back since it belongs to Nokia now..
Also, developers didnt think about this earlier when Apple took khtml and improved it in webkit earlier..
I do not think your first point is the main reason preventing webkit in konq..
@Time has shown nobody wants to work on a webkit kpart, so unless you do it your words just create noise
This could be a issue though..
June 30, 2009 at 11:05 pm
Webkit is under LGPL:
July 1, 2009 at 1:07 am
Are you lying on purpose or are you just misinformed? The Qt port of WebKit is hosted under webkit.org and no one ever had to assign copyright to anybody: http://trac.webkit.org/browser/trunk/WebKit/qt
July 1, 2009 at 3:33 am
“* Contributing to QtWebkit requires you giving your copyright to Nokia, not all of us like to work for free for big corporations”
This is false and incorrect. QtWebkit does NOT require giving your copyright to Nokia. QtWebkit is developed in the WebKit svn repository and is under the LGPL and anyone can submit patches to it under their own copyright.
July 1, 2009 at 1:44 am
I don’t know why this thing keep popping up in planet KDE, but the real problem is the Webkit KPart is not in a very good shape, and don’t expect KHTML developers to fix it, because they’re just simply not interested (well, I’m not interested as well).
What I suggest is people who always whine about Webkit integration in KDE just lend their hand and help KDE to improve it. Whining will not solve any problem. Period
July 1, 2009 at 7:42 am
It’s not a Webkit KPart issue, read Leo S comment up above.
The problem is finding consensus on what the course of action will be. If this is the time in which we’ll choose Webkit as the default rendering engine, the Webkit KPart will be fixed in weeks.
July 1, 2009 at 8:23 am
“It’s not a Webkit KPart issue, read Leo S comment up above.”
Yes it is, and I don’t see how Leo S’s comment states otherwise.
“If this is the time in which we’ll choose Webkit as the default rendering engine, the Webkit KPart will be fixed in weeks.”
Do you have any evidence at all for this assertion? I doubt that would-be Webkit KPart people are put off of working on it by the fact that it is not the default yet. In fact, they’d either a) not care since the default can be changed so incredibly easily or b) work harder on it so that it can feasibly be *made* the default.
July 1, 2009 at 4:38 am
Sad things are happening. One day kde was really innovative, with their own great things like arts. They are all gone, replaced with just-another-wrappers. Today everyone wants to throw away great html engine en exchange for some shiny thingie. Sad, sad.
July 1, 2009 at 6:38 am
Users want their software to work.
That’s so unfair. 😥
July 1, 2009 at 7:45 am
If it was the greatest html engine, people will use it. Unfortunately it’s behind the competition, and KDE must offer something ‘better’ to its userbase.
July 1, 2009 at 6:01 am
I think webkit is good and nice, but NOT good for konqueror… Konqueror should still use KHTML as that is its engine.. You dont hear people saying Mozilla should use webkit instead of gecko do you?? NO!!
But what I do think is that konqueror needs a tiny bit more innovation, I am not saying konqueror sucks… but it needs more pluggable gagets, or it needs to invent somthing complet new that could lead to new directions in the www! right now there is no lack of browsers for Linux like in the past, instead we have a few and they are all doing new things.. while konqueror is just not conquering!!
July 1, 2009 at 8:19 am
Yeah, let’s change the web with a browser that nobody uses!
July 1, 2009 at 6:45 am
I try each KDE release to switch from Firefox to Konqueror… sadly i must switch back. Like it or not this is a fact. Shoud we take this into account or not?
I don’t know if QTWebKit is the solution, I’m not a we tech expert but, as of now, things are not working and KDE as a project should plan something to address this issue.
July 1, 2009 at 8:27 am
Imho:
Keep Konqueror, but make it use webkitkde.
Konqueror is not the “problem” (if I can say so), but khtml is…
By using webkitkde, KDE would use webkit, and the load of developing a html/js/css engine would be completely offloaded.
Just make sure the webkitkde part rocks. Sounds easy compared to make khtml the same than webkit or gecko.
July 1, 2009 at 10:17 am
I really do not understand the logic of beat khtml and very thing will go smooth !
First of all, there is WebKit Kpart and I can activate it in three click. But it is not stable and have a lot of bugs and missing a lot of features. It is not ready yet.
Second, Khtml developers are not your enemy. They are cool hackers who work in their fun project in their free time. The give KDE a good html engine when webkit was not ready. They definitely will help any one ask for help. Trust me they are cool. Please give theme some respect.
Third, please consider follow your talk with action and start hacking in webkit kde Part.
July 1, 2009 at 10:45 am
I too believe it’s a good thing to bring this discussion up again. Lack of resources is a commen problem not only within the greater KDE sphere, but in all open source, and if we hadn’t had KHTML, the need for a fully functional WebKit would have forced a solution long time ago.
Also – just look at the momentum webkit is gaining from this speed-test related to Firefox 3.5 where the webkit browsers really pull away from the pack:
http://blogs.zdnet.com/hardware/?p=4833
I’m no coder at all, but will happily invest time and effort in troubleshooting and contributing any way I can to have a WebKit-based Konqueror in KDE !!
July 1, 2009 at 12:18 pm
stop saying :
– you are bad guys, you piss on khtml
– you must help khtml devs
– site are badly written
For seven years i use and prefer konqueror
but
– seven years javascript/flash pb
– seven years javascript kmplayer (using mplayer) problems
– today more an more page are loaded but not displayed
– everyday several time a day i use file/open with Firefox
– i sent bugs reports but today i am discouraged
it’s not a pb of task force but a policy problem, you must be compliant to the reality not only to the standards.
Others do that. why not konqueror ?
July 1, 2009 at 2:22 pm
I’m using Konqueror for years and I’m especially very happy with the new KDE4 Konqueror. It runs much faster now and I’m expiring much less problems with KHTML than one or two years ago.
+1 for KHTML in Konqueror!
July 1, 2009 at 4:47 pm
maybe web site don’t work well with konqueror… but this problem exist alswo for brownser who use webkit
July 2, 2009 at 2:16 pm
As KDE user for a long time I have to say that using Konqueror just doesn’t works for me. And if I say this and I’m a CS student, imagine “normal” people using it… it’s already hard to convince people that using and promoting OSS is good, so giving them a bad experience is definitely the killer argument. This is not a KHTML/Konqueror fault only, too many OSS is broken and this is hard for me to admit it but we must not plant our heads into the sand.
I think that both things must be done: FF should really get integrated, AT LEAST the application preferences for downloads; Arora, rekonq, wtv., should be integrated into KDE, the web moves too fast nowadays, new (complex) technology rising anytime, everywhere… this requires more and more manpower. That manpower exists on WebKit so we should use it? Is that hard to see that WebKit provides a better experience than KHTML? KHTML isn’t bad! WebKit is simply better.
July 2, 2009 at 3:39 pm
While KHTML does need more improvements, the allegations being made that it doesn’t work, is naive.
Konqueror (and KHTML) is working, and has worked, pretty good for my needs as a normal user.
Pingback: Top Posts « WordPress.com