Browser Wars – Reloaded

kde-logo-official
The dispute over WebKit and KHTML reached a new peak today. With Harri Porten yesterday a KHTML supporter already pubslished his position on the subject and today Zack Rusin, a WebKit supporter, answered.

The Background

WebKit was originally forked from KHTML by Apple (more details at WebKit’s Wikipedia entry). Today it the developmnet is still backed by Apple but supported by other groups as well: Nokia, Adobe, Trolltech, some Gnome guys – and several KDE developers.
Soon after WebKit went public it was questioned if the resources of WebKit and KHTML could not be bundled to benefit both. This didn’t work out totally. Some KDE developers decided to help WebKit, some stayed with KHTML.
In the meantime WebKit became more and more famous and spread: Adobe adopted it, Nokia adopted it, Trolltech will adopt it, it is the standard browser on recent Mac OS releases and was as such even ported to Windows. Therefore WebKit became even recognized by web designers and developers.

So nowadays there is the quite open WebKit development project which is not controlled by KDE at all (but up to a certain degree by Apple) but has a nice set of features. On the other hand there is the KHTML project which is fully controlled by KDE, works nice, but still lacks several features. Especially stuff like missing support for WYSIWIG rich text editors in web applications (WordPress editor, CMS systems, etc.) is a pressing issue for several users.

As a result many users still ask what the situation around WebKit and KHTML is.

KHTML’s FAQ

The KHTML supporters team never bothered with marketing. In fact there are not even many blog posts or anything else at all about KHTML from their point of view. This became a problem recently when the KHTML supporters realized that they had no voice for the users outside of the community and that they had no way to answer many of the existing questions.
As a reaction Harri Porten published a “KHTML FAQ” yesterday on behalf of the KHTML supporters. The FAQ picks up the most important points of the discussion and highlights the stand of the KHTML fraction.
In short it can be said that they would like to work together with the WebKit project – if they get certain rights. This is understandable since the KDE project has its own needs and wishes and the KHTML team wishes to work according to these just as it did in the past.

However, the FAQ fails to explain what the WebKit project actually responded to these wishes and needs. Since the WebKit project often highlighted that they welcome other developers the question is what the outcome of current discussions and talks which issues are blocking what.

Zack Rusin’s response

One of the most famous WebKit supporters is Zack Rusin who worked for Trolltech for years. He got reviewer rights in the WebKit project quite some time ago. And he posted a response to the FAQ.
In short it can be said that Zack was pissed of by certain assumptions in the KHTML FAQ: Zack points out that many former KHTML developers simply switched over to WebKit and that they still can be seen as “KHTML developers”. He also highlights that even the founder of KHTML is a strong WebKit supporter, and that in general more KDE people contribute to WebKit than to KHTML.

However, he also does not address the real reason or problem why both projects simply do not work together. The question remains what the most blocking reasons are.

Future Development

The discussion boiled up now and will certainly stay on the radar for some time. After all, this is a discussion and an argument between software developers which are emotionally involved with their software.

There are now two solutions: one would be to let a third party step in to settle the conflict. The KDE e.V. comes to the mind: one of the tasks of the KDE e.V. is to settle major problems between developers and technology. The KDE e.V. is also “official” enough to start talks with Apple (if they want to listen). This would be the political solution.

The other solution is the more Open Source one: the one who codes decides. If there will be a WebKit kpart, then the distributions will include it. Then users will decide on their own which engine they use. In the end, the users will decide.
Or it could happen that a developer starts with a WebKit KDE browser on his/her own. If that one works well and is well integrated with KDE it might even happen that most people switch over to that one. As an example, the developer momesana has already developed an own WebKit browser:

Momesana Browser - Google main page

Momesana Browser - Overview

Momesana also published a video (Ogg, 8.8 MB) showing the “Momesana Browser” at work and performing quite nice.

About these ads

19 thoughts on “Browser Wars – Reloaded

  1. “There are now two solutions: one would be to let a third party step in to settle the conflict. The KDE e.V. comes to the mind: one of the tasks of the KDE e.V. is to settle major problems between developers and technology. The KDE e.V. is also “official” enough to start talks with Apple (if they want to listen). This would be the political solution.”

    No, I don’t believe it is the role of the KDE e.V. to ‘settle’ purely technical disputes. Not everyone who contributes to KDE is a member of KDE e.V. and it would be quite wrong to have a ‘secret ballot’ amongst just KDE e.V. members about development issues.

  2. I wouldn’t point this out as just a technical disupute, as it contains many different opinions from various people. Most primarily the users. Where if a website doesn’t work i.e. gmail then they move onto firefox. Being such in such a minority community, it is hardly going to get attention from web developers and the lesser interest of new developers working again on khtml engine.

    IN part unless someone can radically spearhead the revitalisation of Khtml and activly push new features and compatibility that other browsers don’t have, the engine itself will become outdate. Until the qtwebkit component is finalised, khtml should be left by default, but as with Dolphin, it started from scratch, and to the benefit made things simpler.

  3. It might seem like a naive suggestion, but maybe the addition of a simple Webkit-based browser in 4.1 could be a nice solution. This could follow the Dolphin philosophy: a simpler alternative to the web browser functions in Konqueror. Konqueror (KHTML-based) would still be around for power users, and both would compete for user’s hearts. In a few months/years we would have a better understanding of what is important for KDE users and the direction WebKit development is taking. No need to burn our bridges imo, and no need to stop experimenting with new and potentially very useful solutions like QtWebKit.

  4. I attended the Trolltech DevDays in Munich and the QtWebkit I saw isn’t just a perfect browser.. it’s the “way to go” !!
    You can inject code, change the dom on the fly, insert your custom widgets everywhere in the page, animate a widget using AJAX (javascript and the dom) or qwidget method calls!!
    And try to put the web QWidget on the GraphicsView and you just took the red pill ;-)

    Viva QtWebkit! Try QtWebkit!! Enjoy it on KDE!!! And look for Simon Hausmann DevDays presentation !!!!

    (ah, of course I’m writing this in QtLauncher :-)

  5. Problem isn’t browser. KHTML is used in many parts of KDE to display content. Throwing out KHTML means total submission to foreign entity.

  6. Ok let me see,
    * popcorn?, check
    * soda?, check
    * big comfy chair?, check
    * front row seats to a foss developer war?, check
    * bikini clad women holding up score cards when one developer throws a successful upper cut?, nope
    * blood & spit buckets in the corners for the roughed up developers?, nope
    * some sort of murder/heist/world-domination sub-plot involving men in trenchcoats and fine Italian suits?, nope

    Well COME ON you lazy foss people!!! My VCR is set on ‘record’ and I’m ready, let’s see some ACTION!

  7. @mikmach You can’t call an integral part of Qt (4.4) a foreign entity. KDE is based on Qt and hence there is nothing “foreign” about using Qt Widgets.

    You see WebKit is under heavy development (the decoupled render engine and the Qt bindings) and it will allow cross-platform integration (even in the Qtopia embedded sphere).

    In my opinion, what it is really about, is control.
    This means, should KDE (developers) loose full control (as of unrestricted SVN access) with the disadvantages it might imply or should KDE try to join efforts in the sense of freedesktop.org and put all effort in making a “KWebKit” derived from “QtWebKit”, to get the full KDE integration for the desktop space and join all efforts in WebKit/WebCore to deliver the best rendering engine out there.

  8. A few points – an individual browser using webkit would be no replacement as Kmail and some other apps use html rendering from the default K-part. So a K-part would be the only way to go and it just happens that one already exists created by Simon Hausmann (I think its complete and a complete solution!)

    I hate to see this kind of thing as everyone without knowledge would believe it to be an Apple creation ground up but if the original creator (and most contributors) are content with that then Webkit really is the way forward given the buy in from major companies. So unfortunately I see their point but they’ll just have to swallow their pride and do whats best for KDE which is to go with the better long term solution.

  9. I agree with Dave. The comments about Apple ‘being in control’ of WebKit aren’t true to reality, imho. It is Free Software, so the amount of control anyone can have is limited. We could fork of WebKit, sync regularly and have full ‘control’.

    I think the advantage of the larger marketshare of WebKit are larger than the disadvantage of less control. KHTML rocks, I love the developers – that’s not the point here. We all appreciate every line of code going in there. It’s just a more sane decision to share resources and work with others. That’s another big thing FOSS is about…

  10. “It might seem like a naive suggestion, but maybe the addition of a simple Webkit-based browser in 4.1 could be a nice solution. This could follow the Dolphin philosophy: a simpler alternative to the web browser functions in Konqueror. Konqueror (KHTML-based) would still be around for power users, and both would compete for user’s hearts.”

    It is a naive suggestion: it’s *exactly* the power users who will want a fully integrated solution like Konqueror to have a Webkit-based browser kpart. I *hate* the fact that KDE seems to be tending towards watered-down separate applications for file management & web browsing, rather than effort being put in to making Konqueror’s integration that much more seemless. Konqueror is an absolutely fantastic tool, and it’s depressing to think that it’s gradually getting more and more marginalised and ignored both by KDE developers and users. Making users use a different application for web browsing when the technology required to make Konqueror Just Work on almost any website is *already there* is abject foolishness.

  11. You wrote;
    > However, he also does not address the real reason or problem why both
    > projects simply do not work together. The question remains what the most
    > blocking reasons are.

    I think you missed the most “spot-on” sentence, then :)
    Zack wrote:
    > we [webkit] would love to work with you, the fork, but you’re kind of a
    > pain in the butt to deal with.
    :-)

  12. Throwing away Konqueror would not just be a pity, it goes against everything that KDE has been working for for years. I think we should be looking in the direction of creating kparts for more things. You could run an operating system from kparts, and I don’t think that’s such a bad idea. Dolphin can be used inside Konqueror, so if we keep giving it love, it will still be the best file browser and web browser for linux well into the kde 4 series.

    As for web browsing, we should keep the fantastic konqueror base. If webkit is better than khtml, we will use webkit, but still from within konqueror. In fact, I never understood why qt-gecko never took off, there was nothing wrong with the idea.

  13. That Browser of Momesana looks interesting. Could you give me his email-address, because i always had in mind to build a QtWebkit based browser, maybe we could join forces…
    Thanks!

  14. KDE ( E.V ) & Apple Should Meet & Help Form A Foundation Much Like The KDE Free QT Foundation. It Would Have The Same Approach ( 2 From Apple, 2 From KDE ) & Would Have Total Control ( Apart From The Mac OS X Parts ) Over Webkit ( KHTML ). This Would Put EVERYONE On An Even Keel, It Doesn’t Matter If You Are A Nokia, Adobe, Gnome, KDE Or Apple Developer You Will Have As Much Commit Rights As The Next Person ( Provided You Have Proved That You’re Coding Is Good Enough ). KDE Can Always Re-Fork It Again Anyway.

  15. I reply on an ancient blog.:

    >As for web browsing, we should keep the fantastic konqueror base.
    >If webkit is better than khtml, we will use webkit, but still from within
    >konqueror. In fact, I never understood why qt-gecko
    >never took off, there was nothing wrong with the idea.
    Nit Invented Here attitude and spite.
    It’s the same reason people are rejecting WebKit now. It’s free software.
    It’s as much mine a yours, as Apple’s, but since it was forked and IMPROVED(yes, improved. A 100% on the Acid Test is an improvement over 70%) it’s being treated as a foreign entity.
    So now Amarok with display web pages more accurately than Konqueror.
    That’s also why people are still trying to trudge their way through ALSA despite OSS being back under the GPL. It supports more mixing options than ALSA, it’s smaller, faster, and has more complete hardware support, AND it works with ALSA-only apps!
    Why isn’t it in the kernel tree? Spite.

    You could re-fork Webkit and rename it. here’s an idea for the new name: KHTML.

  16. I don’t understand why apple just took khtml source and developed it in secret releasing massive and badly documented patches to khtml dev-team, and then just released “web-kit” why couldn’t they have developed with khtml developers when web-kit was in development rather than exclude them??? This is such stupid stupid open-source practice and apple are directly to blame. They use open-source so much yet they don’t know squat on how projects should be developed… you cannot expect a good relationship between projects when you do this….. Stupid Apple inc. no wonder opendarwin died.

    To GZeus: why would people not use oss you say? look in your answer… It is now “BACK” under gpl…. why trust something that is gpl one minute and not the next? Now that is not because of spite, it’s just plain dumb common sence.

Comments are closed.