Announcement

Collapse
No announcement yet.

Rekonq as the default browser of Kubuntu 10.10

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Rekonq as the default browser of Kubuntu 10.10

    I don't see any benefits of having Rekonq be the default browser. Here's why.

    1. Using Konqueror with the webkit backend has, from what I can tell, the same effect as using Rekonq. They render all pages in exactly the same way, including those they don't render properly (e.g. google calendar which gives the error "Sorry, calendar is temporarily unavailable..."). But those that don't render properly usually render fine using the KHTML backend of Konqueror. (Kpart-webkit used to be buggy but I haven't encountered any bugginess in Meerkat.)

    2. Rekonq has some bizarre way of embedding files (e.g. pdfs in Okular) such that the toolbars of the embedded parts don't integrate with Rekonq. As a result none of the functions of the embedded application are available. This doesn't happen with Konqueror.

    3. Rekonq doesn't inherit certain global appearance properties. E.g. change your color scheme to Obsidian Coast and witness the Oxygen-colored scrollbar of Rekonq (yes, even upon restart).

    4. No information on tab mouseover in Rekonq plus small fixed tab width can make it unusuable. The little thumbnail on hover doesn't help. In Konqueror the full url is exposed on mouseover.

    The list could go on.

    I think Rekonq's a good browser but if there's any need to replace Konqueror due to certain inadequacies then Rekonq is an extremely poor solution. Something like Firefox or Chrome would do a better job. Of course neither of these are genuine KDE/Qt apps, so working on e.g. Chrome/KDE-integration could be a good idea. I hope sooner than later that Rekonq does become a suitable replacement but for now I have to wonder why it was ever included by default.

    #2
    Re: Rekonq as the default browser of Kubuntu 10.10

    Originally posted by molecule-eye
    I don't see any benefits of having Rekonq be the default browser. Here's why.

    1. Using Konqueror with the webkit backend has, from what I can tell, the same effect as using Rekonq. They render all pages in exactly the same way, including those they don't render properly (e.g. google calendar which gives the error "Sorry, calendar is temporarily unavailable..."). But those that don't render properly usually render fine using the KHTML backend of Konqueror. (Kpart-webkit used to be buggy but I haven't encountered any bugginess in Meerkat.)
    Except that the majority of the settings in Konqueror's config dialog are KHTML-specific, and entirely do not work with WebKit. While the KPart works fine in Konqueror, having half of the settings in the config dialog stop doing anything isn't really something we can do...

    2. Rekonq has some bizarre way of embedding files (e.g. pdfs in Okular) such that the toolbars of the embedded parts don't integrate with Rekonq. As a result none of the functions of the embedded application are available. This doesn't happen with Konqueror.
    This is something that does need improving, yes, but the rendering improvements are worth this temporary setback.

    3. Rekonq doesn't inherit certain global appearance properties. E.g. change your color scheme to Obsidian Coast and witness the Oxygen-colored scrollbar of Rekonq (yes, even upon restart).
    Works for me (tm). If you were talking about scrollbars inside the HTML, this would be a QtWebKit limitation, and would happen with Konq + WebKit KPart.

    4. No information on tab mouseover in Rekonq plus small fixed tab width can make it unusuable. The little thumbnail on hover doesn't help. In Konqueror the full url is exposed on mouseover.
    This would be an easy fix. Filing a wishlist request in the KDE bugtracker instead of complaining in a forum would be more effective. (Chrome or Firefox don't do this either, for the record)

    The list could go on.

    I think Rekonq's a good browser but if there's any need to replace Konqueror due to certain inadequacies then Rekonq is an extremely poor solution. Something like Firefox or Chrome would do a better job. Of course neither of these are genuine KDE/Qt apps, so working on e.g. Chrome/KDE-integration could be a good idea. I hope sooner than later that Rekonq does become a suitable replacement but for now I have to wonder why it was ever included by default.
    It was included by default because it was the only tenable way to have both WebKit and KDE integration. Firefox cannot be included on the CD due to the size constraints the non-KDE dependencies that it would bring in. We do still provide the firefox installer, so it is still quite trivial to get Firefox with the current KDE integration already. Chrome is unsuitable for several reasons for being the default. (Though it is my favorite browser.) It contains many code copies as well as an unsuitable security release cycle which makes it unlikely to ever be default in either Ubuntu or Kubuntu.

    Rekonq is really the only way we can bring WebKit to KDE at this time.

    Comment


      #3
      Re: Rekonq as the default browser of Kubuntu 10.10

      Except that the majority of the settings in Konqueror's config dialog are KHTML-specific, and entirely do not work with WebKit. While the KPart works fine in Konqueror, having half of the settings in the config dialog stop doing anything isn't really something we can do...
      I had never thought about that. It would be nice if the kpart-webkit team (or relevant party, whoever that may be) worked on a way of adjusting those settings via a GUI so that they would apply globally to any application using kpart-webkit.

      2. Rekonq has some bizarre way of embedding files (e.g. pdfs in Okular) such that the toolbars of the embedded parts don't integrate with Rekonq. As a result none of the functions of the embedded application are available. This doesn't happen with Konqueror.
      This is something that does need improving, yes, but the rendering improvements are worth this temporary setback.
      The rendering improvements are available in Konqueror using the webkit backend, so I don't see that as much of an argument to use Rekonq.

      3. Rekonq doesn't inherit certain global appearance properties. E.g. change your color scheme to Obsidian Coast and witness the Oxygen-colored scrollbar of Rekonq (yes, even upon restart).
      Works for me (tm). If you were talking about scrollbars inside the HTML, this would be a QtWebKit limitation, and would happen with Konq + WebKit KPart.
      I'm talking about the main toolbar, not the ones inside HTML. I wonder, then, if it's a packaging issue or specific to my install.

      This would be an easy fix. Filing a wishlist request in the KDE bugtracker instead of complaining in a forum would be more effective. (Chrome or Firefox don't do this either, for the record)
      Why assume I've not yet done that? Filing a wish and "complaining" on a forum are not exclusive activities.

      It was included by default because it was the only tenable way to have both WebKit and KDE integration.
      Again, I don't get why using kpart-webkit as default with Konqueror is not an option. The only good reason you gave was the first one (re KHTML-specific settings) and it's not even that good a reason.

      Comment


        #4
        Re: Rekonq as the default browser of Kubuntu 10.10

        Originally posted by molecule-eye

        2. Rekonq has some bizarre way of embedding files (e.g. pdfs in Okular) such that the toolbars of the embedded parts don't integrate with Rekonq. As a result none of the functions of the embedded application are available. This doesn't happen with Konqueror.
        This is something that does need improving, yes, but the rendering improvements are worth this temporary setback.
        The rendering improvements are available in Konqueror using the webkit backend, so I don't see that as much of an argument to use Rekonq.
        Yes, but not without another set of more significant issues.

        This would be an easy fix. Filing a wishlist request in the KDE bugtracker instead of complaining in a forum would be more effective. (Chrome or Firefox don't do this either, for the record)
        Why assume I've not yet done that? Filing a wish and "complaining" on a forum are not exclusive activities.
        Because it's hardly relevant to mention aside from a wishlist request, seeing as your other two suggestions don't implement it anyways. It's certainly not big enough of an issue to use to second-guess the decision to make rekonq default, so I assumed that you were mentioning it here because you a) Wanted to get the idea out and b) hadn't done so elsewhere making a) necessary here.

        It was included by default because it was the only tenable way to have both WebKit and KDE integration.
        Again, I don't get why using kpart-webkit as default with Konqueror is not an option. The only good reason you gave was the first one (re KHTML-specific settings) and it's not even that good a reason.
        [/quote]

        Having a half-broken configuration dialog isn't a good enough reason? :s
        The average user would think the entire application was broken, which is much worse than a few nice features that rekonq does not have (yet). Conversely, the only reason that you give that really holds up is the lack of embedding, and since correctly rendering web pages is the primary task of a web browser, it is more important than KPart embedding.

        Comment


          #5
          Re: Rekonq as the default browser of Kubuntu 10.10

          Maybe I should ask, then, why it was so important to have a webkit browser be default in Meerkat. For one, people are going to run into more rendering problems (at least this is my experience) with Rekonq than with Konqueror and KHTML, even if the latter is much slower at rendering pages. Being able to view a page correctly at all is more important than loading it incorrectly quickly or not loading it at all. (And if it doesn't load correctly with KHTML than that's what kpart-webkit's for.)

          Rekonq just doesn't feel mature enough to be included as the default browser for Kubuntu, and it's hard to see any good reason for including it as the default *now*. It might make more sense down the line (and I hope it does), but that's another matter.

          Comment


            #6
            Re: Rekonq as the default browser of Kubuntu 10.10

            KHTML has more rendering issues than WebKit, which is why the switch was done in the first place. As it stands, KHTML has lackluster support for popular websites such as GMail, EBay and Slashdot.

            Comment


              #7
              Re: Rekonq as the default browser of Kubuntu 10.10

              Rekonq can search from the address bar. konqueror doesnt (not without some serious tweaking from the default, anyway)

              But I prefer Chrome over anything else

              Comment

              Working...
              X