| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
It does not work properly with the new rpath logic and causes
problems with the installer packages. This should be a temporary
fix until the rpath situation has been cleaned up again.
This reverts commit 819279827a4ce05562909994468ec5604392c672.
Change-Id: I082ba0118d410f90d202c786d07717bf224d5f70
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@theqtcompany.com>
|
|\
| |
| |
| |
| |
| |
| | |
Conflicts:
src/3rdparty
Change-Id: I49acdd9b5ca94f2807b0c13a97f508a67f1c5750
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
On Windows, system calls that retrieve screen properties (like
GetSystemMetrics to get the size of a scroll bar button) are dependent
on the DPI awareness setting of the calling process.
The render process must use the same DPI awareness setting as the
browser process. Retrieve the DPI awareness of the parent process in
the render process and set it accordingly.
Task-number: QTBUG-48380
Change-Id: Ic17d29d0f584e3cf230ac6ea2b08e3aa0d87ccdd
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@theqtcompany.com>
|
|/
|
|
|
|
|
|
|
| |
This also fixes a runtime failure when building the webengine module
independently (for example, where QtCore and QtWebEngine* frameworks
are located in different directories).
Change-Id: I801d74da0be495089bf552b85b507918684b9685
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
| |
Pass /LARGEADDRESSAWARE the the MSVC linker to allow allocating more
than two GiByte of memory for 32 bit. The flag is a NOOP for 64 bit.
Task-number: QTBUG-47129
Change-Id: I82c4a7bc99e9042c4901425b37202d7977c0bcaa
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Peter Varga <pvarga@inf.u-szeged.hu>
|
|
|
|
|
|
|
|
|
|
| |
Use the proper library executables path on Windows instead of the
libexec.
With this fix it is not necessary to set QTWEBENGINEPROCESS_PATH
environment variable per default.
Change-Id: I8cce07b8adbccc88b03c9cf942841eb1d4a5f176
Reviewed-by: Andras Becsi <andras.becsi@theqtcompany.com>
|
|
|
|
|
|
|
|
|
| |
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.
Change-Id: Ieb6bac7a1be5c25eb7cb917495b58b6a870ca6d4
Reviewed-by: Pierre Rossi <pierre.rossi@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
| |
If debug_and_release is set then QtWebEngineProcess should be built in
release mode as it is a separate process and when it is deployed later it
will be in the right mode already.
Change-Id: I377baa20f01b70db91a7a1cec5f1014b44780546
Reviewed-by: Michael BrĂ¼ning <michael.bruning@theqtcompany.com>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Set the LSUIElement key as Chromium does in its helper app's
Info.plist to prevent seeing a jumping icon in the dock while the OS
waits in vain for QtWebEngineProcess to create a window.
Change-Id: I6c836621ec506fde04bc3825f64c49630a065351
Task-number: QTBUG-42955
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
Reviewed-by: Andras Becsi <andras.becsi@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until we can rely on Qt using @rpath on OSX, QtWebEngineProcess'
dependencies must either be updated by macdeployqt when creating
an .app bundle, either we must make that path relative at build
time.
Since QtWebEngineProcess.app is always deployed inside
QtWebEngineCore.framework, we can safely assume that the dylib is
always in a parent directory and that QtCore.framework can be found
one directory higher.
The additional dependencies of QtWebEngineCore.framework will be
handled by the dynamic linker when it gets loaded, but this only
works for QtWebEngineProcess when macdeployqt uses @loader_path
instead of @executable_path (then relative to the application which
is in a different directory than QtWebEngineProcess).
This can be forced by passing a non-empty value for its
-executable= command-line argument (e.g
`macdeployqt Browser.app -executable=Browser.app/Contents/MacOS/Browser`)
All this will be much simpler once we got Qt framework builds to use
@rpath instead in a future minor version.
Task-number: QTBUG-41611
Change-Id: Ied46c65a09f7033b622708da6e3d85855f9abf34
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is currently no convenient way to deploy QtWebEngine into an application
bundle on OSX. macdeployqt copies frameworks into a .app bundle's Frameworks
directory but this makes no sense unless all the needed files are also
distributed with the bundle.
This patch moves:
- The ffmpegsumo.so library into Libraries/
- Locale .pak files, qtwebengine_resources.pak and icudtl.dat into Resources/
- QtWebEngineProcess into its own .app bundle, itself into Helpers/
QMAKE_BUNDLE_DATA is used to copy files into the bundle while INSTALLS is
used when installing normally. A LOCALE_LIST is explicitly listed since
QMAKE_BUNDLE_DATA can't handle the * glob to match all source files.
Change-Id: I5c0df57b4b9e93f9cce34a74a6e024bf90d37b5c
Task-number: QTBUG-41611
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
A QCoreApplication is needed in order to correctly load the
configuration from qt.conf and setup the Qt environment variables
accordingly. This is important to be able to deploy applications.
This patch creates a dummy QCoreApplication in process main to
have the environment setup correctly.
Change-Id: If536b9edf357d5925fee02f2528872101139f87e
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
|
|
|
|
|
|
| |
Change-Id: Idbe0eafb51d77cc00e3a93179b81770724d5bfaa
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
Reviewed-by: Tuukka Turunen <tuukka.turunen@digia.com>
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These functions override symbols exported by libc,
such as fopen, localtime and similar and call the
exported _override function in QtWebEngineCore.
This code should live in an executable,
but never in a library as it causes erratic behavior
depending on the linking order.
With this change we now also update the submodule
shasum for the 3rdparty submodule to point to a commit
that includes the patches for eLinux.
Change-Id: I88f32c615181eefff2b38b374eed6f57c677d186
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This delegates the linking step from ninja to qmake so that we can
let qmake decide the destination of the target itself, easing the
deployment and installation logic across platforms.
The module is only deployed as a binary and no header are available
outside of the source tree. This is only to make sure that the
dependence of the QtWebEngine and QtWebEngineWidgets libraries on it
is resolved at runtime exactly the same way as with other Qt modules,
on all platforms.
Ninja still takes care of the compilation and gyp lets qmake know how
and what to link by dumping the list of flags and input files in a
generated .pri file.
This has to be done in a separate .pro file so that we can make sure
that ninja is run inconditionally before make reaches the dependency
check in core_module.pro, ensured by the parent Makefile.
Note 1: This patch removes RPATH hacks that are no longer necessary
Note 2: Other targets like ffmpegsumo are still linked by ninja. The
same logic could be moved to a qmake file but this require some more
work to make sure that some switches (e.g. -stdlib=libc++) are
coordinated between gyp and qmake.
Change-Id: If65968547bde5b9cf732e31e97931c17ae1921a7
Reviewed-by: Zoltan Arvai <zarvai@inf.u-szeged.hu>
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
|
|
|
|
|
|
|
|
|
|
| |
Adopt to toolchain changes and fix the build with the
current snapshot.
This patch adds some missing overrides and build system
configurations.
Change-Id: I488929500347bdb5a077ac14e9553cedfcaa605d
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
|
|
|
|
|
|
|
|
|
| |
In developer (non-prefix) builds, the binary goes to $$MODULE_BASE_OUTDIR/libexec,
which is practically qtbase/libexec. In prefix builds it'll be linked to $module_toplevel/libexec
and installed into $prefix/libexec.
Change-Id: Ia42519f3113976e707fbda9e09dbf7ef6e235924
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NOTE: To build after this you should rerun init-repository.py or run
$> git submodule sync
$> git submodule update
$> git config qtwebengine.chromiumsrcdir src/3rdparty
This makes everything build by adjusting paths.
Other mixed-in changes:
- Rename qtwebengine_src variables in scripts to qtwebengine_root to
avoid confusion.
- Cleanup the release and debug extra targets that were in lib.pro.
This file has also been split into src.pro and core.pro.
Change-Id: Ieee9158a65f526b15244eaca59e779b7069d337e
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
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>
|