Announcement

Collapse
No announcement yet.

WebKit Looks To Drop Google Code, V8, Skia

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

  • #11
    Originally posted by GreatEmerald View Post
    But if it's just optional, usable code, why would they want to drop it? Hide it behind a compiler flag if more compilation speed is desired, and that's all.
    And if anyone wants to step up to maintain it and use it, they'll keep it. But as of right now thats basically orphaned code so why keep the maintenance burden?

    Comment


    • #12
      The Qt5 version of QtWebkit uses the V8 engine doesn't it? So, does QtWebkit now become QtBlink?

      Comment


      • #13
        Google never adopted WebKit 2 proposed and implemented by Apple Safari, GTK+, Qt, Win.

        Full scale adoption of LLVM/Clang/LLDB/Compiler-RT/libc++abi/libc++ will be adopted in WebKit. You can bank on it. All this support is standard for OS X, FreeBSD, even Debian FreeBSD and Debian proper is including all of this to rebuild their entire archive to support both GCC/libstdc++ and LLVM/Clang/libc++.

        If people want to maintain live copies of both Blink and WebKit they are always free to do so. I'm just thrilled not having to maintain GBs of crap from Google I never cared to check out with trunk.

        It's also great news that GTK+ is adopting cmake so the gyp build crap is also going bye-bye.

        Comment


        • #14
          Originally posted by CTown View Post
          The Qt5 version of QtWebkit uses the V8 engine doesn't it? So, does QtWebkit now become QtBlink?
          Oliver Hunt right answers this connumdrum here:

          https://lists.webkit.org/pipermail/w...il/024408.html

          GTK+ chimed in to clarify it doesn't support V8.

          https://lists.webkit.org/pipermail/w...il/024410.html

          Comment


          • #15
            Originally posted by GreatEmerald View Post
            But if it's just optional, usable code, why would they want to drop it? Hide it behind a compiler flag if more compilation speed is desired, and that's all.
            Because if it exists, it needs to be kept working, and if it's not even being compiled by default, that's unlikely to happen. You end up with a big mass of code that's sitting in the source tree, showing up every time you search for references to the function you're modifying. And developers will figure "it's just the old Chrome stuff nobody uses", and not bother to fix it, since it's not like it affects anybody.

            So no - with nobody interested in maintaining it, I'd give it a month before it's hopelessly broken by changes made to the more useful bits of the codebase - and I'm probably being optimistic at that. So why would you *not* delete it?

            Comment


            • #16
              Originally posted by Marc Driftmeyer View Post
              Oliver Hunt right answers this connumdrum here:

              https://lists.webkit.org/pipermail/w...il/024408.html
              He says nothing about Qt

              Originally posted by Marc Driftmeyer View Post
              GTK+ chimed in to clarify it doesn't support V8.

              https://lists.webkit.org/pipermail/w...il/024410.html
              GTK+ is obsolete and not relevant anymore.

              Comment


              • #17
                Originally posted by ворот93 View Post
                He says nothing about Qt
                No but what he did say was that they were dropping support for all JS engines except the one. If Qt / Digia want to still use V8 then, yes, they'll have to move to Blink. But if they're keeping it as QtWebKit then they'll stick with the default engine.

                Comment


                • #18
                  Originally posted by GreatEmerald View Post
                  If there was code specific to Safari and Chrome in WebKit, how did it get there in the first place? I mean, if it's browser specific, why have it in mainline Webkit, instead of in the actual browser?
                  Relax. They are referring to platform adaptations. Have a look at https://trac.webkit.org/browser/trun...bCore/platform
                  Chrome is written using a custom toolkit based on the Skia graphics library. I'd be very surprised if there is/was any user of the Chromium adaptions aside from Google. Removing unmaintained platforms is absolutely logical.
                  Btw: I can imagine that the android adaptions will stay if anyone if interested in providing a WebKit-based browser for Android.

                  Comment


                  • #19
                    Originally posted by phoronix View Post
                    Following yesterday's announcement of Google forking the WebKit rendering engine to form "Blink" (also with the support of Opera), Apple developers working on WebKit are now looking to strip away Google/Chrome features from upstream WebKit...
                    Reading through the mailing list, the suggestion to remove Chromium support came directly from Google and they'll even write the patches themselves:
                    https://lists.webkit.org/pipermail/w...il/024384.html

                    Comment


                    • #20
                      Originally posted by Ericg View Post
                      No but what he did say was that they were dropping support for all JS engines except the one. If Qt / Digia want to still use V8 then, yes, they'll have to move to Blink. But if they're keeping it as QtWebKit then they'll stick with the default engine.
                      I could be wrong but I think that QtWebKit is using standard JavaScriptCore and V8 is only being used for QML execution.

                      Comment

                      Working...
                      X