Introducing the Qt WebEngine • Hacker News Board

Re: Introducing the Qt WebEngine

#31

Post by fpgeek » Fri, Sep 13, 2013, 1:46 AM UTC

randallu wrote: post #28

passfree wrote: post #12

This is what happens when Mozilla stopped giving shit about their XUL platform.

What about WebKit! Now they're down to Apple, GTK+, EFL and BlackBerry (until they go bankrupt). EFL is funded by Intel and Samsung for Tizen (insurance policy against Android?). GTK+ is supported by consulting and occasional grants. If everyone but Apple leave WebKit will it stay open?

The LGPL means there will still be code dumps, but the development process has been closing for some time (e.g. WebKit2 process changes).

Re: Introducing the Qt WebEngine

#32

Post by general_failure » Fri, Sep 13, 2013, 1:54 AM UTC

shmerl wrote: post #20

rwbt wrote: post #18

A little bit off topic, but I'm glad Qt didn't end up at Microsoft.

+1000. That could be a disaster. Some people in Nokia really saved it before the rest of Nokia sunk.

Nobody saved it. It just got sold off.

Re: Introducing the Qt WebEngine

#33

Post by shmerl » Fri, Sep 13, 2013, 2:19 AM UTC

general_failure wrote: post #32

shmerl wrote: post #20

Earlier quoted context omitted.

+1000. That could be a disaster. Some people in Nokia really saved it before the rest of Nokia sunk.

Nobody saved it. It just got sold off.

Selling off could hurt the project. Here it helped.

Re: Introducing the Qt WebEngine

#34

Post by stock_toaster » Fri, Sep 13, 2013, 2:22 AM UTC

icefox wrote: post #16

borplk wrote: post #3

Can someone provide a simplified summary?

After Google forked WebKit a few months ago into the Blink project the Qt trolls got together and decided that they will basing the future Qt WebKit module on the Google fork of WebKit and not the (Apple maintained) WebKit. While similar the two differ in a few key aspects the main one being if the WebKit/Blink webviews are in process or out of process (ignoring the discussion complication of webkit2). There were var…

Didn't google introduce at least some of those "little pain points" due to their requirement for alternate js engine (for v8), and their own process sandbox?

I heard that after the fork, both sides were able to clean up and remove a ton of code (thus benefiting pretty much everyone).

Re: Introducing the Qt WebEngine

#35

Post by gcr » Fri, Sep 13, 2013, 2:29 AM UTC

azakai wrote: post #22

teho wrote: post #17

Earlier quoted context omitted.

>Since Chromium doesn't support flash (that is one of the closed source bits added to Chrome) The Chrome PPAPI Flash Player works perfectly on Chromium and the binary can be shipped separately.

In principle, but does Adobe ship the Flash PPAPI binary separately?

How do other WebKit-based browsers like Luakit get flash to work? I thought they were always using the NS Plugin API for Flash. Is that being deprecated; is PPAPI a replacement?

Re: Introducing the Qt WebEngine

#36

Post by fulafel » Fri, Sep 13, 2013, 10:59 AM UTC

If you ship a copy of a browser engine you need to make sure deployments are diligently kept up to date via patches, that didn't hapapen with the earlier Qt setup. Hope they have a plan for it now.

Re: Introducing the Qt WebEngine

#37

Post by gsnedders » Fri, Sep 13, 2013, 12:21 PM UTC

gcr wrote: post #35

azakai wrote: post #22

Earlier quoted context omitted.

In principle, but does Adobe ship the Flash PPAPI binary separately?

How do other WebKit-based browsers like Luakit get flash to work? I thought they were always using the NS Plugin API for Flash. Is that being deprecated; is PPAPI a replacement?

Adobe no longer support (except for security updates) the NPAPI (not NSAPI) plugin on Linux, which also has a habit of crashing a lot and randomly hanging… If you want Flash to work under Linux, one practically has to use the PPAPI plugin.

Note nobody except Chrome (and those based on the Chromium Content API) has any plan to support PPAPI, so in that sense NPAPI is alive and strong.