Announcement

Collapse
No announcement yet.

Qt 5.6 Drops WebKit, Qt QML Uses Less Memory & Other Forthcoming Features

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

  • Qt 5.6 Drops WebKit, Qt QML Uses Less Memory & Other Forthcoming Features

    Phoronix: Qt 5.6 Drops WebKit, Qt QML Uses Less Memory & Other Forthcoming Features

    With the Qt 5.6 beta planned for this week ahead of the planned Qt 5.6.0 official release before the end of the year, and being well past the feature freeze, here's a look at some of the features coming to Qt 5.6...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    glad that webkit is being dropped, a lot of projects(otter, qupzilla, qutebrowser, etc) still use it as a default despite it having a ton of bugs/performance issues so hopefully they'll be forced to upgrade to webengine.

    Comment


    • #3
      Originally posted by peppercats View Post
      glad that webkit is being dropped, a lot of projects(otter, qupzilla, qutebrowser, etc) still use it as a default despite it having a ton of bugs/performance issues so hopefully they'll be forced to upgrade to webengine.
      qutebrowser developer here, and I had to sign up just to answer to this.

      It's not like we are too lazy or whatever to switch to QtWebEngine. Hell, it's not like you'd need to force us to switch. I personally would've liked to use QtWebEngine since the beginning - when I started 2 years ago, I even considered waiting until QtWebEngine is released and usable (I'm glad I didn't - I'd still be waiting).

      Otter and QupZilla already have a work-in-progress QtWebEngine backend, I'm working hard on writing more tests so I can maintain both backends for the time being.

      The problem is that QtWebEngine still is kind of a joke for anything beyond using HTML/CSS to do some presentation kiosk or whatever. This is slowly getting better (especially with 5.6), but it's still a pain. Some examples:
      • Until 5.5: Controlling storage paths/policies for cache, cookies etc. isn't possible.
      • Until 5.5: Downloading files isn't possible
      • Until 5.5: Setting any settings isn't possible
      • Until 5.6: Form input in Otter won't work with QtWebEngine because of a QtWebEngine bug
      • Until 5.6: Scrollbars are painted red in QtWebEngine with Otter because - you guessed it - a QtWebEngine bug
      • Until 5.6: Adblocking is impossible
      • Until 5.6: custom HTTP headers are impossible (think selective Referer blocking, Do-Not-Track, etc.)
      • Until 5.6: Flash doesn't work (arguably less important than it used to be, but some users still need it)
      • Until 5.6: Custom URL schemes for browser-internal pages are not possible
      • Until 5.6: Setting proxies isn't really possible
      • Until 5.7: Getting the scroll position isn't possible.
      • Even after 5.6 (and probably 5.7): Many things possible with QtWebKit still aren't possible (mainly QNetworkAccessManager/QWebElement/QWebFrame APIs missing). For example, anything other than a single, global proxy isn't possible. More sophisticated adblocking isn't possible. Setting the scroll position isn't.
      • QtWebEngine isn't getting packaged for Fedora/Debian/Ubuntu because it bundles a patched Chromium, so dropping QtWebKit support is infeasible.


      And you're blaming us for not switching over yet? So you prefer a completely broken browser over a working but suboptimal one? Honestly, with 5.5 I'm quite happy with QtWebKit, even more so comparing to QtWebEngine... I think QtWebEngine will be the better solution at some point, but it's far from being ready yet, and switching to it will mean losing many features and adding many workarounds.

      So yeah, I'm not happy about the removal of QtWebEngine before it can be considered stable/mature, and I certainly don't need to be "forced" to switch.

      Comment


      • #4
        Otter Browser developer here. ;-)
        Indeed, it is too early to drop QtWebKit support, QtWebEngine is not up to the task yet, albeit it will be way more usable than in Qt 5.5...
        I have a whole wiki page listing just the most important stuff missing in QtWebEngine, only some of these feature will be available in 5.6, and sometimes only partially:
        Otter Browser aims to recreate the best aspects of the classic Opera (12.x) UI using Qt5 - OtterBrowser/otter-browser


        Some time ago there was information of reversal of that decision due to QtCreator depending on QtWebKit (for displaying documentation), it seems that it was corrected or someone forgot to update wiki page.

        Comment


        • #5
          That does look like a ton of missing features Emdek and The Compiler, hopefully with the dropping of QtWebkit more focus will be given to QtWebEngine from devs that were working on both.

          Comment


          • #6
            My8th, that doesn't change that much, QtWebKit seen almost only bug fixes since Qt 5.3 anyway.
            I think they cannot start ignoring QtWebKit completely anyway, most likely there are still commercial users that cannot go for QtWebEngine yet.

            Comment


            • #7
              Whoa! Didin't realize QtWebEngine being still so broken :O Now I understand Fiber choosing CEF completely. Are any of you others qutebrowserees considering it too?

              Comment


              • #8
                Originally posted by Emdek View Post
                Otter Browser developer here. ;-)
                Indeed, it is too early to drop QtWebKit support, QtWebEngine is not up to the task yet, albeit it will be way more usable than in Qt 5.5...
                I have a whole wiki page listing just the most important stuff missing in QtWebEngine, only some of these feature will be available in 5.6, and sometimes only partially:
                Otter Browser aims to recreate the best aspects of the classic Opera (12.x) UI using Qt5 - OtterBrowser/otter-browser


                Some time ago there was information of reversal of that decision due to QtCreator depending on QtWebKit (for displaying documentation), it seems that it was corrected or someone forgot to update wiki page.
                Have you complained in the mailling list ? If nobody complains it won't get fixed

                Comment


                • #9
                  Originally posted by blindfrog View Post
                  Whoa! Didin't realize QtWebEngine being still so broken :O Now I understand Fiber choosing CEF completely. Are any of you others qutebrowserees considering it too?
                  I plan to look at it at some point before definitely going for QtWebEngine - a lot of the work which needs to be done before that is just making sure everything is modular enough for a second engine.

                  Have you complained in the mailling list ? If nobody complains it won't get fixed
                  Yes, I'm in contact with the developers over IRC/bugtracker/ML since months already - as an example, I was the one proposing to add a scrolling API

                  Unfortunately, there are some things (like the QNetworkAccessManager/QWebElement API) which would be very powerful, but would require a lot of patching inside Chromium, which would lead to the same problems they basically had with QtWebKit - they'd end up with a Chromium fork which would be very difficult to synchronize with upstream.

                  I can see how it's unfeasible to add similar APIs back, but that also means a lot of finer-grained APIs need to be added - the API to intercept/change/block host requests added in 5.6 is a big first step towards a QNetworkAccessManager replacement.

                  The other issue is that in some cases, I don't know exactly yet what's missing - I'd need to start with a half-assed QtWebEngine support and see what stumbling blocks I encounter. Unfortunately it'll probably take some more weeks to months until I can start, as (as said) I want better tests first, so I can effictively maintain both backends... I wish I could work on this full-time!

                  Comment


                  • #10
                    Originally posted by The Compiler View Post
                    ... And you're blaming us for not switching over yet? ...
                    It's just a reflex. Every time a new buzzword is upon us, those not automatically lining up behind it are marked as holding back the progress of the world.

                    Comment

                    Working...
                    X