summaryrefslogtreecommitdiff
path: root/lib/widgets/Api/qwebenginepage_p.h
Commit message (Collapse)AuthorAgeFilesLines
* Moving sources to src part 1: Move files.Jocelyn Turcotte2013-11-281-95/+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>
* Delegated renderer: enable by default for QQuickWebView.Jocelyn Turcotte2013-11-151-1/+1
| | | | | | | | | | | 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>
* Make RenderWidgetHostViewQtDelegate a pure interface.Jocelyn Turcotte2013-11-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | 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>
* Pass popup geometry along for new window creationPierre Rossi2013-10-241-1/+1
| | | | | Change-Id: Ideefbf272d0affa3f53c5795b779f1bfc9c9bf70 Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
* Add windowCloseRequested() supportPierre Rossi2013-10-241-0/+1
| | | | | 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>
* Add preliminary context menu supportPierre Rossi2013-10-111-0/+2
| | | | | | | | | | | 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>
* Add loadProgress APIArvid Nilsson2013-10-041-0/+1
| | | | | | | | | | | | | | | | 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-031-0/+1
| | | | | | | | | | | | | | | | | | | 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>
* Use an enum at creation to initialize the compositing mode.Jocelyn Turcotte2013-09-251-1/+1
| | | | | | | | 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-171-2/+6
| | | | | | This should enable namespaced builds of Qt and QtWebEngine. Change-Id: I4c9d506d864b42a346026b980dcf3777b9680957 Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
* Implement window creation through QWebEnginePage::createWindow.Jocelyn Turcotte2013-09-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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 QWebEnginePage::action for basic navigation.Jocelyn Turcotte2013-08-201-0/+5
| | | | | | | | 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>
* Move the WebContentsAdapter to QWebEnginePage.Jocelyn Turcotte2013-08-201-1/+14
| | | | | | | | To allow QWebEnginePage to act on its own, let it own the WebContentsAdapter and let the view delegate its calls through the page. Change-Id: I851c753d068992e387edab0e1ea8018732af1fd7 Reviewed-by: Andras Becsi <andras.becsi@digia.com>
* Import QtWebKit public headers.Jocelyn Turcotte2013-08-201-0/+66
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>
View Lorry Controller Status