@jcar87 To build legacy QtWebKit you should point LIB and INCLUDEPATH variables to locations of your ICU includes and libraries. So it's absolutely possible to build it standalone, though you should not do that because it is insecure, slow[*], and does not support modern web standards.
@grheard BTW, simply accessing Document from MediaPlayer is considered a layering violation in modern WebKit (i.e. WebCore/platform and rest of WebCore are different layers). You should work with MediaPlayerClient only.
I faced the same problem, and my Qt version is Qt5.5.1. QtWebkit plugin will always be on the top despite z-index in the style property, other objects with higher z-index will be corvered by this plugin.
Is there any resolution to put the plugin at the bottom of the webview?
@datasunny You are right, buffer may have different encoding.
My initial thought of this API was to return QByteArray to avoid useless encoding conversion for those who just needs e.g. to save it into file. Now I think we should better have easy API returning QString, and advanced API returning object with QIODevice and properties like encoding and MIME type.
For normal web browsing that would be sufficient, yes.
In my case we use a web-driven GUI. If I stop the script that needed too long (due to some network error or whatever) the GUI is missing on the device.
Finally coming back to this ... and found the issue :-)
DBGWebPage *NewPage = new DBGWebPage(webGUI);
The new Page was not a child of the correct object.
I checked pointers as suggested.
The connect of the JS bridge showed no issues.
Approach with multiple views is optimal when you want all those pages to be present on screen at the same time, or have indpendent "tabs" like in a browser with separate navigation histories and possibility to do background work like playing music
This is about what we do. The screen is divided into various sections that are used for various menus, sub-menus, lists ... and more. These need to be loaded and shown/hidden separately or at the same time. The GUI is completely based on webpages with html/css/php/js.
I have it working pretty smart now, though there are some limits like a key can not be sent to a webGUI that is hidden for instance, which would be great to preload a GUI section before showing.
@chanyenping QtWebKit can use 2 different player implementations: GStreamer and QtMultimedia. If you are using GStreamer (on Linux you really should, because QtMultimedia acts just like an additional layer on top of GStreamer, and is not as integrated into WebKit as GStreamer player), you don't need any QtMultimedia stuff on device.
As for GStreamer plugins, you should look what codecs you need to support, for widest coverage you need all plugins. You may also need to adjust code to make use of hardware acceleration, if your device vendor provides gstreamer integration