In this week's KDE Commit-Digest: A Sonnet-based spellcheck runner, and icons on the desktop in Plasma. Continued work revamping KBugBuster, more work towards KDevelop 4. GetHotNewStuff support for downloading maps in Marble. Image and audio dockers in Parley. The start of Glimpse, a new scanning application based on libksane. The beginnings of a generic resource display framework for NEPOMUK. Various work in KHTML. Music Service configuration work, and the integration of last.fm code in Amarok 2.0. Printing work in KOffice. A Sybase database driver for Kexi, panorama work in Krita, and ODF work in KChart. Kompare becomes usable for KDE 4.0, and gets a new maintainer. The confusingly-named game KWin4 is renamed KFourInLine. Trolltech-supported Phonon backends for all major platforms (Quicktime 7, DirectShow 9 and GStreamer) are imported to KDE SVN. Read the rest of the Digest here.
Comments
Hy.
Thanks everybody involved in the digest for yet another interesting issue. Last week was realy gread, but this week shows a lot of little interesting things.
And thanks danny for fixing the web page fast enought for me to read it before going to work.
It's especialy nice to see, in the whole lot of KDE4 commits, that some KDE3 stuff still happen. And every week, to see a few KDE4 rought edges be smoothed.
Good work everybody
In KDE 4.0 RC2+ (at least in openSUSE) Konqueror uses WebKit by default for web browsing. Is this intentional? It still has several issues (no cursor in text fields, not redrawing scrollbar, not reacting to submit button).
And, there is no WebKit in the bugs.kde.org application list. Where should I report WebKit bugs?
Your distribution, or webkit.org. It's not a KDE project.
webkitpart is in KDE's playground SVN - why should those bug reports go elsewhere than bugzilla.kde.org?
Because the only people who are likely to read them there are
the people who do not want to read them.
That's kind'a sad... Really, I can understand your frustration, but you're going a little too far lately.
It's not too far if one considers the sort of BS one has to put up with.
Crap like what this patch reverted:
http://lists.kde.org/?l=kde-commits&m=119323520703513&w=2
Crap like articles about KHTML future which are wrong and published
without asking a single person involved in the project.
Crap like people playing PR games, and forcing me to waste time writing FAQs, and trying to explain things, which I am not very good at, and when I could be debugging.
Crap that nearly blew the KDE4 release, by discouraging core contributors who have to deal with FUD from people who are supposed to be friends. Not that KDE4 is likely to be something to show off to one's parents with pride, being that some people feel that marketing solves everythign. Heck, I nearly went "screw it" myself, but fortunately my tendency is more to get pissed off then discouraged.
The main positive of this is that it really reinforces that our differences with Apple are those of goals, and that most of their folks are of utmost integrity, and that they have never done anything deserving aprobation.
Sure, I dislike many things they did on technical grounds, but people's technical styles differ.
Uff. Though this was a reply to the other post.
To address this one, it's actually true: the only person I know that's working on the kpart is George Wright, on occassion. It's basically barely ever touched otherwise. Sure, TrollTech works on the Qt port, and Apple and some outside contributors work on the core renderer, but that's why those bug reports should go to them, other then wasting our time.
P.S. Reading kde-bugs-dist ain't much fun as is.
Hmmm, I see your point. Sorry for accusing you of saying something sad while it was actually true ;-)
I think these bugs are in the Qt port of webKit, not in WebKit in general.
Oops, forgot about that. TrollTech would want them.
See this post:
http://zrusin.blogspot.com/2007/10/khtml-future.html
All the big KHTML hackers including the guys that actually created KHML are working on qt-webkit now. Ditching code is part of a developer life. I ditch code all the time, aseigo did ditch a lot of code when he started plasma, everybody does it. So why do you make such a big deal about ditching your KHTML patches? If you're a developer you should know that this is part of a developer life. WebKit is clearly superior, it has better support for design mode and many websites outthere (gmail, youtube, facebook, google doc etc) and it has something that KHTML will never have: market share.
So get over it and stop spreading FUD about webkit, it's coming to KDE, every big KHTML hackers want it, all big distros want it (opensuse and kubuntu), users want it so you're all alone now.
Funny that you mention FUD. None of the guys there are KHTML hackers.
They used to be, but have not been in involved in 4 years or so.
Well, I've never said they are working on KHTML right now have I? Those guy are the best web rendering engineers KDE ever had according to zack and given that zack is pretty smart and that those guys invented the whole KHTML in the first place I think we can agree on that. Now those guys, Lars, Antti and co decided to go with webkit because it is clearly superior to KHTML, if KHTML was better they would have gone for it unless they were masochistic.
Also these guys are working on Qt, the foundation of KDE, they moved to Norway in order to be able to help KDE. That's a pretty strong move I think, would you move to Norway just to help KDE? You're not even ready to ditch some patches to help KDE so... By the way just because they didn't work for it in the past 4 years doesn't make their opinion doesn't count especially since the KHTML developpment has been pretty static (still no design mode or gmail etc).
Swallow your ego and get over it.
Antti works for Apple. And the other people 'decided' because their employer wanted a product, and one not tied to KDE. They weren't heard of before that. Those same people entirely abandoned KHTML for many years, leaving it basically unmaintained until the current generation showed up. And now they suddenly reappear and their opinion matters? I don't think so.
What I am not willing to do is tie KDE's future to two corporations without an escape hatch and any sort of representation of KDE's values. I am not willing to see KDE use half-integrated codebase that's maintained only by people whose primary users aren't KDE users. I /am/ willing to throw out lots of my work; though I am definitely not willing to let other people throw it out for me. Especially people who spend more time self-promoting than fixing bugs. And doubly so people who never touched it the first place. If you're not doing the work, your opinion is irrelevant. That's the OSS way.
Look, you have a point. We all get that point - really. I mean, really, we do. You feel neglected - but that's not true. We just weigh the arguments different than you do - and not even as different as you might think.
KHTML is the default rendering engine for KDE 4.0, and probably will be for 4.1. Your work is recognized in WebKit - and will be, even if it might replace KHTML within KDE. Your opinion is valued - more than you (apparently) think. Everyone appreciates what you guys have done for the World Wide Web. KHTML and it's offspring WebKit are major players when you're talking about advancing the state of technology on the Web. We love you guys, always have...
Yet I do want to remind you that what happens to KHTML isn't *only* up to the KHTML developers. KDE is a community, and the community as a whole will have the final say about the rendering engine in KDE. Sure, what you say is worth more than what I say (tough you can diminish the value of what you say by being so extreme). But refusing to go with the community might lead to you and the other KHTML hackers finding yourself in the same situation XFree86 is in - sure, you can go on. Forever. But nobody will notice anymore... That is ALSO the OSS way.
Allowing that would be a disservice to both yourself and the community. Please don't.
You're certainly quite reasonable, but it's hard for me to view the word community as anything other than a farce since some "community" members have basically tried to ignore what we think and to force our hand by playing PR games. Behind our backs, too.
The reality is that I am not actually opposed to incorporating WebKit, inside libkhtml. I think it has to be done the right way, a way that doesn't endanger KDE's long term interests, and in a way that actually integrates into KDE. Integrating into Qt isn't good enough. A reasonably setup permitting that sort of integration might happen for 4.1. It might not. That might happen for 4.2. It might not. It depends on whether we can work out difficult issues, both technical and social.
I can't understand how an opensource project, forked from KHTML, cannot be integrated into KDE and cannot be used by KDE in the future. I mean, today Apple seems to be happy to collaborate. If one day they change they mind, well, fork again. I can't understand your point. You're putting effort in maintaining two very similiar but still different products, so a possible future re-fork shouldn't scare you, should it?
I'm reading your posts/messages on the net, SadEagle and while I say you a big thank you for all your great work, it seems you're suffering the NIH syndrome.
For all the reasons many people in FOSS remake apps that already exist : because they think they can do better.
KHTML devs obviously tend to believe many parts of WebKit are badly designed and written. If it does not seem possible for them to implement them properly in Webkit, I can understand they want to keep their own approach.
So my question back to you is : why would you want them to stop it? Are you so sure of the outcome? Not me, and as such, I'm willing to have both solutions working to compare them and choose the best instead of having the choice being made before for me in that matter.
The "escape hatch" is the LGPL. WebKit is free software and it stays free software. If WebKit moves into a direction that's harmful for KDE, WebKit can be forked again. WebKit is maintained by lots of full-time employed people from Apple, Trolltech, Nokia, Adobe, Google, etc. + hobby developers. How are a handful of hobby KHTML devs supposed to keep up with so many WebKit devs? Are the KHTML devs cyborgs that work 24/7?
Why does KDE have to stick with the current KHTML code base anyway? If the KHTML devs think that the rendering engine must be developed in KDE's SVN, then just fork it now. The platform integration work is easier than the compatibility and speed work that KHTML is missing right now. WebKit is faster and has a more compatible "quirks mode" than KHTML. I use mainly three computers: a 2.3 GHz Athlon 64 X2 PC with 2 GB RAM, a 2.6 GHz Pentium 4 PC with 512 MB RAM, and a 1 GHz iBook with only 394 MB RAM. I use Linux with Konqueror (v3 and v4) on both PCs and the waaaay slower iBook renders websites in Safari much faster than Konqueror.
It doesn't work like that. You need people with skills and background to fork something, and really, you need continuity of development, otherwise things just bitrot. If you look at the history of Apple forking KHTML, it really took them awhile to get up to speed, and they had (and have) some phenominally skilled people working for them, and those were people whose job was to get this done, and who weren't juggling 5 other projects, as OSS people frequently are. Developers don't just pop out of thin air all the time to pick something up, they have to come from somewhere. And pissing off actual KHTML developers by playing games behind our backs isn't very conductive to that.
And yes, we're considering a KHTML based on WebKit sources, as has been stated before, many times, I might add, but we won't want to fork things, but rather to try to find a way to work together. That might happen. It might not, like about 5 previous attempts, but at least things like git can make some things easier. And, again, I'd rather all the people playing PR games helped --- but of course, most of them don't have much of a background, and seem they would rather confuse our users instead.
P.S. Most (all non-Apple ones?) of the companies you listed just contribute platform ports, per one of the nice Apple folks who hangs around in #khtml and who we work with on JavaScript stuff.
P.P.S Platform integration isn't easy, and a lot of it is speed work - X11 sucks.
P.P.P.S As for keeping up.. You're right that we can't keep up entirely, but it's actually not as dramatic as you would think. Basically, working with limited time can actually be helpful, as it forces one to make smaller, more focused changes, while someone with a lot of manpower can just brute force it.
It's more of "think of a change periodically for a couple of weeks, say while taking a shower, and then make a 10-line patch" rather than "sit down for 3 days and make 3000 lines of changes". One also avoids a lot of pointless changes, and doing things for tiny short-term benefits which would have to be replaced soon anyway. This sort of thing is actually one reason while working together is difficult -- there is a huge difference in work styles.
Your reasoning is most interesting.
Whatever happens with khtml vs webkit, please keep expressing your opinions in such a clear manner.
In the end, Excellency (in software) often comes from the synthesis of diverging viewpoints.
Regards,
Kig.
> WebKit is faster and has a more compatible "quirks mode" than KHTML.
I'm afraid you are wrong on both accounts, and a propaganda victim.
Just see the only DHTML benchmark the WebKit guys have been boasting about in http://webkit.org/blog/122/webkit-3-10-new-things:
http://nontroppo.org/timer/progressive_raytracer.html (Full Render)
KHTML kicks WebKit's ass at it by a factor 2.
And I really mean WebKit. When you take qtwebkit, it was actually a factor 5 last time I tested. Same goes for CSS speed tests where KHTML consistently beat the living crap out of WebKit.
There are various reasons for that.
The WebKit team did a lot of corporate-needs-driven premature optimizations a long time ago, that they are paying now in term of entropy and added complexity.
The rendering code has been especially lagging behind in this respect since there is only one really knowledgeable developer for it in the whole project (dwh), and he has become quite a busy man, with no replacement at all in sight.
For instance they tried to deterministically compute the visual rectangles for part of the CSS specification that was not meant to be deterministic (in-flow elements). This was all the more silly than the expected gain is modest and far offset by the decrease in maintainability, which prevent optimizing far more substantial aspects in the end.
Apparent pressure from their hierarchy lead their developers to do all sort of code uglifications for the sake of a "performance holy grail" that were actually blatant violations of the 80/20 rule leading nowhere (as a rule of thumb, you spend 80% of code execution time in 20% of the code, so it is pointless and damageable to evolutivity to try and optimize the 80% portion of the code that's not performance-critical).
Their are lot of examples along this line of too early solving, like the fact
RenderObjects coordinates cannot be simply iterated upon in WebKit, because of a design problem with table rows . This is even more damaging since another design problem with table was solved with a less-than stellar patch that requires you to add some random offsets here and there to absolutely positioned objects (the ugly absolutePositionForContent).
In the end, the new developer is just facing an ugly mess.
That's not helping, and probably explains why so few rendering patches have been contributed by developers other than Apple.
Trolltech, for instance, has not contributed a *single* core rendering patch since they began working on their backend. That's something very unsettling.
As for web compatibility, well, I just have before me a list of a good 30 (thirty) very significant compatibility defects that are not in any other engine in the market; and certainly not in KHTML.
Compatibility has never been the forte of WebKit.
Since the beginning Apple has preferred moving forward and having web designers turnaround the compatibility bugs by agressively marketing the Safari web browser and its User Agent string.
It's not by chance than Zack Rusin has been defensively stating "we'd better match Safari bug-for-bug"... it's rhetoric defense of WebKit's severly lacking in this domain.
This is a bit saddening when you realize your derived webkit browser is not going to have the same user agent string, and will therefore never have the web "compatibility" that the Safari browser enjoys and which is based on User Agent string sniffing from JavaScript.
Wow. That sounds messed up.
I'm of the opinion that Apple chose KHTML as a base for a reason (cleanness and correctness). They've since moved away and it sounds like they are maving away in ways that aren't good.
I thought before that KDE should stick with KHTML (own project, one not driver by corporate concerns and tied to a specific platform outside of second class ports). Hearing this makes me think there are other reasons to stick with KHTML as well: the correctness and cleanness that made it what it is.
So I'm all for staying with KHTML. Fortunately, unless someone steps up and codes (and shows his solution is superior), that is exactly what will happen.
You should blog about this (maybe just copy your post)... Get this info out, it is very interesting and it would be informative to get replies from others on this.
The reason why they "abandoned" KHTML is because they couldn't keep up with WebKit just as you can't. But instead of sticking their head in the sand they tried everything to find a good engine for KDE. So they first went for Gecko but the code was so messy that they had to give up. By that time, webkit was born and doing great, so they did the smart thing and tried to integrate it into KDE. That shows how much they care about KDE and about KDE HTML engine, in other words: they care about KHTML. And for this reason, their opinion matters a lot, just like yours.
Also, all the things you say about webkit and apple makes no sense. WebKit is LGPL so if things go wrong you can always free yourself from apple. Especially thanks to the wonders of Git and now that Trolltech is doing exactly that (staikos Git repository), there is no reason to worry already.
Excuse if this comes across in the wrong way but who exactly are you and why should I as an uninformed bystander pay any value to what you say? I have worked out who 'sadeagle' is and his credentials but 'Paul', who are you, and what have you contributed in any real sense apart from these sniping comments? You obviously aren't a professional/mature coder from either camp as you appear to have no clue about either codebase.
I hate these armchair (backseat) code architects chirping up in matters which they invest little in themselves. If it's not khtml/webkit it's plasma or the menu.. does anyone really believe things get sorted out for the better in this forum? Far more likely is this is evolved by the experts and *do-ers* behind the scenes and between themselves, at least I hope so.
The problem is that SadEagle always systematically downplay qtwebkit and people who work on it as being non interested in KDE affairs. People who don't know about the situation might believe everything SadEagle say about KHTML and so I'm just stating what Zack, all qtwebkit developers and many users think of the whole situation to inform people and put some balance in there.
You have the right to disagree and keep on working on KHTML for the rest of your life as nobody cares, but don't try to say that KHTML will never get webkit or that there is a secret ploy against KDE coming from qtwebkit. That's just ridiculous, false and hurting KDE.
Well, QtWebkit alone won't satisfy KDE's needs as it has to be turned into a KPart to fully replace KHTHL and right now it seems to be more or less moldering in svn. For all the pressure some users and developers are exerting on the KHTML developers I don't see anybody standing up and saying "Screw SadEagle and his lunatics, we want WebKit and we'll make it happen NOW!". Maybe the situation will change after the release of KDE 4.0 and Qt 4.4 and some non-KHTML developers will divert their attention to developing and maintaining(!!!) a Webkit KPart but trying to bully the existing KHTML people into doing the work although they have reasonable reservations and/or simply don't want to is very untactful and very ungrateful considering the work they have done. "He who codes also decides" still applies here.
I second that. KHTML does provide quite a good level of service and instead of playing the FUD part, Webkit supporters should just make it working for KDE and allow the users to compare instead of trying to tell people what to do. Maybe they're right and Webkit is the future (I tend to believe it's the case) but I think they need to prove it and not just try to discourage KHTML devs by claiming they're making useless work. Actually, I'm sure that's what they're doing, but they should do away with the FUD part, IMO.
Damn, my last sentence reads like I claim KHTML devs do useless work. I meant I think that I believe Webkit people are working to prove Webkit is the future.
After reading Sprat's post above, though, I must say I'm a bit dubious and rather glad to still have KHTML.
I think pretty much everyone thinks that a completed QtWebKit KPart is inevitable, no is bullying current KHtml devs. QtWebKit is relatively new project, you can hardly say that its even newer KPart (that I didn't even know about until this thread) is "moldering" in SVN.
To answer your post, I'm not a KHTML developer but as a developer I ditch code all the time. Sure it's a pain sometime to throw away hour of work. But when I do so it's generally because the new solution is way better than all the code I've been writing for hours. Now if I were working on a web engine, I would throw my code anytime for WebKit :) If I could get something as powerful as webkit backed by many coorp to replace any of my projects, I would ditch them right away. This is one of the reason I use Free Software, you know linux, emacs, kde etc :)
Well, that would be wise if WebKit was better than KHTML. But unless you had a good look at both codebases you can't know that. I haven't seen many wellinformed comments about that, except http://dot.kde.org/1198130504/1198185607/1198186308/1198187782/119822967... and I would love to see comments from other developers who know both codebases about this topic.
Who cares about that benchmark, here is one that runs faster on qtwebkit than khtml:
http://webkit.org/perf/sunspider-0.9/sunspider.html
Anyway, nobody cares about javascript benchmarks. What users care about is being able to use their favorite browser on their favorite website such as gmail, google doc, youtube, facebook you name it. Now webkit allows me to do just that. And for the matter KHTML on KDE 4.0 doesn't even work with youtube and screws up with digg comments while qtwebkit does.
> Now webkit allows me to do just that
Which WebKit browser other than Safari did you test this with?
Because last time I checked even Google's browser check was broken and checking for Safari instead of WebKit, so any other WebKit browser would still be served the fallback.
I compile qt4.4 from staikos Git repository and it comes with a demo browser that uses qtwebkit and works really great, it gets really better everyday and already beats the crap out of KHTML in KDE4.0 as it works with gmail, facebook, google doc etc...
KHTML works with gmail and facebook. I can't comment on google doc.
gmail standard view with chat on? hm last time I checked it didn't work. And why can't you comment on google doc? cause it doesn't work? :D
SadEagle's above answer was IMO just saying he can't comment because he has not tested. And don't tell me your sentence was humor, after all the bashing you've done on KHTML, putting a smiley at the end does not help.
Apart from that, I use Gmail and Youtube everyday with Konqueror 3.5.8 without issue yet (I don't use Chat though so I assume you may be right, but I suppose that's nothing that can't be fixed). In fact, there are very few sites where I have incompatibility issues with KHTML, and it's quite notably faster than Gecko on large page with a lot of CSS.
In any case, I don't see the point of all this : just make a kdewebkit available to everybody to check if it works better or not tha KHTML, for all the uses made of KHTML. The better will win, period. There's no reason to throw in any propaganda before that happens.
I'm not bashing KHTML, I'm just saying it is way inferior than webkit and that's not because KHTML devs are incompetent or lack skills, that's because a bunch of people can't keep up against Apple+Adobe+Nokia+Google+trolltech+KHTML creators and they all provide bug fixes and features not only platform ports.
As for youtube, did you try to scroll down the related videos box? it doesn't show the video thumbnails and did you try fullscreen videos? Ok.
Now try this:
http://www.carto.net/papers/svg/dock/index.svg
and that:
http://webkit.org/demos/editingToolbar/
it works with FF and webkit.
KHTML still doesn't support design mode so no fckeditor or google doc or any WYSIWYG editor whatsoever and that sucks. People are already working on webkitpart and qtwebkit, we might even get it for KDE4.0 actually and certainly for 4.1.
Well, you have a problem with your settings as video thumbnails and fullscreen videos have been working for me for monthes. My daughters use it all the time to watch Simpsons and Malcom in the Middle. Maybe you have some remaining old configuration settings in .kde that screw some things, I know I sometimes had such an issue in the past. Or maybe you should use the Flash 9 player if you don't yet, it works quite well for me (well Youtube fullscreen mode, with the resolution and bitrate,... never mind). But it does not seem related to a KHTML issue in itself to me.
As for your reasoning about Adobe+Apple etc., that's the obvious propaganda heard by Zack Rusin and co and it **sounds** reasonable in the first place. But I actually have my doubts about it. Corporate habits are very different from open source ones (except maybe for Trolltech) and making companies work together is often a headache, as each one tries to push their solution that best suits their own needs. Having quite a lot more companies behind it has not helped Gnome being a far more better desktop than KDE, despite all the claims made 5 years ago. It may bring very good things but it can end up an ugly ego and interest mess.
As for WYSIWYG, I used Dreamweaver years ago, but I've been quite happy moving to coding HTML with tools like Quanta recently. WYSIWYG may help people to code their blog, but I don't see it as a mandatory service provided an HTML renderer and it obviously doesn't help you code complicated DHTML pages.
Anyway, I still find surprising your claims that Webkit is "far superior", based apparently on a rather partial experience. Especially when you discard not so "superior" benchmarks that even Apple use.
I think you've never used youtube with konqueror or you don't know what you are talking about, here is a screenshot, it doesn't work with any of my kde installs on different PCs and different distributions. Scroll down the "related video" box and see that the thumbnails don't show up, they do show at the top but not when you scroll down and this has nothing to do with flash, it's pure AJAX and HTML. Talking about dev, WebKit comes with inspector that is almost as great as FireBug, something that most web developer can't live without.
As for WYSIWYG, I'm not talking about designing webpage using it, of course it is silly to develop a webpage that way. I'm talking about text_area in HTML form that use WYSIWYG such as the fckeditor, blogger.com, gmail, google doc, yahoo mail etc... I also forgot http://meebo.com which is a real useful site that doesn't work at all with khtml.
As for the benchmark, checkout this one:
http://webkit.org/perf/sunspider-0.9/sunspider.html
webkit is way faster than khtml on that one but I wouldn't care even if it was a bit slower as long as I can actually use my favorite webpages with my browser.
About the development of Webkit, they have an open process and SVN and mailing list, it is very friendly and nobody is "pushing their agenda", if you think there is some kind of conspiration check the ML and see for yourself.
I have Debian testing/unstable 64bit installed and ever since the nsplugin wrapper has been available for use in Konqueror flash has pretty much worked without fail on any site I have tried including Youtube with the little previews you seem fond of. As to the meebo I get to the login page so that works I would think not at all would mean the page would not load ... holding that thought I just said to myself why not try to create an account guess what it worked without problems the rendering could be a little better but oh well you are so full of it it is not funny. Here is a couple of screen shots on your non-working websites.
http://users.eastlink.ca/~stephencormier/youtube.png
http://users.eastlink.ca/~stephencormier/meebo.png
Who knows though perhaps they just don't work properly on your install but it only took me about 40 seconds including signup to disprove the meebo assertion, the youtube always worked for me so it does not help make your points with me at all.
Here a sreen shot from the KDE 4 SVN showing what you say is wrong.
Now please go spread your lies elsewhere, you clearly don't now what
you are trolling about.
Well youtube and meebo still don't work on KDE3.5.8 and KDE 4.0 RC2 at least here, maybe it was fixed in the mean time. Anyway design mode won't work, that's just a turn off not to mention the lack of debugger and the fact that nobody tests its browser on KHTML and that it will always stay that way. As a Web developer I would love to support KDE but with KHTML it justs give me unpaid extra work my clients don't even care about so this is why I and 99.9% of web devs will never design their webpage with KHTML in mind and won't test it and this is the reason why kHTML will always be lagging. Notice that I'm not bashing the KHTML devs here, it's just the reality of the market, no fuck the market, it's just how devs work it is really annoying already to work around IE quirks, firefox, safari and opera so don't expect the situation to improve. Youtube and meebo might be working but it took 4 years already, do we have to wait that long every time a new website comes around? Knowing that gmail and google doc and design mode in general still don't work it looks like KHTML will always need a few years to catch up. Sorry but I and most users won't wait.
It doesn't even matter how good KHTML is, if people don't test their websites on it it won't work, don't you get this? This is why Opera is suing Microsoft because even with the best engine around they can't support as many sites as IE.
Anyway, aseigo and the principal KDE guys have made it clear that WebKit is coming and will replace KHTML so I'm happy and I don't care if you still want to develop it until death :)
> not to mention the lack of debugger
wow, you really are not much current with KDE development are you? :)
> It doesn't even matter how good KHTML is, if people don't test their
> websites on it it won't work
this look like a typical Windows developer mindset :)
Have you ever heard about standards?
Look, I'll take a real example to make it very plain to you why you are wrong.
Say a developer will use this very basic html snippet:
b{vertical-align:-40}____________
As you can see, in Opera, MSIE 6/7, FireFox and Konqueror this will render as a staircase, as the CSS specification *mandates*.
In Safari, on the other hand, it will erroneously render as a flat line because of so-so compatibility.
Now, what will the Web developer do?
Either he doesn't care about Safari and let the bug stay, or he'll just sniff the User Agent string and make a workaround for Safari.
End result: it will work in Konqueror, it will work in Safari, and it won't work on your WebKit-derived also-ran browser nobody has heard about.
QED.
You mean KHTML has something like the web inspector and firebug? cool I hope we'll have it in KDE4.0.
> In Safari, on the other hand, it will erroneously render as a flat line because of so-so compatibility.
I think you don't get my point, of course that WebKit has its quirks, every brothers has theirs and so does KHTML. The thing is that web developers will only work around big browsers quirks because nobody uses KHTML so it's not worse looking at them.
And for the matter, I'm a Gnu/Linux developer, I code using emacs and I test on qtwebkit, FF, Opera, IE4Linux and even KHTML actually sometimes but I'm afraid I'm kind of the only one there :)
a "quirk"? that is an interesting understatement for a
failure at handling a basic CSS 1 property :)