| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
| |
This lets the page receive touch events sent to the QWidget/QQuickItem.
Change-Id: Ic358d4963d6af3df57d37a02b471cd442e8947ce
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
|
| |
|
|
|
|
|
| |
Since ContentBrowserClientQt::OverrideCreateWebContentsView now
takes care of using our Qt layer at runtime without relying on
the static RenderWidgetHostView::CreateViewForWidget, we can
now avoid linking this layer into the render process.
|
| |
|
|
|
|
|
| |
process uses the same code as lib and decides at runtime which
code to run. Fix the debug build by making sure that all infrastructure
code is available in both process and lib by building common code
not shared directly through chromium sources in a separate static lib.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
among other things:
- Better modifiers mapping
- Mapping Qt key codes to windows keycodes thanks
to the big-ass switch "salvaged" from WebCore's
PlatformKeyboardEventQt
- Subsequently introduce Copyrights and license header
(the keycode mapping was BSD-licensed)
|
| | |
|
| |
|
