summaryrefslogtreecommitdiff
path: root/lib/widgets
Commit message (Collapse)AuthorAgeFilesLines
* Moving sources to src part 1: Move files.Jocelyn Turcotte2013-11-2817-2752/+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 examples/widgets linking problems on QNXArvid Nilsson2013-11-271-0/+8
| | | | | | | | | | | | | Since QNX ld only supports staging-relative rpath values, the absolute filesystem rpath stored in libQt5WebEngineWidgets.so doesn't help it find libQtWebEngineCore.so. As a QNX-specific counterpart to the rpath hack, we add an rpath-link to qt_lib_webengine.pri that will allow webenginewidgets apps to find the lib at link time. Change-Id: I8217805edebebe55c66e47d6e9409c20f1dfc717 Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
* Use functors instead of lambda expressions when creating a context menu.Andras Becsi2013-11-262-6/+33
| | | | | Change-Id: I09cea3230da7d0b7a218108668bd562f2cb57384 Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@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>
* Delegated renderer: enable by default for QQuickWebView.Jocelyn Turcotte2013-11-152-3/+3
| | | | | | | | | | | 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>
* Mark functions with Q_DECL_OVERRIDE where necessary.Zeno Albisser2013-11-142-15/+15
| | | | | Change-Id: I15261c3737a3284b99308453132f09ee7889c444 Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
* Move implemented properties aroundPierre Rossi2013-11-131-3/+3
| | | | | | | Out of the #ifndef Q_MOC_RUN block, so we can keep track of what's missing there. Change-Id: I53ef60b1a70b5495603d44fb23491c144891eb92 Reviewed-by: Andras Becsi <andras.becsi@digia.com>
* Remove the native window hardware acceleration support for widgets.Jocelyn Turcotte2013-11-133-20/+6
| | | | | | | | This experiment served its purpose and is now more often broken than useful. Change-Id: I73ea68c99dedcc8a3fe9004d130518daf146b493 Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
* Make RenderWidgetHostViewQtDelegate a pure interface.Jocelyn Turcotte2013-11-064-10/+14
| | | | | | | | | | | | | | | | | | | | | | | 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>
* Implement QWebEnginePage::runJavaScriptPierre Rossi2013-11-042-3/+53
| | | | | | | | | | | | | | | | | | | | | We can't have QWebFrame::evaluateJavascript in its old form for several reasons, the first of which being that we don't have a QWebEngineFrame class anymore. This is worked around by adding an optional QString parameter with the frame's XPath. Another issue is that the WebKit1 API was synchronous, and this would not play nicely with the very asynchronous nature of chromium we're now sitting on top of. In order to make this obvious when porting, we rename it to runJavaScript which doesn't return any result. This also introduces a template member function overload that will accept function pointers, functors and lambdas,much like Qt5's new signal/slot syntax, in order to get the result of the javascript evaluation back. Change-Id: I64e15a6f5a168936c52a4da2cef6285dfd16e0d5 Reviewed-by: Zeno Albisser <zeno.albisser@digia.com> Reviewed-by: Andras Becsi <andras.becsi@digia.com>
* Implement popup dialogMary Wu2013-10-292-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>
* Silence a warningPierre Rossi2013-10-292-2/+1
| | | | | | | | While we're at it, QWebEnginePage::createWindow is non const, we could probably use a non const d-ptr in there. Change-Id: If5ad43dcb5d13454c87b7dc84d69b976b1b5e334 Reviewed-by: Andras Becsi <andras.becsi@digia.com>
* Implement inputMethodQueryAndras Becsi2013-10-252-0/+18
| | | | | | | | | | | | 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/+4
| | | | | Change-Id: Ideefbf272d0affa3f53c5795b779f1bfc9c9bf70 Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
* Add windowCloseRequested() supportPierre Rossi2013-10-242-0/+7
| | | | | Change-Id: If97c7b50efc7bf01095cb4a7138208ab2c6b2e9b Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
* Add javascript dialogs supportPierre Rossi2013-10-173-3/+42
| | | | | | | | | | 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-116-0/+106
| | | | | | | | | | | 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-043-0/+8
| | | | | | | | | | | | | | | | 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-032-0/+6
| | | | | | | | | | | | | | | | | | | 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>
* Widgets: implement zoomFactorPierre Rossi2013-10-012-0/+23
| | | | | | Change-Id: I7ef26e4a2e6c9eb228bcf5542ad272b998f8c6a3 Reviewed-by: Michael Bruning <michael.bruning@digia.com> Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
* Use an enum at creation to initialize the compositing mode.Jocelyn Turcotte2013-09-254-6/+7
| | | | | | | | 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-1715-3/+57
| | | | | | This should enable namespaced builds of Qt and QtWebEngine. Change-Id: I4c9d506d864b42a346026b980dcf3777b9680957 Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
* Implement sizeHint for widgets API.Michael Brüning2013-09-121-0/+2
| | | | | | | Unconditionally return a 800 by 600 like in QtWebKit. Change-Id: I6ae151d535fb35ad3420f17921be73ba55878945 Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
* Fix rendering on Retina displaysAndras Becsi2013-09-022-1/+10
| | | | | | | | | | 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-025-3/+35
| | | | | | | | | | | | | | | | | | | | | | | | | 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-205-2/+241
| | | | | | | | | | | | | | 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 the WebContentsAdapter directly in QWebEngineHistory.Jocelyn Turcotte2013-08-204-16/+11
| | | | | | Change-Id: Iac80388e8d3a789b336ab88b75c6fa6048a3c446 Reviewed-by: Zeno Albisser <zeno.albisser@digia.com> Reviewed-by: Andras Becsi <andras.becsi@digia.com>
* Implement QWebEnginePage::action for basic navigation.Jocelyn Turcotte2013-08-204-43/+149
| | | | | | | | 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>
* Implement QWebEngineView/Page::url/setUrl.Jocelyn Turcotte2013-08-202-0/+21
| | | | | | Change-Id: I8b188fb1c6167612307d4db3272f5ae6f85705c7 Reviewed-by: Zeno Albisser <zeno.albisser@digia.com> Reviewed-by: Andras Becsi <andras.becsi@digia.com>
* Implement QWebEngineView::title and QWebEnginePage::title.Jocelyn Turcotte2013-08-202-5/+16
| | | | | Change-Id: I9fb191a5a2351c5c953f640a6cf1a33609385cc9 Reviewed-by: Andras Becsi <andras.becsi@digia.com>
* Move the WebContentsAdapter to QWebEnginePage.Jocelyn Turcotte2013-08-208-88/+116
| | | | | | | | 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>
* Merge QWebEngineFrame into QWebEnginePage.Jocelyn Turcotte2013-08-202-219/+157
| | | | | | | | | | Chromium doesn't allow managing sub-frames from the contents API. To support operations that were made on the main frame, merge the frame API into the page. Methods should be later either be removed or implemented one by one. Change-Id: I52de89a48c00efb9dd0cf0a2c1fdf09d735d2381 Reviewed-by: Andras Becsi <andras.becsi@digia.com>
* Import QtWebKit public headers.Jocelyn Turcotte2013-08-2015-63/+1462
| | | | | | | | | | | | | | | | | | | 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>
* Use QObject::d_ptr for public API classesJocelyn Turcotte2013-08-204-12/+12
| | | | | | | | | | | 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-195-54/+54
| | | | | Change-Id: I58d83f4f33728f92e4bf13b6be30b15528fdd033 Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
* Move QWEBENGINEWIDGETS_EXPORT to qtwebkitwidgetsglobal.hJocelyn Turcotte2013-08-133-1/+58
| | | | | | | | Since the macro is used in public headers, it should also be declared in one of the webenginewidgets module's public headers. Change-Id: I5cd56196e95c78fac2ba8df076f2cd683b01a5ac Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
* Delay the RWHVDelegate parenting until it's been attached to its RWHV.Jocelyn Turcotte2013-08-125-6/+13
| | | | | | | | 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-2/+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-3/+15
| | | | | | | | | | | | | 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-011-0/+1
| | | | | Change-Id: I5ce13af04de8520bb0ab93c48a2493822aa42294 Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
* Enable accelerated composition with QtWidgets view for testing.Jocelyn Turcotte2013-08-011-0/+16
| | | | | | | | | | 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-316-0/+513
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>
View Lorry Controller Status