| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
Also update references in the doc.
Change-Id: Ica4d77cb1db040b466c739e4fc1bfd37df544589
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
|
|
|
|
|
| |
Change-Id: Ia61fbe3ef6b76c7530d10d4a3305d4208b3469ef
Reviewed-by: Zeno Albisser <zeno.albisser@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>
|
|
|
|
|
| |
Change-Id: Ia8052bffc7be18c4d8f81c3a89ac4a64b1c589af
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
|
|
|
|
|
| |
Change-Id: I48c0ed54cd946f223dc050b8a1f26282b02964a2
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
|
|
|
|
|
|
|
|
|
| |
Set favicon image source to the value of the icon property, not the
url. D'oh!
Change-Id: I411f787f4f19fbeb2db9a61e4aada79b3527dcfb
Reviewed-by: Arvid Nilsson <anilsson@blackberry.com>
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This exposes loadProgress in both widget and quick webengineviews.
However, the progress will not change until we get an upstream change
in Chromium where the content LoadProgressChanged API is exposed to all
ports, not just Android. The upstream change is
https://src.chromium.org/viewvc/chrome?revision=221010&view=revision
Once we get that change, you'll see the widget example browser start to
paint a blue progress rectangle in the background of the URL bar. Also,
a progress bar was added to the quicknanobrowser, but it will be stuck
at 0 for now.
Change-Id: Icbaa01b86c013e0052b3abb7672c38e57128f44a
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds a favicon API modelled after the WebKit2 QQuickWebView API, but
using an http(s) URL instead of a custom protocol, because there's no
icondatabase yet.
The icon URL lingers even when a new load is committed, until the load
finishes. It might be more prudent to clear the icon when committing a
new load, but I opted to let the app take care of that detail if
desired. Many browsers show a spinner instead of the favicon while
loading, for example.
There's no widget API implementation for favicons yet, because that API
only makes sense if we have a full-fledged icon database (case in
point: QWebEngineSettings::iconForUrl()).
Change-Id: I1e7b85104c80de2ae46a5fe9a273104d43a5c71f
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
|
|
|
|
|
|
| |
Change-Id: I7ef26e4a2e6c9eb228bcf5542ad272b998f8c6a3
Reviewed-by: Michael Bruning <michael.bruning@digia.com>
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
|
|
|
|
|
|
| |
This should enable namespaced builds of Qt and QtWebEngine.
Change-Id: I4c9d506d864b42a346026b980dcf3777b9680957
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Mark the remaining methods as not implemented to allow enabling most
of the dependent code in the demo browser and in API tests.
Add two new tests to cover cases that might be problematic with the
index-based implementation.
This also renames WebContentsAdapter::navigateHistory to navigateToOffset
in order to avoid confusion with navigateToIndex.
Change-Id: I7c5cb9f5f878e34206fdfe48334a2dc7d9d95a1d
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
|
|
|
|
|
|
|
|
| |
This imports code from qwebpage.cpp and QWebPageAdapter.cpp of WebKit
into qwebenginepage.cpp and thus also restrict the license accordingly.
Change-Id: Ic5da8f2b469109cb10132cbe6585f2d941b14403
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
|
|
|
|
|
|
|
|
|
|
| |
Do like the QtQuick example and let the Widgets example use urlFromUserInput
to add a missing http scheme instead of letting QtWebEngine do it.
This is the same behavior as QtWebKit does.
Change-Id: Iac1570523253126e059afb00c3a2ff844e177ff1
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
|
|
|
|
|
|
|
|
| |
The ifdefs should later be removed along with the feature
implementations.
Change-Id: If73f4c4c02c00e90d6cf54c6a08bb37f43fa95bc
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
|
|
|
|
|
|
|
|
|
|
|
| |
This makes the demo compile, but not link since
most of the methods aren't implemented yet.
Also disable downloads and printing since they require a bit
more work to instead use the page directly.
Change-Id: I59adfe07fda077c6909f70f12800a4cfa6a6dad2
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
|
|
|
|
|
|
|
|
|
| |
Import the sources as-is, without adding it to the build, to allow
performing diffs later on the changes that were needed to port it
to use QtWebEngine and manage source compatibility issues.
Change-Id: Icf8a284881ce2153e9b5a1ba97dbe77096f1b88d
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the first step toward re-implementing part of the QWebView
API on top of QtWebEngine. The plan is to import the complete headers
to facilitate diffs and progress tracking.
Changes squashed in this commit:
- Use the QWebEngine prefix for class names
- Strip out non-public members and directives
- Allow building using those headers by disabling the Q_PROPERTY
macros and by adding a dummy implementation for virtual methods
directly in the header
- Update the widgetsnanobrowser example to comply with the slight
changes from the previous API
Change-Id: Ia7efa5430f775d09b493544430a04856cc7928f6
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
|
|
|
|
|
| |
Change-Id: I58d83f4f33728f92e4bf13b6be30b15528fdd033
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move common.pri to the root directory to be able to use it with tests.
Remove nano browser specific logic (util.h include and common resources)
from this file and use relative paths in the examples instead.
This also remove unnecessary directives:
- lib doesn't have to be added to INCLUDEPATH since proper modules are used
- util.h doesn't need to be added to HEADERS, moc doesn't need to go through it
- MOC_DIR doesn't have to be adjusted anymore
Change-Id: Id706e7f2ef7c9607bdcd0ba63afecf5b5854262b
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.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>
|
|
|
|
|
|
|
| |
It's quite convenient when one wants to test if navigating works.
Change-Id: I89404df3a9a878701180fdd5b5144b46b3f68df5
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>
|
|
|
|
|
|
|
|
| |
Use the same icons for the widgets and qtquick example.
Remove the styling as it does not work on all platforms anyway.
Change-Id: Iff59455689619ae45823eb835768d7c4fc75bd93
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
|
|
|
|
|
| |
Change-Id: I1d8affaa797a61a71051b3a347ade4e589fd68a7
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
| |
Change-Id: If41e2991be7877060f7739877f756acf2679b688
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
also remove QQUICKWEBENGINE env var
|
|
Cleaner than deciding on startup with an env variable
|