summaryrefslogtreecommitdiffstats
path: root/lib/quick
Commit message (Collapse)AuthorAgeFilesLines
* Moving sources to src part 1: Move files.Jocelyn Turcotte2013-11-2814-1136/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | This only move files without adjusting any paths. This moves: - lib/quick -> src/webengine/api (API files) lib/quick -> src/webengine (other files) This contains the main QtWebEngine module library since <ec7b2ee70a8b2db7fb87f50671a001ddd54697b0>. - lib/widgets -> src/webenginewidgets Also rename this directory to match its module name and rename Api to api. - lib -> src/core - process -> src/process - resources -> src/core/resources - tools/* -> tools/scripts/ The build directory is spread as follow: - build/build.pro -> src/core/gyp_run.pro - build/qmake_extras/* -> src/core/ (for the host and target .pro files) - build/qmake -> tools/qmake - Build related scripts -> tools/buildscripts Change-Id: I0cded1de772c99c0c1da6536c9afea353236b4a1 Reviewed-by: Zeno Albisser <zeno.albisser@digia.com> Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com> Reviewed-by: Andras Becsi <andras.becsi@digia.com>
* Fix the build with Qt 5.1Andras Becsi2013-11-261-0/+2
| | | | | | | | 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>
* Add a WebEngine.experimental QtQuick plugin library.Jocelyn Turcotte2013-11-186-0/+127
| | | | | | | | | | | | Bring this QtWebKit concept to our API as well to contain APIs that we aren't comfortable adding to the supported-forever group yet and allow trying them out unofficially for an undetermined number of releases first. Change-Id: I52c8655dfd2996ea461ac6c00de975002827a4c3 Reviewed-by: Andras Becsi <andras.becsi@digia.com> Reviewed-by: Arvid Nilsson <anilsson@blackberry.com> Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
* Add an intermediate Qt5WebEngine module library.Jocelyn Turcotte2013-11-188-8/+149
| | | | | | | | | | | | | | | | | | Make the WebEngine QtQuick plubin library a library only that fetches the API privatly from the official module. This will allow an experimental plugin library to also have access to the API classes, which it currently can't since the plugins aren't deployed the same way as module to <prefix>/lib. The module currently only export classes privately but the plan is to make this library the official linking point of entry for applications along with the Qt5WebEngineWidgets module. The WebEngineCore library could eventyally be merged into this module library if we can get gyp to play well with qmake. Change-Id: I5edb60b412e213b59f791a7b8df9f28c295502de Reviewed-by: Andras Becsi <andras.becsi@digia.com>
* Remove the need for application to set an RPATH.Jocelyn Turcotte2013-11-181-1/+1
| | | | | | | | | | | | | The WebEngineWidgets module and the WebEngine QtQuick plugin libraries already have the RPATH set properly in their headers and the application won't need to link any symbol directly to the Core library. Remove the RPATH directive for examples and tests and fix the build issue by making sure that the link directive isn't passed to dependencies through the prl or pkgconfig file. Change-Id: Id1f5efb8c9823613e804e8e6356d711d561d72ec Reviewed-by: Andras Becsi <andras.becsi@digia.com>
* Add some QQuickWebView graphics stack tests.Jocelyn Turcotte2013-11-152-2/+11
| | | | | | | | | | | This does basic sanity testing of the graphics stack for both the hardware accelerated and software codepaths. This also adds a required signal to report the CompositingSurface later on if the QWindow wasn't available yet when Chromium asked for it. Change-Id: I402ec5ade9114c78bea7960c5f0de989f54110e3 Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
* Delegated renderer: enable by default for QQuickWebView.Jocelyn Turcotte2013-11-152-4/+4
| | | | | | | | | | | This also allows the software code path to be enabled: - Programmatically by setting this dynamic property on the QCoreApplication: "QQuickWebEngineView_DisableHardwareAcceleration" - Through the Chromium command line switch "--disable-delegated-renderer" for quick development use cases. Change-Id: I32136d880444e0a24f042c7c4862950b7ed0c910 Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
* Delegated renderer: Fix remaining synchronization issues.Jocelyn Turcotte2013-11-152-26/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes two issues: - The onFrameSwapped slot was connected with a QueuedConnection, this means that any previous frame triggered by Qt could be queued right before updatePaintNode is called, and be handled right after, thus picking our m_pendingAckFrameData and sending the Ack before this frame was actually swapped. - For cases where Qt triggers a new frame (e.g. typing text in a QtQuick text area) it would be possible that it starts rendering before m_pendingUpdateFrameData had been set, which would render the old frame while Chromium might be in the middle of rendering the new one on the same resources, or destroying them. The solution is grossly to do proper used resource reporting to the child compositors via cc::CompositorFrameAck::resources. We previously released all resources on every frame, and Chromium would resend back to us the ones that could be reused without change. We now instead only return unused resources, but this also means that we have to keep track of used resources ourselves. cc::DelegatedFrameData::resource_list only contain new resources to be added to the scene and we keep a deep copy of the cc::TransferableResource into our MailboxTextures. A few other changes that come with this: - A few null-checks can now be removed since we can better rely on the integrity of the information passed through DelegatedFrameData. - Since we can now prevent used resources from being destroyed while we use them, trigger a frame Ack immediately after updatePaintNode instead of waiting until the buffer is swapped, like ui::Compositor does. - MailboxTexture is now more autonomous, but still require some information from quads. Mark them as not containing alpha by default and fetch this information from quads when encountered. Change-Id: Ice235f3a98a179c87eec7fbcb9880e34b0ed1e73 Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
* Mark functions with Q_DECL_OVERRIDE where necessary.Zeno Albisser2013-11-142-19/+19
| | | | | Change-Id: I15261c3737a3284b99308453132f09ee7889c444 Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
* Delegated renderer: Put textures on those quads.Jocelyn Turcotte2013-11-112-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Make RenderWidgetHostViewQtDelegate a pure interface.Jocelyn Turcotte2013-11-064-27/+30
| | | | | | | | | | | | | | | | | | | | | | | RenderWidgetHostViewQtDelegate acts as a bidirectional interface to avoid exporting Chromium symbols outside of the core dynamic library. The problem is that, other than this, from the top layer point of view, its responsibilities are the same as RenderWidgetHostViewQt, and it would be better not to split its logic without properly defined responsibilities. Using it as a base class and interfacing through its protected methods is also cumbersome and make the destination of calls on the upper layer difficult to discern. Use instead a dual pure interface mechanism like WebContentsAdapter and pass the callback client interface directly in WebContentsAdapterClient::CreateRenderWidgetHostViewQtDelegate. This allows RenderWidgetHostViewQtDelegate to be solely what it should be, an interface. Change-Id: I4e55439ae7f9539cc9e360f0756fbf391405f3b7 Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
* QtWebEngine Dev Tools (Web Inspector)Chris Hutten-Czapski2013-10-293-0/+18
| | | | | | | | | | | | | | | | | | To implement the Web Inspector we need a delegate to handle the http server and devtools connections, a landing page, a ContentClient to tell the devtools server where to find its frontend resources, those frontend resources, and an API for embedders to turn on inspectability in WebEngineViews. The frontend resources are build by the chromium build and are copied over as part of lib's build. The landing page was taken directly from content_shell. This should be replaced by either a new one for all QtWebEngine embedders or by a mechanism for embedders to supply their own (or both). Change-Id: Id4076d5ede34a91abf8dba443aed4dca4be1b3e5 Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
* Implement popup dialogMary Wu2013-10-291-0/+9
| | | | | | | | | This is used to show like date time picker whose document content was generated in webkit engine. Change-Id: I900a6ae5f61646d2ef8497dccc114f7cb5882349 Reviewed-by: Michael Bruning <michael.bruning@digia.com> Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
* Implement inputMethodQueryAndras Becsi2013-10-251-0/+17
| | | | | | | | | | | | This makes it possible on touch devices to use a simple virtual keyboard input method that synthesizes key events. This is the minimal requirement to make the the boot2Qt Keyboard component functional. For more advanced input methods and the widget tests we will need to override inputMethodEvent as well. Change-Id: If9228ee6b1730d72e7424bdb33a9a9c46654507f Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
* Pass popup geometry along for new window creationPierre Rossi2013-10-242-2/+2
| | | | | Change-Id: Ideefbf272d0affa3f53c5795b779f1bfc9c9bf70 Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
* Add windowCloseRequested() supportPierre Rossi2013-10-242-0/+6
| | | | | Change-Id: If97c7b50efc7bf01095cb4a7138208ab2c6b2e9b Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
* Add javascript dialogs supportPierre Rossi2013-10-171-0/+1
| | | | | | | | | | This is just the basic core part and widgets plumbing and default implementations of the virtual functions in QWebEnginePage. QtQuick implementation is still yet to be done Change-Id: I7cf8d6e5ec0bf747d45e9914db57bd0e4ef95b7f Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
* Render delegated renderer frames using the Qt scene graph.Jocelyn Turcotte2013-10-143-14/+49
| | | | | | | | | | | | | | This provides a stub implementation that renders quads and RenderPasses using QSGNodes in QQuickWebEngineView. The BackingStore code path is still supported when the delegated renderer switch is not enabled. To use the new rendering, pass the following switches: --enable-delegated-renderer --enable-threaded-compositing This uses debug, plain color textures until we can fetch tiles and textures from the ResourceProvider across OpenGL context boundaries. Change-Id: I33ea0738dc5a326ef79c1435f75c044c42e8551f Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
* Add preliminary context menu supportPierre Rossi2013-10-111-0/+1
| | | | | | | | | | | This is essentially the widgets part, with some tricks to get it to honor the widget's context menu policy. It enables c++11 for the widgets library for the convenience of using lambdas, which admitedly we could do without, but seems reasonable considering our timeline and the fact that we build chromium that way. Change-Id: I6a632a78d2aa48fb0dfecfe491e92651d12407db Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
* We should still be able to build with Qt 5.1 for the time being.Andras Becsi2013-10-071-0/+3
| | | | | | | | | | Also remove 3rdparty_upstream from from submodules, accidentally added in https://codereview.qt-project.org/#change,67241 This fixes init-repository.py. Change-Id: I08c095e4830581156efc3f069e00e733dda1ffd8 Reviewed-by: Adam Kallai <kadam@inf.u-szeged.hu> Reviewed-by: Andras Becsi <andras.becsi@digia.com>
* Remove v8-private private dependencyPierre Rossi2013-10-041-1/+1
| | | | | | | Long live the new v4 (formerly known as v4vm)! :) Change-Id: I9648e43276abb332b270a7c788a4bbff7334b919 Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
* Add loadProgress APIArvid Nilsson2013-10-043-0/+19
| | | | | | | | | | | | | | | | 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>
* Quick: Add Favicon APIArvid Nilsson2013-10-033-0/+18
| | | | | | | | | | | | | | | | | | | 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>
* Ground work for splitting RenderWidgetHostViewQtDelegateQuick.Jocelyn Turcotte2013-09-274-168/+141
| | | | | | | | | | This prepares the addition of a delegated renderer implementation for the QtQuick view. Use a template for the base class since the accelerated delegate will derive from QQuickItem instead of QQuickPaintedItem. Change-Id: I5619290c0023bafdd27f18dab9edc10f5fbbf838 Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
* Use an enum at creation to initialize the compositing mode.Jocelyn Turcotte2013-09-252-2/+2
| | | | | | | | This value won't change and this will force us to avoid spreading runtime checks. Change-Id: I7928cbe12d75bacddb5ad5c0578ae9a25d7c138e Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
* Add Qt namespace macros QtWebEngine classes.Michael Brüning2013-09-174-2/+16
| | | | | | This should enable namespaced builds of Qt and QtWebEngine. Change-Id: I4c9d506d864b42a346026b980dcf3777b9680957 Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
* Fix rendering on Retina displaysAndras Becsi2013-09-022-1/+7
| | | | | | | | | | Since the QWindow returned by the RWHV delegates was always 0 we never actually propagated a valid WebScreenInfo to chromium. Additionally the painting and scrolling in the backing store had to be fixed so that the device pixel ratio is taken into account. Change-Id: I22dc135e8e090362201292863ed911464b9fc133 Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
* Implement window creation through QWebEnginePage::createWindow.Jocelyn Turcotte2013-09-022-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | This makes the necessary changes to handle WebContentsDelegateQt::AddNewContents and funnel the callback through createWindow in QWebEnginePage and QWebEngineView. - Expose the AddNewContents callback through WebContentsAdapterClient - Allow creating a WebContentsAdapter attached only on the Chromium side, leaving the choice to QWebEnginePage to either adopt it and call WebContentsAdapter::initialize to attach itself as the client, or destroy it if the application isn't handling the call. - Delay the InitAsChild handling in RenderWidgetHostViewQt when it is called before an adapter client has been attached. - Since WebContentsAdapterClient::CreateRenderWidgetHostViewQtDelegate is only a factory method, not creating any link with the callee client, allow using the creating window's adapter client to create the RWHVQtDelegate. This allows an unparented delegate to be created instead of needing to add numerous null-checks in RWHVQt. Use content::WebContents::CreateParams::context for this purpose, which can be used both when creating a WebContents ourselves and when a new window's WebContents is created for us. Change-Id: I032262e867931dc40a7c2eca0c993027a555f56e Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
* Ref-count WebContentsAdapter.Jocelyn Turcotte2013-08-291-2/+2
| | | | | | | | | | This is needed to handle createWindow where a WebContentsAdapter will be created to wrap the new WebContents and will passed up through the API. If the application doesn't handle the callback, this will allow managing the lifetime of the WebContents more easily. Change-Id: I40ae1973a9bdf8c3d75f9ff137228d48ed92cfb2 Reviewed-by: Andras Becsi <andras.becsi@digia.com>
* Implement the basic parts of QWebEngineHistory.Jocelyn Turcotte2013-08-201-2/+2
| | | | | | | | | | | | | | 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>
* Use QObject::d_ptr for public API classesJocelyn Turcotte2013-08-204-9/+6
| | | | | | | | | | | This follows the model used by the rest of Qt, potentially avoiding binary compatibility issues. The compromise is that we now depend on core-private, thus forcing us to follow Qt's release cycle. Change-Id: Ib2df51071fc35935ac99edf7b9c5562949cb43e2 Reviewed-by: Andras Becsi <andras.becsi@digia.com>
* Change "Contents" to "Engine" in API class names.Jocelyn Turcotte2013-08-196-66/+66
| | | | | Change-Id: I58d83f4f33728f92e4bf13b6be30b15528fdd033 Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
* Delay the RWHVDelegate parenting until it's been attached to its RWHV.Jocelyn Turcotte2013-08-124-5/+12
| | | | | | | | This avoids the RWHV being accessed before being attached to the delegate when attaching the later to the view's layout. Change-Id: I5fffef60fdd7203cfb4ced807b5475aac676ea09 Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
* Avoid keeping a RWHVDelegate pointer in WebContentsViewQt.Jocelyn Turcotte2013-08-122-0/+7
| | | | | | | | | There can be multiple RWHVDelegates within one WebContentsViewQt during navigation. Avoid keeping a pointer by sending the focus call to the client directly, which fits the purpose better. Change-Id: I863c174e9a2567f3580f3cb525bc5353ab2a4417 Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
* Implement more detailed load information handling.Michael Brüning2013-08-022-0/+8
| | | | | | | | | | | | Add WebContentsObserver as a base class of WebContentsDelegateQt to be able to get more information about the WebContents (loading state etc.). Also implements load finished with a success value to be able to show when a load has failed. Change-Id: Ic2ad698d180b395cf3d9fb6cd49b12c9cb4fb493 Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
* Don't pass the RWHV to the AdapterClientPierre Rossi2013-08-024-4/+16
| | | | | | | | | | | | | As this looks like a layering violation. Instead, rely on WebContentsViewImpl::CreateRenderViewForRenderManager querying the WebContentsView's size before setting it on the RenderWidgetHostView. The WebContentsView now gets the size of the actual view through the Adapter interface. Then, in RenderWidgetHostViewQt, we now forward the resize request to the delegate. Change-Id: Ide679f6d114508cc7c9ffac83daad19d16764a4d Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
* Handle basic cursor changes.Jocelyn Turcotte2013-08-012-0/+6
| | | | | Change-Id: Ic08f83db03454542554fac9e590d79a4440a4b28 Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
* Forward mouse hover events to the page.Jocelyn Turcotte2013-08-012-0/+7
| | | | | Change-Id: I5ce13af04de8520bb0ab93c48a2493822aa42294 Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
* Enable accelerated composition with QtWidgets view for testing.Jocelyn Turcotte2013-08-011-1/+4
| | | | | | | | | | Only enable it when the --force-compositing-mode switch is used. The purpose of this is only to allow testing pinch-zooming until we are able to use the delegated renderer in the QtQuick view. Change-Id: I2ca265c84c8fe6a74299f1b2757ad525f33fae17 Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com> Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
* Split out the Widgets and QtQuick integrationPierre Rossi2013-07-318-0/+680
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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-04 16:06:13 +0000