Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 24

Thread: WebKit Looks To Drop Google Code, V8, Skia

  1. #11
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,889

    Default

    Quote 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?

  2. #12
    Join Date
    Sep 2011
    Posts
    110

    Default

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

  3. #13
    Join Date
    Oct 2012
    Location
    Washington State
    Posts
    457

    Default

    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.

  4. #14
    Join Date
    Oct 2012
    Location
    Washington State
    Posts
    457

    Default

    Quote 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

  5. #15
    Join Date
    Apr 2010
    Posts
    734

    Default

    Quote 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?

  6. #16
    Join Date
    Aug 2012
    Location
    Europe/Moscow
    Posts
    167

    Default

    Quote 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

    Quote 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.

  7. #17
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,889

    Default

    Quote 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.

  8. #18
    Join Date
    Dec 2010
    Posts
    1,150

    Default

    Quote 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.

  9. #19
    Join Date
    Dec 2010
    Posts
    1,150

    Default

    Quote 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

  10. #20
    Join Date
    Dec 2010
    Posts
    1,150

    Default

    Quote 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •