The current Kubuntu-KDE-4 LiveCD ships a Konqueror version which uses WebKit as the main HTML engine for Konqueror.
The KDE 4 LiveCD page mentions the new feature:
This CD includes a preview of the Konqueror Webkit engine.
And indeed, if you use the LiveCD to run Konqueror you’ll pretty soon see the difference in the terminal output:
First of all this shows the power of KDE’s kpart technology: you can exchange vital technologies if you want as long as they are provided as a kpart. Second, it also shows the possibilities: while this version had serious problems during my short tests (I was not able to input anything in Google, for example) the WebKit engine is capable of displaying web pages inside of Konqueror. Of course more polishing is needed, but it works.
It is left open if that is just a technical preview or a statement for future development. I haven’t found any further announcement or notice. But in case a statement for future development this step is very brave: WebKit does not seem to be ready yet to be used as the main HTML engine in KDE. It looks like KDE 4.1 would be a better release to ship a KDE version where KHTML is fully replaced by WebKit, also since QtWebKit would be available at that point. Additionally it could also be better to first ship a stand alone browser first and check how the community adopts that move.
However, this step can also be understood as a signal towards the KDE developers: while the situation around KHTML and WebKit is still not cleared Kubuntu now takes a clear position close to WebKit. Since Kubuntu is indeed one of the main KDE distributions out there this is a strong signal – but also might fire up the flame wars again.
/home/liquidat 
I thought the main KHTML devs were violently opposed to using Webkit. I don’t agree, but I’m simply a grateful KDE user (who is stuck on Windows a lot). KDE moving to Webkit once Trolltech started work on a qt port just seems like a good progression. The secret fork was not a popular move by Apple, but since then with all the attention it has gotten by big companies Webkit has turned into a very good HTML renderer. It just seems like using it would benefit KDE.
Thanks for the information. We will now know not to accept any bug reports for konqueror from kubuntu users.
Skeith: please read:
http://blog.froglogic.com/2007/10/the-khtml-future-faq/
“Thanks for the information. We will now know not to accept any bug reports for konqueror from kubuntu users.”
SadEagle, I’m sorry but that’s just absurd. Kubuntu is not using WebKit in the shipped distribution so konqueror bugs on Kubuntu are still valid. Ignoring bug reports for your software just because the distribution shipped a technical preview of an alternative as an option on a Live-CD intended solely as a preview is ridiculous.
SadEagle,
answers like that do not help anybody or the situation like that. I use kubuntu and the current version of konqueror they use has khtml so any bug reports might still be useful. The other way to interpret your comment is that since kubuntu decide to take a chance and try something that you are against you will punish their users even if they use ´your´ product.
Well, you’re right in that my reaction is quite premature, tikal26. But if this sort of thing starts contributing a considerable amount of bug traffic, I think we’ll have no option but to put in some sort of automatic filtering.
I spend many hours a week reading bug reports (there is a reason I’ve closed more than 2000 of them, and touched many more). I think it’s reasonable for me to not have to deal with problems created by a 3rd party product. Doubly so at this point, since we have a release to get ready.
And yes, my patience has grown quite thin, since some people would rather ignore and bypass our long-term concerns than help to resolve them, and comment on the situation in ways which either willingly or unwillingly misleads our users.
I just committed a new patch that stops the KIO progress dialogs from appearing for every transfer in the loading of the page, making the KPart a lot more usable.
I find it confusing that KUbuntu integrates such things. Confusing for the KDE project in general (was it decided to get webkit replace KHTML?) and confusing for the user as the bug reports are very difficult to assign to KDE or KUbuntu (as for example the KControl from KUbuntu KDE 3).
Things should be clarified. What does “preview” mean in a statement such as “This CD includes a preview of the Konqueror Webkit engine.”?
KHTML is maintained and the last thing I’d want personally is another Kickoff-like or System Settings-like inclusion with tons of bugs and no real maintainer. Jumping on the New-and Hype wagon is maybe OK for distros but it’s not for KDE.
So I just wish KUbuntu states clearly this is in no way related to KDE and this is their choice to ship webkit in Konqueror.
well, one of the main problems of KHTML is kde 3.5 was lack of a good debugging solution, look at sadEagle website and see this new debugger.KHTML “__IS__” maintained and under heavy development, i dont understand why people just want it to be deprecated??
Go SadEagle and KHTML team, Youre doing a great job.
SadEagle,
If you going to reject any and all things related to webkit if they touch (apparently) your konqueror then just say so, then people can quit wasting their time and make a browser that is not your konqueror and call it whatever and let it use webkit so you can be happy that your konqueror doesn’t get tainted by webkit.
And last I checked konqueror is just a container for various functions so bugs in konqueror should have zip to do with web rendering but it’s nice to see some more of you fud that does nothing to help the situation out but I suppose that’s the whole point.
Go, WebKit, Go! It’s a great step that Kubuntu is going toward KDE – WebKit integration. KHTML really should be replaced by WebKit (despite of injured ego of some remaining KHTML developers – original KHTML develiopers are already in WebKit camp) and I hope that KDE 4.1 will include WebKit engine (as Aaron Seigo said, WebKit will be used by Plasma and it users should decide if they want WebKit or KHTML).
@otohperif and @mmmm and to all:
You should at least say “Thanks” to them who still maintain KHTML despite the fact that their work are hardly appreciated. IMHO without them Konqueror in KDE 4.0 would be a shame as it would be crashy as hell and also this would mean no stable rendering engine in place for KDE 4.0 since QtWebkit would only go to KDE 4.1.
As for 4.1, let both engines (KHTML and QtWebkit) are shipped with KDE and people decide.
I really understand SadEagle.
Lots of people from Free Community spent lots of evenings and nights to make damned good softwares and this is how they are rewarded.
I like KHTML and Konqueror is my main browser since years. It’s far faster from other popular browsers and more efficient… but the mood is Firefox (like ogg better than mp3 but not used, iPod dominating music players with a medium quality player, etc).
Thank you guys for you work! 😀
My other feeling is that Kubuntu’s weight is really TOO important.
[end of message auto-censored]
@annma: ok, so upstream developers, please take a definitive, common position on the distributions/upstream devs relationship. Very often devs answer with “ask your distribution” or “we create an environment where distros can personalize the software easily” (think of plasma). But also there are lots of devs answer just like yours… so please take a clear, definitive postion and publish an official statement.
My humble user opinion is that…it’s opensource, baby. If you don’t want distros changing your product, do not release under an OS license.
I like Konqueror very much as it is right now, thank you. A secondary renderer is OK, especially if that would make FF completely obsolete.
“Since Kubuntu is indeed one of the main KDE distributions” Is it? Sort of like there are lots of Fedora users with KDE too?
@vide: of course it’s open source and of course KUbuntu can use it. What I dislike is the announcement which I find misleading (the “preview”) and slightly pressuring for KDE (Kubuntu devels are also KDE devels). I would like it clear to the users that this is a distro choice and that it does not imply yet that KDE will follow this path and surely not for 4.0. That’s all. I am not qualified to decide anything on Konqueror as I never worked on that part of the code.
KUbuntu has already changed KDE a lot in the past and that’s fine with me. But my view here is biased because of the low quality of System Settings in KDE 4.0. I just would like that sort of move not repeated in the future.
SadEagle, the link you’ve given is also linked in a post which I linked as background information above.
However, you should *really* work on your PR: the FAQ is definitely not enough to answer all the user questions – especially after the WebKit team made a step towards the KHTML developers. The fact that there was no response at all can be easily interpreted in many ways which are all not good for the KHTML developers.
In the mentioned FAQ it is written “And we’ll keep the
discussion about cooperation going.” – but there is nothing visible about that, it looks like the strict opposite.
So Kubuntu is shipping a very buggy pre-alpha version of the WebKit KPart? Let them do it. There’s no way this is going to go into Fedora rawhide in this state.
Including an experimental package on an experimental and unsupported live CD is not a “clear position” for anything.
Great Article liquidat, thanks.
I think we should stop letting the developers throw mud and let them start working together on reasonable terms. And if they fail to integrate codebases the end result *will* be that the best one gets picked by the public.
So, the comments from sadeagle on this blog sadden me, I don’t see any efforts going into merging the two products that are aimed at the same market but are so similar that, really, there is no room for both of them in most distros. Naturally I can be wrong and khtml may live besides webkit where the user chooses which one works for him. But you really have to ask if thats the outcome you want to fight for.
Remind me, what comes after denial?
@annma: what’s wrong with system settings? the most broken parts are KCM modules which are using something like a 1024×768 or even bigger windows. System Settings (which IMO is ways better than the old KControl) is just little more than a shell around KCM modules.. it has it’s bugs/problem, sure; its aestethic could be improved, sure but really I don’t get your point.
Anyway, I was talking in a more general way, I do read very often statements like “this distro patches my software, it’s a piece of crap now” ( Kubuntu KPDF in KDE 3.5 for example, read TSDGeos blog) so I think that it’s something that KDE should face as a project, although I can understand that it’s a very complicated task.
@vide
Apart from the resizing problem (for which someone recently proposed a fully functional patch that is being discussed at the moment) one of the biggest problem right now is that a lot of kcm modules are simply missing in System Settings, probably due to the misguided notion to make it “easier”.
@erunno: name the modules please, I’m pretty sure most of them are almost useless for normal use, and for power users there’s always kcmshell.
Liquidat: You can’t really expect all comunications to be through public mailing lists. We haven’t responded to the new policies of Apple, because we are using all our spare time to prepare KHTML for KDE 4.0.
So ask yourself: Do you want a KDE 4.0 or do you want us drop everything in our hands and run to WebKit and leave Konqueror completely broken for the next 18 months?
To me this just shows once again that KParts are a perfect framework for pluggability, not just in Konqueror but throughout KDE.
I wish someone made a Gecko KPart so we can have three of them to choose from!
There is a Gecko KPart, but it’s horrendously broken and it’s probably bitrotted and no longer compiles. See http://blog.gwright.org.uk/articles/2004/12/12/howto-install-kmozilla
Jonathan, usually that wouldn’t be a clear position. But I always have the very strict position of some KHTML developers in my ears, and with these everything supporting WebKit seems like a clear position.
Carewolf, of course you shouldn’t discuss everything on public e-mail lists. That would be nuts. And most people do now that you are busy preparing the KDE 4.0 release.
And I never asked for dropping KHTML. I want to be clear on that: while I have my own position due to specific reasons I try to be as neutral as possible regarding the situation between WebKit and KHTML, and try to shed light on both positions – without statements like “drop this” or “drop that”.
Still, the PR of the KHTML team is horrible! That has nothing to do with code or actual actions you’ve taken, but just with the image of yourself you show to the users.
A simple “thanks for the move, we will consider this in the further discussions and debates regarding that issue” would have been the perfect answer to the WebKit project mail. But saying nothing looks quite rude to normal users.
I do know that there are talks in the background, private e-mail responses and so on – but normal users don’t know this, thy just see a friendly but un-answered e-mail.
George: the progress bars were really irritating, most often I had more than a dozen at the same time 😉
I have recently downloaded the kubuntu dvd iso.
I did not get chance to install it yet.
Liquidat, our PR would be much better if people not involved in the project didn’t chose to make half-informed blog entries. It’s also rather hard to make simple PR statements when lots of options are being considered.
If you want to know, that particular step by Apple, done in response to TrollTech’s (not KDE’s) needs is only a small (and easy) portion of what’s relevant, and hardly worth talking about yet. (Coincidentally, they didn’t seem to be willing to do that for us a couple years ago, but hey, progress is progress).
The reality is that we’ve talked about that and many other things with Maciej, but those sorts of things are not that important right now. KDE4.0 is. And I don’t feel obligated to make public statements on every news item CC’d as a courtesy to a development list, just because some people with an agenda choose to stick their noses where it doesn’t belong and publicize it wildly.
SadEagle, if you accuse my posts as being “half-informed”, point out which bits are missing. In recent posts about the topic I always tried to show both sides, I always made sure that readers can read more about both positions.
But if you still think that there are some information missing – than we are right back at my statement: bad PR. If you don’t provide information, others cannot bring them. It’s that plain easy.
“our PR would be much better if …”
No. Your PR is non-existent. It is not because of anyone else reporting about the few information available, it is because there are hardly information available. A FAQ and some debatable comments are not PR.
I don’t call for more detailed information, I just recommend you to improve the PR. That would also include something like “we don’t comment on this since it is a running process” or similar statements.
But the current situation is that most users don’t even know that there is a KHTML developer crew, and that even power users like me would not be sure whom to ask in case of questions regarding the situation.
And again: I don’t attack KHTML, I recommend. Because otherwise it is pretty clear what will happen with KHTML. While I do appreciate that you’ve left some more detailed information here in the comment section, this is nothing I would recommend to you: it’s not me who needs to be told what KHTML and its point of view is, but your pretty large user base.
This is good news, Konqueror really needs a renderer thats is compatible down to every little bug with a browser that has some market share. I haven’t been able to use Konqueror outside of API docs and Wikipedia for a few years now due to Ajax.
I can’t wait to drop the memory hog that is Firefox.
Due to Ajax or due to gmail?
@SadEagle
Actually, even though TrollTech recently made a formal request for a more clear commit policy, this is something that has been in the works for a while, and was not primarily based on their request. The main reasons we did it are: (a) to enable greater potential for collaboration with KDE developers, (b) to scale the project structure sensibly as more companies, projects, and individuals get involved and (c) because it’s the right thing to do.
Also, while there have been some discussions, I don’t actually know of specific things Apple could do right now that would be helpful for KDE. Perhaps that is not worth discussing in more detail until KDE 4.0 ships. I certainly did not intend to cause any bad feelings or distractions.
Let us all come to a right and lowest common denominator understanding.
KHTML, as it is on its own, has had years to reach the sort of quality and completeness that will enable a KDE user to visit a wide variety of websites with confidence, and have it render as intended. KDE developers also want a KPart component that will achieve reliable rendering for all the sites and content out there on the web, otherwise their software isn’t going to be of much use to people.
KHTML has failed at this, and there are compelling reasons as to why it will never achieve what is required from a modern HTML/JavaScript engine. Mainly, it simply does not have the user base or market share clout of any of the other major engines out there, so overworked web developers are simply going to pay no attention to it. Closing bugs as ‘WONTFIX’ with a comment asking web developers to change is not going to work, so let’s accept that now.
People are free to continue to work on KHTML, and I sincerely hope people do, but forgive me when I say that distributions, KDE’s users and KDE’s developers are going to use the rendering engine component and KPart that will actually work and render the vast majority of sites out there, without having to file a ton of bugs and without having to simply install Firefox. KDE’s users have waited years for a fully-fledged KDE web browser that will just work. Usage will navigate towards the KDE component that will actually achieve that.
Getting defensive, trying to claim otherwise and trying to dride any kind of WebKit integration into KDE as ‘3rd party’ is just peeing in the wind.
I would really like the ability to select the engine – gecko, webkit or khtml. As a web developer I would absolutely love this.
Man, I don’t think the Free Software would have been exciting as it now is, without all the drama and LoC wars, don’t you think?
I’m a power user of linux for about 7 or 8 years. I have worked with a lot of developers and managed large banking networks in London and San Francisco. I’m not a developer however. I think you guys should know that I have stuck to Ubuntu for the past couple of years because I know I can give it to my friends and it will replace windows for them. I use konqueror all the time as it is fast and I like how you can browse directories etc with it as well. But.. when I use internet banking or upload photos onto a site etc I have to use firefox because I know it will work. I hope this “user” perspective is useful to you developers out there that are inside the problem. And, thank you all for your work on kde, konqueror, firefox etc we do appreciate it!
But I like KHTML more…..
I think it’s better to use the KHTML as default renderer.(And secondary renderer is WebKit)
Because KHTML is “Konqueror’s renderer”, but WebKit is Safari’s.
KHTML is NOT only Konqueror’s. It is the whole KDE’s! I think.
lRabbit, actually WebKit is the renderer of a lot of browsers in these days. There are at least three Gtk based browsers capable of using WebKit (and one even uses it as default), the Android platform will use it, Nokia’s browser uses it, on the Windows platform Swift uses it, and even on the MacOS X platform there is not only Safari but also two or three other browsers.
In fact, the only platform which does not has a stand-alone WebKit browser is KDE.
Of course you are right that KHTML is not only Konqueror but that several parts of KDE depend on KHTML. On the other side, WebKit could replace that bits as well, if the developers would want to do that.
But in general you should not forget: WebKit is a fork of KHTML – so they are not that far apart!
Excuse me. it’s “L”Rabbit, not ‘I’.
I know WebKit isn’t only used by Safari. In fact, I also agree to that. But I hope KHTML can be install by default.
lRabbit, now your name should right. And about the default installation: it will certainly be the default for the next couple of releases.
However, this also depends on the distributions. But at the moment there is no working, production ready kpart featuring WebKit anyway.
This is really simple.
Apple, make KHTML-programmers responsible for Webkit, pay them for it, KTML and Webkit will become one and a new era of world domination will start… LOL
hmm.. KHTML, not KTML