News from the Qt WebEngine Team

Published Tuesday May 13th, 2014 | by

It has been a while since our last blog post and we would like to provide a short summary of our work and our future plans.

In the meantime, we have added several interesting features such as support for WebRTC or the system clipboard. We added support for Tooltips and Find Text to the Widgets API. Also, we spent a significant amount of time expanding our APIs and verifying these by porting example applications from Qt WebKit to Qt WebEngine.

Qt WebEngine in Action

The following video shows Qt WebEngine in action on multiple platforms. Some very exciting features shown in the video include WebRTC being used for video conferencing and WebGL and CSS animations running on embedded linux. Further it also shows HTML5 Video running on an off-the-shelf embedded device.

Focusing on Embedded

Since last year, we have been working on getting Qt WebEngine running on Linux and Mac OS X. These are already running pretty well as shown in the video above. However, given the market requirements and the high number of requests received for web content on embedded platforms, we have had to slightly shift the team’s focus. Having a well performing, high-quality web engine is a key requirement for many embedded devices, and we want to cater to these with the upcoming release of Qt WebEngine. Therefore, in the past few months we have placed more emphasis on the embedded Android and embedded Linux operating systems that form part of Qt Enterprise Embedded.

Although, the team’s focus has moved to embedded on the short term, there is ongoing work happening to fully support Windows.

So far we have Qt WebEngine running on the following reference devices which are supported through Qt Enterprise Embedded:

embedded Linux:

  • Raspberry Pi model B (Broadcom BCM2835)
  • Boundary Devices SABRE Lite (Freescale i.MX 6)
  • BeagleBone Black (Texas Instruments AM335x)

embedded Android:

  •  BeagleBone Black (Texas Instruments AM335x)
  •  Google Nexus 7 (Nvidia Tegra 3)

 

Furthermore, Qt WebEngine is also running on desktop Linux and on Mac OS X.
The work to add support for Windows is on-going.

Upcoming Releases

We will first ship Qt WebEngine with the Qt 5.3 version of Qt Enterprise Embedded coming soon. At this point, Qt WebEngine will be a Qt Enterprise Embedded only release and will include support for the embedded platforms mentioned above. We are expecting to receive a lot of feedback from our embedded users and this will help us to release an even more improved version also for desktop with Qt 5.4.
Qt WebEngine is a solid and future proof solution for Qt-based embedded devices requiring a web engine.

Support for further platforms

Support for further platforms, in particular the desktop platforms will then be added with our 1.0 release which we are currently planning to have with Qt 5.4. We are putting significant effort into easing the porting from Qt WebKit to Qt WebEngine. Qt WebKit remains supported for all desktop platforms with both Qt 5.3 and 5.4, so each application can migrate to Qt WebEngine when desired.

 

Did you like this? Share it:
Bookmark and Share

Posted in desktop, Embedded, Qt, Qt Quick, Qt Quick 2, Qt WebEngine | Tags: , , ,

22 comments to News from the Qt WebEngine Team

J says:

Good news. I was wondering if I made a QPA plug in for a platform that isn’t embedded Linux, like Wii U for example, what extra work would I have to do beyond getting QtWebEngine to compile?

J says:

Also, as requested in a previous blog comment, please be sure to make a mobile example that uses QtWebEngine where it’s available, and falls back to a platform provided web view where it isn’t available.

Michal says:

So far it’s APIs are unacceptable, comparing to what is offered by QtWebKit…

Pierre says:

The adage for this is that “Rome wasn’t built in a day”.
Could you give some examples of things that you are missing to make it a bit more bearable?

Michal says:

Sure, it needs time, but there are already “bad” changes, like no QWebFrame (to be precise, it makes sense to move some of it’s methods to QWebPage but it is still needed for something more advanced, like real web browser, not just HTML viewer) or asynchronous calls (kind of forced by Blink, but maybe they could use signals, to be more like other Qt modules?).
Most important thing is no QNetworkAccessManager integration, it needs lots of work, surely, but it’s must have.
There is no QWebElement equivalent and so far nobody promised that there ever be one…
In current state it doesn’t have much advantages over Qt bindings for mozembed. :-/

Jocelyn says:

FYI signals should be callable from our callback mechanism just like slots or normal member functions. We chose that way to allow C++11 lambda functions.

The maintenance of a WebView API on top of a project that moves as fast as Chromium is a delicate task. We have to find the right balance between powerful features and future maintainability of our stable API on top of their moving code. If we offer those features to you, the price for everybody to pay will be a higher bug rate on each of our releases.

The API is good enough for a regular web browser, but it sounds like you have a good use case to justify digging into Qt WebEngine and exposing the features you want in a branch, not having to commit to binary compatibility constraints. We can have a chat on #qtwebengine about it :)

mozembed bindings are an alternative but it’s not perfect either. You won’t get support and as far as I know you will only be able to ship your application on Linux.

Michal says:

Sure, it is a pain to follow upstream (especially if their APIs are unstable, I have no idea how it looks in case of Blink), I was surprised when original QtWebKit come out. ;-)
I know that it would be possible to have kind of fork of QtWebEngine exposing additional APIs, but that creates additional issues, especially for packagers (it takes lots of CPU cycles to build it…), it would be nice to find golden mean. ;-)
Personally I would like to see some semiofficial statement, which APIs will have equivalents in QtWebEngine, which ones for sure won’t be available, which could be added later (possibly stating when we could expect them, like not earlier that Qt 5.5 etc.) and maybe if we can expect something new.
I’m following #qtwebengine for some time already, nick: Emdek.
I didn’t have time to fully evaluate mozembed, but sooner or later I’ll do that, since I would like to support multiple backends but I’ll need anyway something feature complete to replace QtWebKit as default…

Michal says:

Apparently there is some issue with characters limit, counter said that one is left but my comment was cut anyway:

I didn’t have time to fully evaluate mozembed, but sooner or later I’ll do that, since I would like to support multiple backends but I’ll need anyway something feature complete to replace QtWebKit as default one. :-)

Nathan says:

I have the exact same problems you do with the upcoming move to QtWebEngine. For several years now I’ve been employed writing a product that *heavily* uses QtWebkit. Access to the Qt network layer, the ability to execute javascript from the C++ side, traversing the the DOM with the QWebElement API, are all extremely crucial. Without those features, my company is in trouble, and I’m probably out of a job.

J says:

I would probably say that some form of network call interception (for caching or dynamically generated content by the app) is necessary QNetworkAccessManager does this well, so perhaps a call per request could be issued to return a bool stating whether to use Chromium’s network stack or QNetworkAccessManager. There are other benefits to using the Qt network stack for some (or all, if the app prefers) requests, such as special protocol proxy handlers that some companies have written, and countless other reasons. I really think that you should reconsider using Chromium’s network stack 100% of the time. If you can’t use the same resources (such as the same cache as QtQuick, internal app resources, same URL mappings, etc.), then it makes no sense to use Qt over Chromium Embedded Framework or node-webkit, which does have the ability for the app to service a request (bypassing the network stack).

Michal says:

In my case it’s needed since it allows to implement more advanced stuff, like content blocking, disabling referrers, detailed tracking of loading progress etc.
There is no other way to these tings “right way” using official APIs.

Tony says:

Michal, you may consider sending a private message to Digia sales staff. I’m sure we can help you.

Thanks

Michal says:

As mentioned in earlier comment, best way to clear this issue would be to publish some semiofficial statement, which APIs will have equivalents in QtWebEngine, which ones for sure won’t be available, which could be added later (possibly stating when we could expect them, like not earlier that Qt 5.5 etc.) and maybe if we can expect something new

D says:

In your Enterprise Embedded distro, does WebRTC work on RPi and if it does does it use SW VP8?

Thanks in advance,
D

m][sko says:

Are there any benefits that you use same scene-graph as QML?

Jocelyn says:

The benefits are better performances on lower end hardware.

The alternative was to run the Chromium compositor onto a framebuffer object in the application process, and then composite it in the final scene. This is similar to the way the QML WebView is currently rendered in QtWebKit.

Scorp1us says:

I think Qt WebEngine is a bad name.
I think Qt is missing the real Web aspect of what it should be doing.

I think Qt should have a two-fold approach to “web”,
1. Port QML runtime to the web, so that QML can be used for WebUIs.
2. Create a QPA port for a HTML5 canvas. Do you know how many Embedded apps (which this “web engine” seems to be targeting) would be web-enabled with just a re-compile, if you had a HTML5 QPA plugin? Just recompile the embedded app, and on the command line, specify the QPA plugin and bam, you’ve got your UI on a port rot remote control the device.

suy says:

The way the release plan is phrased, seems like this is only a proprietary product from Digia. Is that so? Doesnt seem to me, since I see the source code on Gitorious (with some LPGL headers), code review on Gerrit, etc.

Tuukka Turunen says:

@suy: We are now first releasing Qt WebEngine for our embedded offering, which is packaged, tested and supported only as Qt Enterprise Embedded.

Conny says:

Great to hear that WebEngine will be available on Android as well. I always thought that overlaying a native WebView is too limited for many use cases…

Could you please clarify whether or not WebEngine for Android will be part of the Qt 5.4 open source packages?

Also maybe think about updating this page with the relevant information:
http://qt-project.org/wiki/QtWebEngine

Thanks!
Conny

Jocelyn says:

Please note that the video states “embedded Android” which means Qt Enterprise Embedded running the Qt graphics stack directly on the Android baselayer, using the Nexus 7 as a reference device.

MartinUI says:

The question is whenever this will have iOS support… Anyway it’s great to see progress!

Commenting closed.