and make it a namespace

Change-Id: I15c1af8c7d0d8ab213cdf7945109263fe461d2ac
Reviewed-by: Andras Becsi <andras.becsi@digia.com>

Change-Id: Icc4219ace4121a4b30302e0348e48dc75cae54cb
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>

We now require the user to use QWebEngine::initialize() in main (preferably) and
print out an error message if this wasn't set up accordingly. This limits the use
of private scene graph API to inside QWebEngine and offers public API for users
of the API.

Change-Id: I787c176a85ab7784dbc8787d9876960b4872959e
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>

To match other modules example directory structures we should deploy our
examples in a directory matching the module name, webengine and
webenginewidgets in our case.

qmake uses the relative directory of each example up to the upper "examples"
directory to decide where they will be deployed when running the sources
install target.

Change-Id: I59ce7ff8a30f98fad20064c7eecf72b784f1d275
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>

Cleanup version ifdefs and v8-private dependencies.

Change-Id: Iac393c06dfba02499e60d713d9f4d04ef0c9e617
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
Reviewed-by: Andras Becsi <andras.becsi@digia.com>

We are still able to build with Qt 5.1 if we disable
the hardware acceleration codepaths.

Change-Id: Ic748dac0a7f25bbd79f2f711a18431872cebd917
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>

A few changes are necessary to allow fetching textures provided by
the render processes through IPC and bound to their respective GL
context in the GPU process and use them in the QtQuick scene graph.

- Remove the plain color test textures.
- Allow setting the QtQuick QOpenGLContext's handle as the share
  context for all context set as shared in the Chromium GPU process.
  We do this by letting the GpuChannelManager ask us for a
  ShareGroup instance responsible for returning a sharing GL context
  handle.
- Fetch texture IDs from the MailboxManager used by the GPU process
  using the Mailbox given to us in the DelegatedFrameData.
  This is the same mechanism used by Chromium to share textures
  between "client" GL contexts.
- Keep the QtQuick scene graph threads and Chromium in-process GPU
  thread separate. The complicated part of merging those two
  rendering pipelines on the same thread is that it would force Qt
  to also use only one thread for rendering. For the moment we will
  try to synchronize those threads together instead.
- Lock the Qt SG thread while waiting for resource sync points.
  Do so by posting a callback to the Chromium GPU thread and wait
  until the sync point of every resource has been retired by the
  producing contexts.
- Acknowledge the delegated from once QtQuick swapped the GL buffers
  instead of right after we added the frame to the scene graph.
  This fixes some issues where the textures for the previous frame
  would already be released as Chromium was producing the new frame.

There are still a few issues regarding synchronization that have to
be fixed, especially when Qt triggers the rendering of a new frame
while Chromium is starting to produce the next frame.

Note: To enable it we still need to pass the following command switches:
--enable-delegated-renderer --enable-threaded-compositing --in-process-gpu

Change-Id: I2d4f7fac603b1808ed1495a8d689cb48e9ed41b9
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>

This also ajust the name to be consistent with other Qt examples.
- Move nano browser one directory level down,
  also renaming them to match their target name
- Remove the dashes from the target names
- Rename the qtquick example directory to quick, matching the style in lib

Change-Id: I4a5e31be0b919ae596eadbf731be52372ae61151
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>

This is the first step to making proper Qt Modules out of QtWebEngine.
The Widgets integration becomes a proper C++ Qt Module while we make
the QtQuick side a QML plugin for now (could probably be promoted if
the need arises).

Code-wise, this means the introduction of a WebContentsAdapterClient
interface that is subclassed by the private implementation of our API
classes for delegation of things that are UI specific. Functionality
from WebContents and the like is exposed via the WebContentsAdapter.

Change-Id: I4ca3395b9fe8502a24e36002cfd5af44067bb6e8
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>

Cleaner than deciding on startup with an env variable

This layers things properly to be able to implement the UI in the
example application instead of directly in shell_qt.cpp.

This is still using global variables to allow the Shell platform
code to do callbacks to the API classes. This should go away once
we properly implemented a WebContentsDelegate.

Some more start-up fixes and a hack for test command line options for debugging multi-process startup