Announcement

Collapse
No announcement yet.

KDE's Rekonq Browser Nears 1.0 w/ New Features

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Sometimes it is good to have got a very simple browser without popup blocking and such things, even konqueror can be used for that. Some routers only work with popup windows which are blocked by default by firefox/chrome so it could be useful to have got a simple way to check it. But basically thats the only usecase where i use another browser. It does not really matter how much a browser is integrated into a desktop envronment. It has to work and should be fast. In most cases i only use chrome.

    Comment


    • #12
      Originally posted by Kano View Post
      It does not really matter how much a browser is integrated into a desktop envronment. It has to work and should be fast.
      I disagree. Integrating into the desktop environment provides a lot of benefits. There are basic things like only needing a single password store and having your download progress be tracked the same way as any other file transfer, as well as more advanced things like embedding your native document viewer, integrating your bookmarks with your desktop, and having tabs integrated with the window manager.

      Comment


      • #13
        Originally posted by Kano View Post
        It has to work and should be fast.
        QtWebKit browsers like QupZilla and rekonq are quite fast and they will only get faster with the release of Qt 5 as it will be based on V8 javascript engine (also used by Chrome) and WebKit 2 (used by Safari). Due to shared libaries rekonq also uses less memory and starts faster on KDE than other browsers. Not to mention all the features that TheBlackCat listed.

        Comment


        • #14
          Originally posted by Teho View Post
          QtWebKit browsers like QupZilla and rekonq are quite fast and they will only get faster with the release of Qt 5 as it will be based on V8 javascript engine (also used by Chrome) and WebKit 2 (used by Safari).
          The browsers have to be ported to WebKit2-Qt first.

          Comment


          • #15
            Originally posted by Awesomeness View Post
            The browsers have to be ported to WebKit2-Qt first.
            Sure but that's already planned at least for rekonq.

            Comment


            • #16
              Originally posted by Teho View Post
              Sure but that's already planned at least for rekonq.
              Support for Chrome extensions is planned since when? Two years or so? And that feature has semi-working code already. However, the Rekonq author (or his employer Blue Systems, not sure) found crap like sync support more important.
              Qt5 will have WebKit1 as well and until I see a port to WebKit2, I do not believe in it.

              Comment


              • #17
                Whether you like rekonq or not, any desktop environment these days has to inculde a web browser in their distribution. If only to let you download Firefox/Chrome/whatever. Making that default browser as good as possible, does not seem like a bad idea, no matter how you look at it.

                Comment


                • #18
                  Originally posted by Awesomeness View Post
                  Support for Chrome extensions is planned since when? Two years or so? And that feature has semi-working code already. However, the Rekonq author (or his employer Blue Systems, not sure) found crap like sync support more important.
                  Qt5 will have WebKit1 as well and until I see a port to WebKit2, I do not believe in it.
                  Have you though that maybe implemented Chrome extensions isn't exactly trivial (like that there's a reason why no one has done that)? Why in the hell would browser use depracated API when newer is available essentially loosing all new features and improvements by doing so? Sure it might not happen righ away but it's obvious top priority. It will take some time before KDE will move to Qt 5 though. Also he is only sponsored to work on rekonq by Blue Systems and it's definetly not his fulltime job.

                  Comment


                  • #19
                    Originally posted by Teho View Post
                    Have you though that maybe implemented Chrome extensions isn't exactly trivial (like that there's a reason why no one has done that)?
                    Most work has already been done (by someone else, btw).
                    While Sync support in browsers is currently the thing to do, I've never met anyone who actually used it. OTOH it's quite hard to find a Firefox/Chrome user who's not using at least one extension these days.

                    If I was head of Blue Systems, I had put my money to pay for rather complete extension support. And if I was paying already anyway, I had extended the contract to cover Mozilla JetPack API extensions as well.

                    Originally posted by Teho View Post
                    Why in the hell would browser use depracated API when newer is available essentially loosing all new features and improvements by doing so?
                    Same reason you gave for not supporting Chrome extensions: It's easier. Rekonq uses WebKit1 now and when moving to Qt5, using the WebKit1 API instead of the WebKit2 one is pretty trivial.

                    Comment


                    • #20
                      Originally posted by Awesomeness View Post
                      Same reason you gave for not supporting Chrome extensions: It's easier. Rekonq uses WebKit1 now and when moving to Qt5, using the WebKit1 API instead of the WebKit2 one is pretty trivial.
                      QtWebKit is there only to ease up the transition. WebKit is the most important part of browser and obviouly having up to date version is top priority. Extensions are optional altough very important.

                      Originally posted by Awesomeness View Post
                      Most work has already been done (by someone else, btw).
                      Only thing I can find is source code from year 2010. Altough I remember hearing that somebody might work on it there isn't any such code in rekonq repository.

                      Comment

                      Working...
                      X