Many others have weighed in on the matter since, and it seems there are huge numbers of comments on each of these blog entries. I haven't read the comments as I don't have time to do so today (I have a couple hours to close out some bugs I want to kill and then I have to dash out to the outskirts of the city for a farewell dinner) and I'm not sure I even want to open that Pandora's box, to be honest.
For those who are discussing it, here are some thoughts that rattle about in my head, in point form, that others may find useful in the discussion:
- This has nothing to do with Konqueror beyond "we'd like to use Konqueror, so we need a suitable rendering engine for it". The discussion is really about web rendering stacks.
- That we need to have this discussion says nothing negative about the KHTML developers, their efforts or those who use KHTML. The people working on KHTML enjoy doing so, have their reasons for doing so and do great work. They can and should work on KHTML for as long as they enjoy doing so.
- The discussion should remain centered on what application developers need and what our users require so as to make decisions that serve those ends properly.
- There are two contexts for web content: web browser (e.g. Konqueror) and application usage (we use web content in Plasma, throughout Kontact, in application intro screens, in some control panels, in educational apps, in ... a lot of places). These two contexts may not have the same answers. There is C++ API currently missing in QtWebKit that make it not a great option for some applications (though it seems Qt 4.6 is addressing a lot of this issue), but which is pretty well irrelevant to its use in Konqueror as a web browser. There are vice versa examples as well. So keep in mind that there is not, at least not right now, a "one size fits all" solution availalble to us and the discussion ought to reflect that. We need to pick the right answers given the specific questions.
- The reality is that some applications are already using WebKit, so this isn't particularly revolutionary.
- Equally real is that KHTML will be with us at least until KDE 5 and there will be users of KTHML for quite a while yet no matter what happens.
- QtWebKit is not perfect. It's moving forward nicely in Qt 4.6, but to be perfectly blunt: I am disappointed with its progress to date. I had hoped it would be much farther along than it is now. I see all kinds of cool demos for it, but it's mostly for embedded application and usage. We aren't testing it enough on the desktop and we aren't creating enough pressure to move it forward in those directions. Those responsible for QtWebKit would, imho, be wise to put more human resources on it as well.
- The biggest asset WebKit has going for it is broad usage and broad development by numerous entities. The web has become stupidly complex and is ever evolving; it needs a large developer base to keep up, and this is why WebKit works "better" than KHTML on today's "web 2.0". (As a related aside to the Gtk+ WebKit developers: naming your library libwebkit is not only ballsy it's downright ridiculous, divisive and offensive. It's a shameful decision.)
- Here's the most important point, and thus the one I'll end with: this discussion will not matter one little bit in the least unless people commit to a solution and write code for it. Words are great, but they are just words. It is the effort that turns those words into something that matters. You don't have to ask for permission to work on something, either. Just do it, where "it" in this case is the webkit part in playground/libs/webkitkde.
19 comments:
I worked with QtWebKit to write a WYSIWYG HTML Editor for KDE (4 bugs left until beta 1 going public, matter or hours if I have time, BTW, thanks for braking the KHTML "welcome" template in 4.3, this one will be harder to fix, but the new one look better). The API mostly suck, but things can be done anyway. I managed to wrote a small WYSIWYG that I hope to drop when a better will be out. It is possible to use JavaScript to bridge C++ with QtWebKit. Ariya make an example how to do this and I extended it to my own need. But what is truly missing is a HTML-QTextCusor to know where the frame cussor is positionned in the HTML code. More advanced features can't be done because this is missing (and I have no idea how to do this with JS). What is also missing is drag and drop of elements like images, selection support for non-text elements and only bold, italic and underline have two way communication (query if it is used and set used) other can only be set (justify, align, text color). I really miss those things and if nothing can be done with 4.6, I will have to switch to KHTML and implement the feature myself. I really hope QtWebKit become usable, but right now, using it mean making an hacky un unperfect APY with nothing to support it.
@Elv13: that's a perfect example of why it's important to remember in this conversation that it's not a one-size-fits-all situation and that we ought to pick based on the challenges in each particular use case.
In your case, QtWebKit may not be the right choice. I don't know. We'll see. :)
Maybe you'll go with KHTML and be perfectly happy. Yet that doesn't say anything about the challenges Konqueror faces.
So we need to decide this on a case-by-case basis, and the discussion must remain clear on that.
Otherwise we'll get results that work somewhere but not elsewhere, no matter which decision is made between WebKit and KHTML.
For the foreseeable future we'll need both. We also probably need to be using WebKit in more places than we currently are.
I just wanted to say, Aaron: I love reading your blog entries for reasons like these. You provide such a balanced view of what goes on in the KDE community, as well as the entire Free Software ecosystem. Kudos to you for providing insight into an issue that I didn't fully comprehend. Also, your depictions of the latest and greatest things happening to KDE and Plasma are always great to read about. Thanks!
As for Webkit, if someone really wants to provide a full Webkit browser for KDE, they'll do it. If not, I'm not too worried. KHTML is a great rendering engine for most things, it's just got a little ways to go is all, in my opinion.
@aseigo: I agree, the naming of WebKitGTK+ was ill chosen, as was making it 1.0 too soon. I am not sure who made those decisions and why, but as a WebKitGTK+ developer, I'd like to sympathize with you on this, and let you know that those who are currently working on it have considered undoing some of the mess, and we may see some progress during GCDS.
As for KHTML/QtWebKit, if a GNOMEr opinion is welcomed, I would say that, as has already been pointed out by a KHTML developer, and now by Aaron, the discussion is moot. There's no point in raising this point again and again. Those who want to see QtWebKit used in Konqueror, step up and finish up the WebKit kpart, and leave the KHTML developers alone doing whatever they please.
@Gustavo Noronha: "and let you know that those who are currently working on it have considered undoing some of the mess, and we may see some progress during GCDS."
that is indeed great news; i hope it is successful. if it is, i will note that in a future blog as i believe in recognizing not only mistakes but also, and probably even more so, improvements.
"if a GNOMEr opinion is welcomed"
sure :)
"the discussion is moot."
agreed, it's time to write code.
I think the lack of progress that Qtwebkit seems to be having is that it is so heavily tied into the release schedule of qt as a whole. With releases coming only every 9-10 months, and only as part of the rest of qt (i.e. you can't just upgrade qtwebkit), the development is somewhat stifled. If there could be more backporting of the up to date qtwebkit to the older release, it might progress faster.
Beyond redering issues or anything related to web rendering stacks, i have the feeling that there's one more big thing lacking in KDE's web browsing experience.
And that thing is communication.
You (and others) are doing a great job at e.g. promoting plasma and all the improvements you guys bless us with.
Currently there is like zero communication being made on konqueror. I'm talking simple stuff like what's being worked on or discussed.
Not every developer can be such a proficient blogger as Aaron Seigo but, given today's use of a pc, a desktop (and kde's much about the desktop, right ?), Konqueror should be promoted as a flagship application.
When I show KDE to other people, i want to be able to say "Look at Plasma, Kwin effects and Konqueror !".
KDE's much more than this but i'm talking about basic marketing here and bling as well as "web 2.0 stuff" are efficient for this.
I use Konqueror daily (this means for 95% of my browsing) and i'm deeply convinced that it is only inches away from being at least one more killer app you get in KDE, be it with webkit or khtml, whatever.
Konqueror should become one of KDE's big "brands".
So, to the devs involved : many thanks and congrats for your work, just show it off a bit more ! Be proud of Konqueror and promote its features ;)
@Elv13: If there is still missing API in QtWebKit whatsoever, than make sure your opinion is heard, e.g. by stopping by at #qtwebkit.
Well this isn't a new issue and reading about it again and reading some comments I have come to a hard sounding but honest opinion.
By telling people that KHTML might catch up and that it might work for users in the next release the KHTML devs are actually hurting KDE.
They are giving people the illusion that web apps will work in KHTML, but they won't. Web apps are complex and buggy and they will only work in tested engines. For example Google Web Toolkit has something like profiles for IE, Webkit, Gecko and maybe for Opera, but Google won't bother supporting KHTML.
They just won't.Google Wave will never work in KHTML. So there is no solution in sight. Same goes for nearly every other complex site/framework.
IMHO it would be best if KHTML devs would acknowledge this and tell people that another solution has to be found. KHTML is no solution. I think by fueling this illusion other devs avoid working on another QtWebkit based browser because they want to be nice to the KHTML devs and they think the HTML part in KDE is somehow covered. But that is just an illusion. It isn't.
I think if development of KHTML would just stop KDE would work harder on a real solution for its users.
So in essence I think this is the rare occasion where contributing to one project is bad for other projects. Sounds crazy, but just imagine what would have happened if KHTML devs had just stopped working on it after 4.0.
I for one think that Arora or Rekonq would be in a better shape right now. That is what I honestly believe. But Aaron probably has more insight into this issue. I just wanted to give my .02€.
The web is _by far_ the most important use case for a computer today. KDE is great and they would come up with a plan it fix this issue, but at the moment that is not happening because of the reasons I mentioned.
QtWebKit might not be perfect. WebKitPart is buggy but I rarely see a website which doesn't work in Arora - and I see a lot which do not work in KHTML.
@Tom: new kind of vendor lock-in in action. It lacks free software feeling. It sucks.
I'm not a KDE developer, but I am a KDE user and a leading developer on a major open source web application framework.
To put it simply... we support WebKit/Safari. We don't support KHTML. Occasionally one of the two Konqueror users (of whom I am one) will find time to fix a Javascript error in KHTML, but not often. There's simply not enough market share for anyone to really care. And that's with us leveraging jQuery for nearly all of our Javascript, which solves most (but not all) cross-browser Javascript issues.
The net result is that much of our admin interface doesn't work in KHTML. No one even bothers to test it because it is such an edge case. In the next version we're adding a lot more Javascript-y effects to the admin UI. I predict that they will be completely non-functional in KHTML, because there is simply no one to test it or debug yet another particular rendering engine's quirks.
I use Konqueror/KHTML myself. I am using it to post this message. I find it much faster than Gecko, and Firefox has some totally screwy rendering issues on my Kubuntu 8.10 / KDE 4.2 system. But professionally, I simply cannot support it. There's a few hundred people working on keeping our system working with Safari/WebKit, and maybe 2 on a good day paying attention to KHTML.
I hate that. I really do. I wish it were otherwise, but it's not. As a web developer who supports open source and wants to see it take over the world... there isn't room in the market for another engine. IE 6, IE 7, IE 8, Firefox, and WebKit are already too many to support, and KHTML simply doesn't make the list.
I really really hate to say this about someone else's code, but KHTML is a dead end. It's been supplanted by its offspring, WebKit. Such happens in the open source market. It's happened within our project, too. Unless KHTML mimics all of WebKit's quirks, it will become more and more fringe and unsupportable by other projects. And if it mimics WebKit that closely... it's probably easier to just use WebKit.
So as someone who builds web sites for a living, supports open source, and supports KDE... please, let's focus on making a good WebKit-based KDE browser and popularize it. The life of the KDE user (myself included) will only get worse until that happens.
Sorry, I calls 'em as I sees 'em.
KDE as a desktop needs to consider this from a practical point of view: Konqueror/KHTML has an extremely niche userbase -- (essentially) no web developers are testing against it (so very few bug reports will be filled by web devs).
Gecko has a large user and developer base, but as far as I understand, it is deeply embedded into Firefox.
WebKit has a larger than KHTML user base, but more importantly, it's developer and user base seem to be growing fairly rapidly.
Many KDE distros/spins ship KDE with a single browser, Konquror. That means many users are experiencing KDE for the first time with one of the least most used/tested/developed against browsers currently available -- their experience is going to be at best unpredictable. How far behind will KHTML be with HTML5 support? I'm sure a new user will miss that pretty soon.
IMHO, if the aim is to have a modern kde *browser* (which is a special case of html rendering, as you note) the best solution would be to create a new one from scratch using QtWebkit, and contributing to QtWebkit to improve it if needed (missing API etc..)
In the case of a browser, using KPart with generic and abstract code everywhere seems utopic to me. The result would be too complex or messy and thus not realistically maintainable.
Basing this browser on Konqueror (imho) is not a good solution. It code base has a lot of history, had been migrated to Qt4 and seen lots of evolutions. As a software developper too, I do not believe that Konqueror has a clean and easily maintainable code.
Moreover, Konqueror is not *only* a web browser, which means more code and features which add to the global complexity.
So in conclusion, I would go for a solution like Arora (or Arora itself?). And yes, this is just *words*
there is also an ongoing discussion about this issue in the KDE brainstorm:
http://forum.kde.org/viewtopic.php?f=83&t=38873
The suggestion to come up with a better browser solution ranked 4th amongst over 1000 contributions.
Aaron, I think KDEs need some leadership on this issue - the problem seems to be that the focus of KDE developers working on Konqi seems to be out-of-sync with the needs of real-world end-users, that want to use heavy sites such as Facebook, Youtube, Gmail, Google Maps and the like on everyday basis.
If no one of the current developers is willing to step up and push the integration of firefox or chromium into KDE, I suggest splitting this task into a number of google-SoC projects to get things in motion.
This is a long shot, but maybe it would even be possible to get some funding from google to hack up a tight KDE Integration (I'm thinking chromium-kde) for chromium.
I started playing with Arora last night on Fedora, and was better than I expected -- though a UI expert would be nice to make it better. I was surprised that it had both Flash and HTML5 audio working.
reading the above comments, people keep talking about konqueror (or alternatives). as i mention in the blog, this is not the topic here. it's KHTML and WebKit. regardless of the application chosen, that's the critical bit here.
trying Arora and finding flash, html5 media and what not working? that's WebKit, not Arora.
this is an important distinction to make because non-browser applications use KHTML or WebKit, too, so limiting it to Konqueror/Arora/Rekonq precludes a large number of important use cases.
it's also important because i don't think we can, as a community, rationally discuss both the topic of "which browser shell" and "which rendering engine" simultaneously and come to a consensus; some of us will be talking about web rendering engines, others browsers, others both in an intertwined message.
so let's keep it clear, and discuss KHTML/WebKit/etc and leave the applications that wrap them out of it for now. :)
@Tom: well, the KHTML developers aren't going to do that. they have their own ideas and desires and they are fulfilling them. there is no room in that for "tell people not to use KHTML", and as free actors we can't force them to do so.
so it is up to those of us not working on KHTML to make the decision as to what to use, in the best interests of our applications and our users.
Plasma chose webkit.
@Crell: yes, that very much sums it up. thanks for that affirming insight.
@shamaz: "The result would be too complex or messy and thus not realistically maintainable."
i'm not sure that reflects the reality of the code base.
konq does need some work internally, but it's not that much of a mess. the big thing you gloss over with the "skip a kpart approach" is that most apps (Plasma is an interesting exception here) use KParts to get at the web rendering stack because it prevents a lot of additional work that would otherwise be necessary.
Thanks Aaron, I kinda knew that already. But I still think it sucks that the KHTML devs aren't honest with their users.
State of the art web apps (like Wave) are likely to _never_ run flawlessly in KHTML.
That is something I want to hear from them. Instead they say the web evolution will slow down and KHTML might catch up. But it just won't. The web won't slow down and even if buggy web apps will only work in tested engines. There are major industries pushing browser innovations and web apps. W3C standard won't help them to keep up.
Delusion is not a nice word, but it is what comes to mind.
I respect their work and the technical decisions, but I just don't like their "marketing". They should be more honest and reflect their own track record.
Until we get a well working QtWebKit based 'component' (and from there, a browser) in KDE that can run web applications and AJAX well then I'm afraid it's just undoing all the good work done in KDE thus far. The first thing people look for in a desktop these days is the web browser.
Aaron is right however, that it isn't about the particular browser (Konqueror, Arora etc.) and all about getting a working WebKit component integrated with KDE that can be used everywhere. It's the sensible thing to do. From there code can actually be written and new browser avenues explored. Using Firefox, as most people have to today, is suboptimal because the integration with the desktop environment is really quite poor. On many levels it's quite bad in Gnome as well.
It remains to be seen whether Konqueror can be the QtWebKit using browser of choice. I don't think it can personally. Creating a swiss-army knife browser was brain damaged from the start as there are so many things you have to pack into it. It's the biggest reason we now have Dolphin for file browsing rather than Konqueor. Dolphin is rather a good name for a web browser however ;-).
Post a Comment