Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing the Qt WebEngine

blog.qt.digia.com

Post reply on HN
Print view View original

21–30 of 37 posts

Re: Introducing the Qt WebEngine

#21

Post by shmerl »

passfree wrote: post #12

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

Though I disagree with them on this:

> Finally, we are seeing that Chromium is currently by far the most dynamic and fastest moving browser available.

I think Firefox moves better. Plus Mozilla innovates more with their Servo project. Though I wish Mozilla would support projects like these officially instead of ignoring them:

https://wiki.mozilla.org/Embedding/IPCLiteAPI

That's what is used for Jolla's browser in the upcoming Sailfish (it uses Qt for the UI with that IPC embedding).

Re: Introducing the Qt WebEngine

#22

Post by azakai »

teho wrote: post #17
jdboyd wrote: post #14

Earlier quoted context omitted.

Since Chromium doesn't support flash (that is one of the closed source bits added to Chrome), I suspect that while QTWebKit had fun with flash integration, Qt WebEngine will probably make Flash integration impossible. The worst part (at least for where I work) of using Flash in QtWebView was the non-availability of a license to just include the flash .dll in our application distribution.

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

Re: Introducing the Qt WebEngine

#23

Post by fauigerzigerk »

So, if I understand this correctly, there will be no more direct access to the DOM via C++, and JavaScript will be the only language for fine grained, fast DOM access. I'm not entirely happy about that, although I do understand the benefits of the new multi-process architecture.

Re: Introducing the Qt WebEngine

#24

Post by leokun »

raptium wrote: post #8
leokun wrote: post #6

Earlier quoted context omitted.

Qt is making a change to what iOS/Cocoa, Android, and Microsoft developers call a 'webview', an embedded browser engine. Qt's version of a webview will switch from WebEngine to Chromium. So if you want to render a browser page inside an application built with Qt, in the future this page it will use Chromium's engine, not WebEngine which was a homegrown engine based on webkit.

Qt WebEngine is (the new one) based on Chromium. The one based on WebKit is just called Qt WebKit.

Yes my mistake, thanks!

Re: Introducing the Qt WebEngine

#25

Post by Aldo_MX »

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…

A little offtopic, but I wanted to clarify to people not familiar with Qt, that the term "Qt trolls" is because the company behind Qt was called Trolltech, before Nokia purchased it.

Re: Introducing the Qt WebEngine

#26

Post by dave1010uk »

Everyone seems to be moving from WebKit to Blink/Chromium. I wonder if / when Apple will be the only one using WebKit?

Slightly off topic: are there any desktop browsers that run on Linux or Windows that run an up to date version of webkit (for browser testing)?

Re: Introducing the Qt WebEngine

#27

Post by jarek-foksa »

dave1010uk wrote: post #26

Everyone seems to be moving from WebKit to Blink/Chromium. I wonder if / when Apple will be the only one using WebKit? Slightly off topic: are there any desktop browsers that run on Linux or Windows that run an up to date version of webkit (for browser testing)?

You could try compiling MiniBrowser which is bundled with WebKit-GTK tarball.

Re: Introducing the Qt WebEngine

#28

Post by randallu »

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?

Re: Introducing the Qt WebEngine

#29

Post by icefox »

dave1010uk wrote: post #26

Everyone seems to be moving from WebKit to Blink/Chromium. I wonder if / when Apple will be the only one using WebKit? Slightly off topic: are there any desktop browsers that run on Linux or Windows that run an up to date version of webkit (for browser testing)?

Well as long as you have a copy of Arora that links to a current Qt you will have a recent WebKit. I have put Arora as a project on ice, but it is still useful for that purpose.

Re: Introducing the Qt WebEngine

#30

Post by aboodman »

fauigerzigerk wrote: post #23

So, if I understand this correctly, there will be no more direct access to the DOM via C++, and JavaScript will be the only language for fine grained, fast DOM access. I'm not entirely happy about that, although I do understand the benefits of the new multi-process architecture.

Chrome supports a single process mode [1], and has in-process APIs [2] for manipulating the DOM via C++.

I would be surprised if it wasn't already possible to make use of these from the embedder side if you're in single-process mode. But if it's not, I wouldn't expect there to be pushback on changes to that effect.

[1] https://code.google.com/p/chromium/codesearch#chromium/src/c...

[2] https://code.google.com/p/chromium/codesearch#chromium/src/t...

Post reply on HN