Again and again

June 30, 2009

Disclaimer: The content of this blog post expresses only the position of its author, and not the position of anybody else (esp. not the position of any project that the author is involved in). If you do not understand that, stop reading now, please. Thanks.

The discussion about KHTML vs. Webkit does not end, with Will Stephenson proposing to make “a widely used web engine that works” (which means Webkit most probably) the default in Konqueror.

Webkit integration has been discussed throughout the KDE community at least since when Qt 4.4 brought built-in Webkit support in early 2008. Yet nothing has happened. Apparently, nobody really felt the urge to scratch an itch on Konqueror’s Webkit integration (apart from the rudimentary Webkitpart in playground). Okay, there is Rekonq, but I see little added value in shipping a separate browser together with Konqueror. The partial disintegration of Konqueror’s file management into Dolphin is logical, because a file manager needs a whole different interface than a web browser, but I find it pointless to split a web browser off the web browser Konqueror. And not shipping Konqueror with the kdebase package is not an option, either. Konqueror just belongs to KDE as Nautilus belongs to Gnome, or Safari to Mac OS.

So let’s have a more detailed look at what people don’t like about Konqueror. A commenter on Will’s blog agreed to him, saying:

Every time I [try Konqueror] I remember the cool features it has but every time I find myself slipping back to firefox because it is just easier. The web just works.

Curiously, for me, it’s the other way around: Every time I try Firefox I remember the cool features it has but everytime I find myself slipping back to Konqueror because it is just easier. The web just works. Okay, I’m not using funky bling-bling Ajax sites that much, but my WordPress editor works since KDE 4.1. For example: Firefox needs 10 seconds for a cold start (even with all plugins deactivated), while Konqueror is ready for my input when I release the Enter button. And even more curiously, the Flash player Just Works™ in Konqueror, with Firefox not finding it sometimes (although it is correctly installed in /usr/lib/browser-plugins).

Please do not misunderstand this as a rant against Firefox. Firefox has achieved very much for F/OSS in general, and all of my issues with Firefox could have to do with misconfiguration. I just want to fight against the common misconception that Konqueror is a piece of crap. Of course, I do not accuse anyone of having said that, but I feel a general mood of disregard against Konqueror.

I just do not see anything in Konqueror that is broken by design. There are just many areas where Konqueror can certainly improve:

  • Will means that we should move bookmarks more into the focus of our integration concerns. At least, that is what I read from “Firefox bookmarks are separate and completely ignored by all KDE’s cool semantic technologies like Nepomuk. They could be indexed, sure, but since we’re the integrated Free Desktop environment, why do lists of bookmarks have to be glued to the app they came from?”

    This is actually a great idea, and incidentally, KDE developers are working on something like that right now: GSoC student Eduardo Robles Elvira is creating a new Nepomuk-based and Akonadi-powered bookmarking framework for Konqueror (together with a new location bar similar to the Awesomebar). These bookmarks could easily be displayed in a separate application. Also, a discussion is taking place on the kde-devel mailing list on connecting Nepomuk to Gnome’s Zeitgeist, which I expect, sooner or later, to be utilised by Firefox.

  • Another interesting question is the integration of scripted extensions in Konqueror. We have working solutions e.g. in Plasma (where applets are basically plugin libraries), but I’m quite sure that the internal APIs of Konqueror would have to be cleaned up beforehand (because it’s much harder to change them when extension writers are already using them).
  • Konqueror could use some interface cleanup (e.g. the settings dialog). Also, I think that we took it too far with the KParts. The KParts library is certainly a good technology, but we got just too many of them. The usage of KParts in Konqueror should be limited to those that really handle a specific file or directory or URL. That means, the dolphinpart, khtmlpart and okularpart can stay, while e.g. kjotspart and klinkstatuspart should not be displayed in Konqueror. After all, what is the point in having an application load inside Konqueror instead of in a separate window if it has nothing at all to do with Konqueror? Klinkstatuspart for example does not even do something with the URL I give to it via the address bar, it brings its own URL entry field. Some service menu cleanup is also desirable, there is no point in each and every context menu offering a checkout with KDESVN, even for simple links.

Last but not least, there is the big question of which browser engine to use. I favor KHTML, because we ship it anyway (and because of binary interface compatibilty, we can’t simply remove it in some minor release, i.e. before KDE 5.0), because I personally like its convenience features (such as those “access keys” which you activate through the Ctrl button), and because its rendering currently looks prettier when compared to Webkit. (I don’t know what it is exactly, but the text feels warmer.) Actually, I’m quite confident that the KHTML team can keep up with web developments, even if they have fallen behind a bit these days. Okay, you’re right that I’m reading tea leaves here. One can never tell what future brings. The only thing I can tell you is that nothing is going to happen until we stop to beat about the bush and start working towards a better solution.


45 Responses to “Again and again”

  1. moroon Says:

    “And not shipping Konqueror with the kdebase package is not an option, either. Konqueror just belongs to KDE as Nautilus belongs to Gnome, or Safari to Mac OS.”

    The Gnome browser is Epiphany, not Nautilus (Nautilus is the file manager). And Epiphany once replaced Galeon. Why can’t Konqueror get replaced in KDE?

    • majewsky Says:

      Okay, I mixed up Nautilus and Epiphany. But that’s not the point. Konqueror is a basic building block of our “complete integration” strategy, providing direct access to previewers for nearly all file types. If we give up the concepts on which Konqueror is built, by introducing another web browser, we might lose a unique selling point of KDE.

  2. skarn Says:

    One of my personal motivations to use Konqueror is the excessive usage of the kparts technology. While it is true that most of them should be disabled by default, I love the possibility to configure my browser to view office documents directly, or calendars, or pretty much anything.

    The endless possibility offered by the amazing combo kio+kparts are why I feel Konqueror suits my need better than any other browser.

  3. mutlu Says:

    I don’t think anyone is trying to get rid of Konqueror. I think the problem is that the default KHTML KPart does not acceptably render a number of popular Web 2.0-sites, while Firefox does. Furthermore, it is assumed that WebKit does render these sites well. Thus, creating a well-working WebKit KPart and making it default in Konqueror is what I believe to be the demand of 99% of those who come nagging over and over.

    The problem, however, seems to be that – so far – the WebKit KPart does not work reliably. I agree that further development of this KPart would make KDE much more attractive as a platform. However, while many people complain, noone seems to invest enough time to get it into shape. In any case, I believe this should not be blamed on the KHTML developers (and, refreshingly, the past posts on the planet did not do this). Nonetheless, I hope that Konqueror (as the browser, not the engine) will pick up WebKit as an alternative to KHTML.

  4. JavierBere Says:

    The idea of providing WebKit support in Konqueror would allow people to choose the way they want things to work. Last time I checked, KDE is all about choice, so why restrict users way?

    I love the KHTML project, it’s great, it’s fast, but it just doesn’t work for the average user, because you said it yourself *you* don’t use AJAX heavy sites. Does that mean we shoould leave out any users who *do* use them?
    Because for the average user, that’s a showbreaker right there. The moment they see their sites don’t work they will stop using it in favor of something that does.
    Even gmail has to use the html version rather than it’s full fledged client. That on it’s own is enough for me to stop using konqueror altogether personally.

    I’m not saying KHTML should be stopped, I’m not even saying Konqueror shoould provide WebKit as default. I am saying however that it *should* provide the option to use it.

    • majewsky Says:

      I agree to you (and mutlu) that a good Webkit KPart certainly improves many things.

      Did anyone consider yet to integrate Webkit into the KHTML KPart, as a type of fallback for sites which KHTML does not render correctly (detection per blacklist or by features unknown to KHTML)?

      • JavierBere Says:

        If my C++ programming was in acceptable shape I’d definitely give that a shot myself, unfortunately my C++ skills are near inexistant. I’m a JAVA person :/

  5. Sometimes it feels like Konqueror devs live in the HTML3.2 time.
    I submitted a patch to implement bookmarklets in Konqueror, but it got rejected because allowing such a feature would be a security issue. Note that no specific problem was reported, the maintainer just did not like the idea I think. Too bad, it would have been one way to make Konqueror a bit more extensible. Nevermind that most browsers support bookmarklets.

    Konqueror has served us well, but for me it’s now a thing of the past. I think a webkit-based browser-only application is the way to go. Rekonq is promising but still too young. Arora works better but the lack of KDE integration is annoying. Still I find myself using Arora most of the times right now and will probably submit a patch to implement bookmarklet support when I get time.

    • James Spencer Says:

      Actually I followed your bookmarklet thread. That one issue has long kept my oldest friend from using Konqueror as a browser. I use Konqueror as my browser and it’s the little things like that and some web 2.0 ‘issues’ (though they have gotten better) that make it a rough sell. Works for me though.

  6. shamaz Says:

    You say :
    “The partial disintegration of Konqueror’s file management into Dolphin is logical, because a file manager needs a whole different interface than a web browser, but I find it pointless to split a web browser off the web browser Konqueror.”

    Bu one can answer :
    “The partial disintegration of Konqueror’s web browser into Rekonq is logical, because a web browser needs a whole different interface than a file manager, and I DON’t find it pointless to split a web browser off the file manager Konqueror.”

    And you didn’t read well what Will said : He did not talk about setting Webkit as the default HTML renderer in Konqueror.
    You seem to have taken his post as an attack against Konqueror ( “Konqueror is not in such a bad shape etc.” ) This is not what he said.

    I think having another kde web browser using a different rendering engine (or khtml optionnaly) would be very good.
    Competition is a good thing.

    Did Google created chrome because Firefox was in a bad shape ?
    No, because they wanted to do something different (proprietary, more stable, ‘google’ branded or whatever)

    People can have different visions, let’s respect that.

    • Tobias Klein Says:

      >Did Google created chrome because Firefox was in a bad shape ?
      >No, because they wanted to do something different (proprietary, more stable, >‘google’ branded or whatever)

      Google created Chrome, because they saw the need for a complete new software architecture regarding JS performance. Today’s web applications are very different from websites created 10 years ago. There are more and more websites which are developed as rich internet applications. And for those websites you definitely need a better javascript performance. Google just took Webkit plus a *very fast* own JS Engine (doing assembler based optimization at runtime!!) and the needed composite UI.

      • majewsky Says:

        You can never truly know the reasons for Google creating Chrome. But this is not important, as this is a totally different story. We are the manufacturers of Konqueror. A better equivalent would be Microsoft creating some new browser because the Internet Explorer is in a bad shape. Which it was some years ago, incidentally, and it is even today not on par with Konqueror when it comes to standards compliance. (Yes, I know the notable differences in market share between IE and Konq.)

      • T. J. Brumfield Says:

        I believe Adobe approached Firefox about giving Firefox some scripting code, and helped provide the basis for their new JS engine. Google could have easily helped develop a faster JS engine for Firefox.

        Chrome is more than a JS engine. Chrome is also about putting trust and security back into the browser. As Google moves further towards cloud apps, Google Gears, etc. people need to trust their browser again.

        Sandboxing and per-process models were the way to go.

        Part of what really interests me with Rekonq is the notion that they will follow a similar development path eventually with separate processes.

        You can kill a tab and properly reclaim that memory without having to kill your entire browser experience.

        One tab hanging on a network request, a bad JS, or a bad plugin won’t crash the whole browser.

        Frankly, I think the main Konqueror needs to take some cues from rekonq, if not directly fold the project in. Provide excellent Webkit integration, Kparts integration, the new bookmark system, Nepomuk and Akondi support, per-process design, and focus on speed.

        Dolphin was the rebirth of Konqui as a file manager. I think Rekonq could be the rebirth of Konqui as a browser.

  7. maninalift Says:

    KHTML doesn’t suck, Konqueror certainly doesn’t suck.

    I expect most people can a agree on a few points

    (1) Konq and KHTML at least do a lot of things well
    (2) The tech in KDE and Konq could potentially make a really great browser, one that draws users, and gets special mention in reviews of KDE
    (3) Currently, for whatever reason, a significant proportion, perhaps a majority of KDE users find KHTML/Konqueror does not meet their needs.

    Point 3 is bad for users as they find themselves without useful desktop-integration.

    Developers are well within their rights to say so what, I’m making a good browser that meets many people’s needs, if other people don’t want to use it, that’s up to them. But if you are interested in overall desktop environment design then the issue surely can’t be ignored.

    Not ignoring the point doesnt necesarily mean adopting WebKit, it just means finding out exactly what are the sticking points for users and whether and how those things can be addressed.

    If there was more certainty that Konq was going to overcome whatever are the issues holding it back from general user acceptance It would probably also attract for developer attention.

    On access key: is that not something that could be included in KWebKit and potentially sent upstream to webkit and/or Qt?

  8. Aru Says:

    I agree with the above poster that merely dismissing AJAXy sites as being bling and moving on is part of the mentality that has stopped Konq from moving further, imho.
    As a KDE user, I’d love full browser integration: god knows I’ve spent ages setting my themes and gtkrc files for a good blend with KDE, and constantly miss the native file and print dialogs. But, at the end of the day, Firefox just works. I haven’t had plugin issues or issues with themes.

    But, with Konq, it’s always been a series of headaches: for us dark color scheme users, getting input elements to be black on white instead of black on black, getting AJAX sites working, and tightening up the UI in general (why do I need Open With/Preview In/Actions context options whenever I right click a page?).

    Usability is key, and, whenever I use Konq I feel as if it has been designed to work around the browsing habits of a few power users, and not the general base. I’d love see some changes, and I’d love to be able to use it, but at this moment, Firefox just provides the better experience.

  9. bliblibli Says:

    “Okay, I’m not using funky bling-bling Ajax sites that much”

    Yeah Konqueror is fine if you visit sites like


    Even those simple geek sites don’t work well. They work fine with almost two years old (Qt4.4)Webkit >: (

    And all those little bugs like spawning hundreds of megabytes worth of kio_http and konqueror process that just wont die without killing if you close the browser with a couple of tabs open, locking up in opestreemap and google maps and so on…

    Nothing against KHTML/KJS really, but seriously they should at least start ripping stuff from Webkit a lot more (Every morally right to do that since Apple ripped you back in the days)! For example maintaining own “web 2.0 javascript engine” without getting paid is insane 😀 Why not to use Squirrel Fish Extreme? That actually works well and is fast.

    Buggy browser experience hurts KDE when other parts works now great/brilliantly.

    Last but not least…Webkit is KDE technology! It’s everywhere now! You all should be proud of it (especially KHTML/KJS devs) and embrace everywhere you can!

    P.S. Posted with Konqueror 4.2.90 🙂

  10. Pierluca Says:

    In my opinion the best solution (and probably very kde-ish) is to make konqueror rendering engine configurable: one should be able to use khtml or webkit or anything else that can render a web page.

    The default shipped will be chosen by distros but user should be able to select which engine suit their needs better.

  11. Birdy Says:

    Having a QtWebKit KPart would be nice. But I would much more like to see a slim webbrowser – have a look at chrome’s UI.
    Take konqueror’s settings dialog for example. There is much more in there than only webbrowsing.
    Or what about having a feature such as each tab rendered in an extra process (for security)? I doubt it will be in konqueror within this decade.
    Konqueror is a flexible but therefore complex “thing” – for users and developers.
    I much more favor a notably enhanced rekonq (stability, froms auto-fill, ad block, …).

    • majewsky Says:

      “what about having a feature such as each tab rendered in an extra process (for security)?”

      Incidentally, the developers are currently working on this feature, at least indirectly, through window tabbing in KWin.

  12. jwickers Says:

    Konqueror already has a lot to catch up in what Firefox extensions can provide, if you add up that popular websites does not and won’t support KHTML then it is pretty much dead for the majority. You cannot expect users to use it in parallel to Firefox just for a few websites.

    I also like(d) a lot Konqueror, the rendering is nice, its better integrated to KDE, it launches and feels faster .. but i just don’t bother using it.

    WebKit seems to make a lot more sense, as it is used in other products/devices. Maybe there could be a KDE survey, top 10 reasons why you use Konqueror / top 10 reasons why you don’t, and let the community vote.

  13. elmargol Says:

    Don’t you think maintaining KHTML (a complex piece of software) is a waste of time if you could just use Webkit and profit from the big companies Apple / Google who invest in this technology?

  14. foo Says:

    “Actually, I’m quite confident that the KHTML team can keep up with web developments, even if they have fallen behind a bit these days.”

    That makes no sense at all – you’re confident they can keep up, except that they haven’t been keeping up?

    Now I don’t mean to offend the KHTML developers – they are all brilliant. The reality of webkit being the more widely supported engine today should be acknowledged though – indeed, it is a direct descendant from KHTML.

  15. Faemir Says:

    “Actually, I’m quite confident that the KHTML team can keep up with web developments, even if they have fallen behind a bit these days.”

    These days? So what, ‘these days’ can count from back when I first used linux in the KDE 3.2 days until now?

    As much as I would rather use konqueror, there are plenty of sites that flat out don’t work, and I would rather have the slow and cumbersome firefox (which is not really that slow anymore in 3.5) that WORKS than a snappy browser that will not work or is dodgy on several websites that I browse very frequently.

    I’m not saying ditch KHTML, I’m saying that perhaps webkit should be offered as an alternative until KHTML can cope in the modern web world.

  16. tada Says:

    “I’m quite confident that the KHTML team can keep up with web developments, even if they have fallen behind a bit these days.”

    I keep trying to use konqueror, since I am a bit of a KDE-fanboy. You probably get a lot right, but from a user’s perspective it does not matter who gets it wrong.

    Several sites not displaying correctly is probably due to them not getting standards right. This does not matter to a user. It makes me switch away from konqueror if the no1 news site in the Netherlands is mangled ( or if I cannot log in to one of the biggest online games (volvooceanrace).

    Redirecting the efforts towards WebKit will help a larger userbase and will eradicate the problems of websites and applications not working properly.

  17. Cypher Says:

    I find Konqueror too heavy for my needs. I need a web browser, not a swiss army knife. But other users like Konqueror for this reason.

    In my opinion, it would be good to have a dedicated web browser as default, and to keep Konqueror with all the loadable KParts as well. Konqueror can load a Dolphin KPart, why couldn’t it load a Rekonq KPart ? I like the principle of “do only one thing, but do it well”.

    Regarding WebKit… well, I like standards, so I would go for WebKit just to make it a de facto standard. I think we do not need another rendering engine. But I’m still waiting for a good proxy support and remote DNS queries through proxies. This is a need for my business, as we need to go through SSH tunnels to reach the intranet.

    • majewsky Says:

      Actually, Konqueror is light-weight because of the KParts. It starts much faster than any other web browser on my system (including Opera, so the libraries-are-already-loaded argument does not count).

      “In my opinion, it would be good to have a dedicated web browser as default, and to keep Konqueror with all the loadable KParts as well. Konqueror can load a Dolphin KPart, why couldn’t it load a Rekonq KPart?”

      The reason why I’m skeptical regarding this plan, is that Konqueror is designed to be a web browser with file management capabilites, not a file manager with web browsing capabilities. This should become clear when you look at its interface.

  18. Enrico Ros Says:

    I love everybody being polite here, this eventually will lead to another “Again and again” post next year, the main difference will be that in the meantime we will loose half our users..

    How can a KDE User like KHTML, if even some Developers admit that “they have to use other browsers” ?

    Fixing KHTML will be a never-ending story, Firefox is there, WebKit is here.

    If only there was a Poll, i’ll vote for:
    – QtWebKit as the default web engine (so users will find Konqueror ‘normal’)
    – making KHTML optional
    – deprecating KHTML for KDE 5, in favor of KdeWebKit

    • Narishma Says:

      The problem here is that a lot of people whine but no one seems to be interested in doing the work necessary to integrate webkit in konqueror.

      As always with KDE, those who code decide, so if you want things to change you should contribute.

  19. Divan Santana Says:

    Hi Stefan,

    I’d like to comment on your blog.

    I thought the original blog regarding Konqueror was very correct.

    The reason is simple you need Firefox installed on KDE to browse the web basically. I love konqueror and prefer it however every now and then I need to switch to firefox for so many websites. So its quite a pain. Agree firefox takes a while to start and I prefer the KDE intergration hence we either need to switch to webkit because it gets more developer attention or improve konqueror.

    How can we give a user kubuntu out of the box and then tell them they need to install firefox and set it as default so they can do some very NB things such as internet banking?

    I know it might be the people who wrote the website thats at fault however Firefox renders these websites fine.

    I for instance can’t login to my internet banking ( as well as struggle with many essential other sites.

    I’m all for khtml however KDE needs a web browser that “just works” more than one that is very advanced but can’t render many websites when thats its core function.

  20. You know what is the problem? You are entitled to your own opinion on the KHTML/WebKit issue (personally I prefer KHTML, not tied to master of lock-in Apple, but that’s not the point here): the problem is *nothing* will change until people *stop* complaining *and start coding*. How many times has this surfaced?

    If that is the issue in the community why doesn’t reKonq gain momentum? Why the webkit-kde kpart has few contributors?

    If you want an alternative, be either help KHTML, or switch to webkit-based solutions, actual contributions are needed.

    Note: this isn’t an attack on the blog author, more a remark on many of the comments here.

    • majewsky Says:

      I would really like to start helping, but I’m involved in too much projects already (both KDE and real life). However, I have some ideas which I’m going to discuss with the KHTML devs later this evening.

  21. Kombat Says:

    I really really like konqueror’s integration. It feels just right in KDE but lately the sequence I find myself using the most is File->Open with Firefox Web browser..
    Facebook wont work, gmail wont work, yahoo wont work, on-line banking wont work, Google reader has crazy keyboard shortcuts, Google suggestions will scroll always 2 times….

    Once again, kudos to the konqueror devs. I use konqueror 80% of the time and absolutely love the ctrl shortcuts, speed, nice text rendering, flash videos starting when I focus the tab, window spiting, pdfs-in-window…etc… but unless _my_remaining 20% is satisfied i will end up using other browsers..

  22. mutlu Says:

    I just wanted to add that I am very happy that the discussion has been so peaceful and reasonable this time. Too often it ended with developers and users of different fractions missquoting and insulting one another. It is obviously an important topic and many have an opinion on it.

    Big kudos to you, Stefan, for being so calm, admitting shortcomings and even taking the initiative (“I have some ideas which I’m going to discuss with the KHTML devs later this evening”) even though all that happened so far is that people were complaining without helping out themselves.

  23. kaismh Says:

    Since this keep coming, it indicate that it is a real issue, which needs to be tackled. Many people use computers only to use the web. Although, many exciting things are happening with KDE desktop experience, it can be irrelevant to many if there is no good web browsing experience. Can Konqueror improve and become the browser? Yes, but the KDE community needs to be doing things differently with Konqueror. I wrote at the KDE forums earlier about Giving Wings to Konqueror!!!

    I believe it is not always about technology, we need to market Konqueror, make small static builds for all the OS. Create a brand out of it. Spread it around and become passionate about it. There is room for another major browser out there. And that can be Konqueror

  24. anon Says:

    The only really annoying thing about QtWebkit is that if KDE were to use it, we would lose the native widgets – in particular, KDE’s awesome input field with its KDE-integrated spell-checking, etc. Native widgets doesn’t seem to be on WebKit’s roadmap, and even if it were I strongly doubt that QtWebkit would offer the hooks needed to splice in the KDE ones. Its upcoming DOM also looks like it will be quite weak in comparison.

    It would be a shame to sacrifice these features, but yes: it’s becoming increasingly obvious that, brilliant though they are, the KHTML devs simply don’t have the resources to keep up, and that KHTML should probably be removed when or if KDE5 rolls around.

    Perhaps the KDEWebkitPart authors could give us a list of outstanding tasks that need to be accomplished for it to be a replacement for KHTML?

  25. val-gaav Says:

    Well I use Konqueror from the time of KDE 3.2 to ditch it with upgrade to KDE 4.2 very recently.

    I always had to have FF for ‘some’ pages but in the era of KDE3 using Konqui made more sense since it was also File Manager (the only one and the default one). With KDE4 we got Dolphin which I was sceptic about at first but came to love it after a bit of using it… So now I didn’t use Konqui for file managment, so what was the point in keeping a browser that works sometimes and you still need to have another one around ?

    I spent hours or even days of time at looking up how to integrate the damn firefox into KDE and now I’m using KGTK to have native file dialogs, couple of addons, a custom theme, and a little CSS hack to turn off Gnome HIG things like Cancel|OK scheme…

    It works and doesn’t feel alien, well at least it doesn’t feel like GTK+ app at all…… The only way to make me turn back and use Konqueor or any webkit browser is if it has something FF doesn’t have.

    The point here is though while I had the time to compile kgtk , look for hacks and configure the damn fox normal users will not… that hurts KDE and its adoption

    • skierpage Says:

      Hey val-gaav,

      Please could you could update the wiki with what you did to better integrate Firefox. Currently, “General KDE Problems” and “General_KDE_FAQs” have separate sections for integrating FF, each pointing to a *different* broken link. 😦 Thanks.

      I remarked on George Wright (gw280)’s post on this topic:
      “As a Linux n00b, I notice that the rest of KDE/Kubuntu looks and works slightly differently than my browser [Firefox 3.6prealpha 64-bit], but I live in the browser (plus a terminal), so I don’t really care. KDE is just a nice panel strip and Kickoff menu below my browser windows ;-). (And someday, the promise of Nepomuk/Strigi/whatever, should Kubuntu ever deign to turn it on and explain it to me.)”

      If Firefox integrates substantially better with other Linux desktops, the millions of FF users who might migrate to Linux will choose them over KDE. Not the end of the world for KDE devs’ awesome efforts, but it’s something to consider.

  26. KenP Says:

    I have a suggestion: How about analyzing statistics of kde websites to see if Konqueror is popular enough, particularly sites like the new community forums etc where average users are more likely to navigate to.

    Some of the reponses above indicate that KDE seems to be becoming a dev-only desktop environment. For all its flaws (and I don’t use it at all), GNOME seems to have got three things right: End-uses, end-users and end-users.

    To all KDE-devs: With KDE4, we have a fantastic chance to raise the level of desktop experience. Konqueror either needs to catch up or be replaced. With KDE4 as a whole talking of social desktop etc how can Konq keep ignoring Web 2.0?

  27. Andrew Says:

    There seems to be a lot of role confusion in this whole debate:

    1. Users seem to think they know what software backend the developers should use. Objectively this is not based on an understanding of the code but on experience with different applications. They are extrapolating their knowledge and thereby not effectively making what would be a very valuable contribution.

    2. Developers seem to think that the code, its structure, the beauty of its API, etc are things the average user cares about. They sometimes see the wrapping of that code into an application as being an afterthought – more trivial in some way, and perhaps able to be handled by a worthy user.

    Both these views are fundamentally flawed. And not addressing this flaw will see this kind of debate just drag on. Start listening to each other guys. *Listening* – not extrapolating or extending your own world view or experience onto others.

    Developers: please explain to users why they should be interested in the work being done in khtml – explain the “vision” (please limit “integration” arguments as these are often circular). Please focus on compatability, function, efficiency, security, usability. Please acknowledge any limitations; explain what is planned to address those limitations; both in the short and long term. In this context, listen to users and be prepared to make short term compromises. A user base is a valuable thing.

    Users: please explain to developers what matters to you in terms of compatability, function, efficiency, security, usability. Please do not tell developers what code they should use. But *do* keep them honest and report significant issues you experience in a useful way. Ask for answers to hard questions and for *good* reasons behind design and development decisions. If all you want is firefox with a KDE look and file browser then I think there is already a solution for that. Speak to your distro packager.

    To be honest, what disturbs me is that a suggestion like this one that could potentially provide a lot of user feedback to developers has met with complete apathy. Perhaps konqueror, and with it khtml, now only attracts comment from disaffected ex-users?

  28. […] Again and again Disclaimer: The content of this blog post expresses only the position of its author, and not the position of anybody […] […]

  29. Tim Says:

    OK, I have heard these arguments before and I don’t accept them anymore.

    There is no denying that KHTML is lacking and with Apple, Google, Mozilla and MS against you it will only get worse.

    Here is why:
    The browser is becoming a application platform and if you don’t have the user base your engine will not be supported because every complex web app is buggy and only works in tested browsers.

    You guys and the few konq users need to accept that. Once you have you will see that you contribution isn’t really helping KDE.

    It is hurting KDE. Yeah, you heard that right. You guys are giving people the illusion that things might get better, but they aren’t. And for social reasons you keep people from working on other stuff.

    So please just stop and thereby increase the pressure for a working solution. You guys don’t have one and_it_is_hurting_KDE.

  30. LXj Says:

    I’ve posted a link to Aaron’s Plasma screencast in my blog, and one of the first comments was “Oh look, Aaron is actually using Firefox”

    Yeah, that sums the situation up

  31. Vladimir Says:

    I personally prefer to use Konqueror for many sites, because it starts quicker, fonts look better and it’s much better integrated into my DE (guess which one) 😉

    However, I still have to fire up Firefox, because I’m Gmail user and I’m a member of a social network (it’s webpages look look similar to’s ones), and they simply don’t work in Konqueror (google works, in fact, but in very plain UI mode. vkontakte doesn’t work at all, because there is no alternative no-Ajax UI) .

    No, there’s the question: once I started Firefox and already waited all that long seconds it takes to start, what’s the reason for me to keep Konqueror opened concurrently?

    And I’m definitely not going to”pick a site which works in my browser”. Browser is a tool, while site is something more (it’s information, services, people community).

    So guys, please, please make Konqueror working with the modern sites! It is THE MOST significant stopper against using it! Could it be WebKit part or improved KHTML — it doesn’t matter for an end user.

  32. Michael "KHTML" Howell Says:

    disclaimer: I have contributed to both WebKitPart and KHTML.

    WebKitPart cannot work. There are technical, and almost insurmountable, obstacles between WebKit and KParts. Konqueror and WebKit both keep track of browsing history, for example. This leaves the only other option: improve KHTML. Merging part-by-part with WebKit would allow us to use both WebKit and KHTML (oh yea, and don’t forget to have appleWebKit somewhere in the UA. Probably next to Gecko).

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s