And add license headers and some minor fixes for warnings in the
example and test.
Task-number: QTBUG-90498
Change-Id: I34592f7f2844c92c25a6a676c8ac1ffca9e03c6d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The lock and unlock of the Android deadlock mutex is now part
of the internal implementation instead of limited to the enum
based permission API. It is unclear why 8bca441b6f added
the guard only to this API and not to the string based API
as well.
The check for isBackgroundLocationApi29 has been removed,
as the logic seemingly resulted in accepting every single
permission type except location permissions if used via
the enum-based API.
Since Android's platform permission API doesn't have an
Undetermined status, we keep a hash of the status for each
permission type, and by default checkPermission() would
return Undetermined, until a requestPermission() call
is done which updates the internal hash, and after that
checkPermission() would return properly Granted/Denied.
Task-number: QTBUG-100413
Change-Id: Ia95c76af754481a281bc90198e349966c9c2da52
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Setting the flag QSurfaceFormat::StereoBuffers does not actually do
anything, because we do not utilize the extra buffers provided. We need
to expose setting the correct buffers using glDrawBuffers between draw
calls.
Change-Id: I6a5110405e621030ac3a2886fa83df0cfe928723
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
When submitting applications to the iOS and macOS AppStore the
application goes through static analysis, which will trigger on
uses of various privacy protected APIs, unless the application
has a corresponding usage description for the permission in the
Info.plist file. This applies even if the application never
requests the given permission, but just links to a Qt library
that has the offending symbols or library dependencies.
To ensure that the application does not have to add usage
descriptions to their Info.plist for permissions they never
plan to use we split up the various permission implementations
into small static libraries that register with the Qt plugin
mechanism as permission backends. We can then inspect the
application's Info.plist at configure time and only add the
relevant static permission libraries.
Furthermore, since some permissions can be checked without any
usage description, we allow the implementation to be split up
into two separate translation units. By putting the request in
its own translation unit we can selectively include it during
linking by telling the linker to look for a special symbol.
This is useful for libraries such as Qt Multimedia who would
like to check the current permission status, but without
needing to request any permission of its own.
Done-with: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Change-Id: Ic2a43e1a0c45a91df6101020639f473ffd9454cc
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Many features of today's devices and operating systems can have
significant privacy, security, and performance implications if
misused. It's therefore increasingly common for platforms to
require explicit consent from the user before accessing these
features.
The Qt permission APIs allow the application to check or request
permission for such features in a cross platform manner.
The check is always synchronous, and can be used in both
library and application code, from any thread.
The request is asynchronous, and should be initiated from
application code on the main thread. The result of the request
can be delivered to lambdas, standalone functions, or
regular member functions such as slots, with an optional
context parameter to manage the lifetime of the request.
Individual permissions are distinct types, not enum values,
and can be added and extended at a later point.
Task-number: QTBUG-90498
Done-with: Timur Pocheptsov <timur.pocheptsov@qt.io>
Done-with: Volker Hilsheimer <volker.hilsheimer@qt.io>
Done-with: Mårten Nordheim <marten.nordheim@qt.io>
Change-Id: I821380bbe56bbc0178cb43e6cabbc99fdbd1235e
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Interesting on its own just because it exercises stencil testing,
unlike any of the other existing manual tests.
In addition it serves as a base example for how outlines could be
done, it is one possible approach at least. (render with stencil
write, then render again slightly scaled up with a solid color with
testing against the stencil buffer content)
Change-Id: I0c845a9004136f229cab037f6f0aab2f772bdd76
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
We currently don't have any machinery for qmake or CMake to map
translations declared via TRANSLATIONS += or qt_add_translations
to the Info.plist CFBundleLocalizations key.
This results in macOS and iOS falling back to the development region,
CFBundleDevelopmentRegion, as the only supported localization of the
app, which is in most cases set to 'en'.
Unfortunately this doesn't work well with the behavior of iOS 11+
and macOS 10.13+ where the OS will set the locale of the app to
the best match between the app's supported localizations and the
user's preferred language.
https://developer.apple.com/library/archive/qa/qa1828/
Since we only support a single localization, the development region,
the locale always ends up as 'en_<REGION>', which after QTBUG-104930
is also reflected in the QLocale's uiLanguages(), resulting in the
QTranslator machinery always picking English translation for the app.
As long as we don't explicitly declare CFBundleLocalizations we need
to opt out of the system's behavior of finding the best match between
the app's declared localizations and the user's preferences, which we
can do via the CFBundleAllowMixedLocalizations key.
Fixes: QTBUG-63324
Pick-to: 6.4
Change-Id: If7586d342148cbbb1d2a152cef039aad4448b13c
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
This is consistent with what $(DEVELOPMENT_LANGUAGE) reports, as well as
the Apple Locales Programming Guide which states that "Locale names such
as “English”, “French”, and “Japanese” are deprecated in OS X and are
supported solely for backward compatibility."
Pick-to: 6.4
Change-Id: I99779d678ef9d4ea90249572f2f977e9b4df6c62
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The workaround stopped working because JSEvents is now not a global
object. Update the workaround by exporting the JSEvents object from
emscripten runtime and replacing the function that removes the
event handlers to a dummy function that does nothing temporarily, only
to revert it when the context is destroyed.
Fixes: QTBUG-107197
Pick-to: 6.4
Change-Id: Icceae884c85e04fdafcca6cf3c563094d3f6f0dc
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
We've been requiring C++17 since Qt 6.0, and our qAsConst use finally
starts to bother us (QTBUG-99313), so time to port away from it
now.
Since qAsConst has exactly the same semantics as std::as_const (down
to rvalue treatment, constexpr'ness and noexcept'ness), there's really
nothing more to it than a global search-and-replace, with manual
unstaging of the actual definition and documentation in dist/,
src/corelib/doc/ and src/corelib/global/.
Task-number: QTBUG-99313
Change-Id: I4c7114444a325ad4e62d0fcbfd347d2bbfb21541
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
This introduces a way to trace each entry in the glyph index
array to a specific index in the original text passed to
QTextLayout, as well as a convenience function to access
the original string from the QGlyphRun.
The index information is stored in the logClusters array internally
in Qt, but it contains the inverse information: For each
character in the output string, it contains an index into the
glyph array. In order to get the string indexes for each glyph,
which makes a lot more sense in the context of the QGlyphRun
API, we need to do a little search to construct the data.
To avoid adding unnecessary allocations, we make the new APIs
opt-in. If you do not specify anything, you will only get the
glyph indexes and glyph positions as before. However, you
can now specify exactly which parts of the layout to extract
using an optional flags parameter.
This also adds a manual test which can be very handy to
visualize QTextLayouts and how they are split into QGlyphRuns.
Fixes: QTBUG-103932
Change-Id: Ie4288fff338b9482aba0aba29fc7e1e59fa60900
Reviewed-by: Lars Knoll <lars@knoll.priv.no>
The new function has an advantage of not requring EM_JS.
Change-Id: Ib9ad0e6b59cfe2e6864697a14b5cfdb39f62af2d
Reviewed-by: David Skoland <david.skoland@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
This provides an easy way to test window modality using a ready
available test.
Change-Id: Ia23736c61fd56dda8f72ae19f5f102163951271b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Since qVersion() might be called also from C code, disable the parts of
qlibraryinfo.h that are relevant only for C++ code if __cplusplus is not
defined.
[ChangeLog][Potentially Source-Incompatible Changes] qVersion() is
moved from qglobal.h to qlibraryinfo.h, '#include <QtCore/QLibraryInfo>'
needs to be added where it's used.
Task-number: QTBUG-99313
Change-Id: I3363ef3fa4073114e5151cb3a2a1e8282ad42a4d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
And include qcore_mac_p.h where needed.
Task-number: QTBUG-99313
Change-Id: Idb1b005f1b5938e8cf329ae06ffaf0d249874db2
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The value will be propagated from Qt build.
Task-number: QTBUG-104858
Change-Id: Iae2c32c3037438f41b92f9ee28004f30eb4e3210
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Test TCP sockets usage on the main thread, on secondary threads,
and with asyncify.
Pick-to: 6.4
Change-Id: I466df8c253c6a18a9c12d44fa8f53e76f81a0437
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Test server for in-browser TCP usage.
Pick-to: 6.4
Change-Id: Ia1a29c0e14a6d2ee8075ce202c9f6998a3ccc4c9
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
The new name describes the behavior in a better way.
[ChangeLog][Build System] The QT_DISABLE_DEPRECATED_BEFORE macro is
renamed to QT_DISABLE_DEPRECATED_UP_TO. The old name is deprecated, but
is still recognized if it is defined during configuration and the new
name is not defined.
Task-number: QTBUG-104944
Change-Id: Ifc34323e0bbd9e3dc2f86c3e80d4d0940ebccbb8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Add a runtime test for asyncify availability; skip tests
if asyncify is not available. Add new build target which
builds with asyncify enabled.
Change-Id: Idaeff0a24aa01525927b012af2a0ba135c7839c3
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
We're not looking to skip faulty tests, but there are cases
where we would like to indicate that a test function exists
but can't run because some precondition is not met.
Pick-to: 6.4
Change-Id: Ifaaafcfa7a55beaaf56d8b25fabbe3dc2566350f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
Emscripten's option for enabling asyncify (-sASYNCIFY) is a link-time
option, which means there is no requirement to have a separate asyncify
build, at least for static builds.
Replace the current QT_HAVE_EMSCRIPTEN_ASYNCIFY compile-time option
with a run-time option which checks if the asyncify API is available.
Keep support for configuring with "-device-option QT_EMSCRIPTEN_ASYNCIFY=1"
for backwards compatibility and for the use case where want asyncify
support to be on by default for a given Qt build.
Enable asyncify for the asyncify_exec example.
Pick-to: 6.4
Change-Id: I301fd7e2d3c0367532c886f4e34b23e1093646ad
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Includes:
- setting a custom Info.plist
- Bundling non-image assets
- Bundling image assets using asset catalogs
- Bundling app icons
- Bundling a launch screen
Projects added for both qmake and CMake.
The executable uses testlib to check that non-image assets,
icons and asset catalogs were successfully bundled upon deployment
to a device.
Task-number: QTBUG-104519
Change-Id: Iaab6112e31e1098dcd2548e18b58bed5b64e6f83
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
The caveat being having to manually create HLSL versions of the hull,
domain, and geometry shaders in parallel with the Vulkan GLSL ones,
while keeping the interfaces intact (stage inputs and outputs, cbuffer
layouts, binding points/registers). This is not always trivial but
typically doable in not very complicated case after inspecting the
SPIRV-Cross-generated vertex/fragment code in the .qsb files. Once
written, the HLSL files can be injected into a .qsb file with qsb -r.
or the corresponding CMake syntax. Conceptually this is no different
from how samplerExternalOES support is implemented for Multimedia.
(there the problem is that the shaders cannot be compiled to SPIR-V
to begin with, here it is that we cannot translate from SPIR-V, but
in the end the workaround for both problems is effectively the same)
The manual tests demonstrate this, both the tessellation and geometry
apps work now with D3D out of the box.
On the bright side, the implementation here in the the D3D backend of
QRhi does not need to know about how the shaders got there in the
QShader. So none of the implementation is dependent on this manual
process. If some day qsb would start translating to these kind of
shaders as well, it would all still work as-is.
Change-Id: I32d9ab94e00174e4bd5b59ac814dfedef9f93ad1
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
QFileDialog::saveFileContent, QFileDialog::getOpenFileContent are now
using local file APIs to access files on any browser that passes a
feature check.
The feature is thoroughly tested using sinon and a new mock library.
Task-number: QTBUG-99611
Change-Id: I3dd27a9d21eb143c71ea7db0563f70ac7db3a3ac
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Add basic tests for timers and event processing, for
different use cases such as on the main thread, on
a secondary thread, and with asyncify.
Pick-to: 6.4
Change-Id: Ie0f82b5de97f639867b1e65dbb0ab8b11db86f85
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
See also QX11EmbedWidget::QX11EmbedWidget() in src/gui/kernel/qx11embed_x11.cpp in qt4.
https: //github.com/qt/qt/blob/4.8/src/gui/kernel/qx11embed_x11.cpp#L475-L477
Pick-to: 6.4 6.3 6.2 5.15
Change-Id: I47504a2d8f3e33c367f092d01ee5d7e1b16b5106
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
All linux CI machines have gtk3 installed. And Python GTK things
are too complicate to setup.
Pick-to: 6.4 6.3 6.2 5.15
Change-Id: I3c0d967f61aebea508784df79569b9d0064f66e2
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
CMakeLists.txt and .cmake files of significant size
(more than 2 lines according to our check in tst_license.pl)
now have the copyright and license header.
Existing copyright statements remain intact
Task-number: QTBUG-88621
Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
...by removing the entire adjustedFormat() helper.
Qt Quick has never used this, which indicates it is not that
useful. Same goes for Qt Multimedia or Qt 3D. Ensuring depth and
stencil is requested is already solved by using
QSurfaceFormat::setDefaultFormat() or by adjusting the formats
everywhere as appropriate.
The helper function's usages are in the manual tests that use it as a
shortcut, and in the GL backend itself. Remove it and leave it up the
client to set the depth or stencil buffer size, typically in the
global default surface format. (which in fact many of the mentioned
manual tests already did, so some of calls to
window->setFormat(adjustedFormat()) were completely unnecessary)
By not having the built-in magic that tries to always force depth and
stencil, we avoid problems that arise then the helper cannot be easily
invoked (thinking of widgets and backingstores), and so one ends up
with unexpected stencil (or depth) in the context (where the GL
backend auto-adjusts), but not in the window (which is not under
QRhi's control).
It was in practice possible to trigger EGL_BAD_MATCH failures with the
new rhi-based widget composition on EGL-based systems. For example, if
an application with a QOpenGLWidget did not set both depth and stencil
(but only one, or none), it ended up failing due to the context -
surface EGLConfig mismatches. On other platforms this matters less due
to less strict config/pixelformat management.
Pick-to: 6.4
Change-Id: I28ae2de163de63ee91bee3ceae08b58e106e1380
Fixes: QTBUG-104951
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
This example connects an echo server running behind
WebSockify, on localhost.
For example, start websockify with
websockify 1515 localhost:1516
to accept a webscoket connection on 1515 and forward
to echo_server at 1516.
Pick-to: 6.4
Change-Id: Id71364e4ab8c46d3482b515fcd1b991b61d7404b
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Connects to echo_server via websockify, like the async version.
Pick-to: 6.4
Change-Id: I9ed560cd388cfddbd0d284d8d40fb7ddf964ba96
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Some of the offsets are already quint32 in the API (vertex input
attributes, dynamic offsets, offsets in draw calls), matching the
reality of the underlying 3D APIs, but many buffer-related functions
use int as of now, simply because that used to be the default choice,
and the same goes for sizes (such as buffer or range sizes). This is
not quite consistent and should be cleaned up if for nothing else then
just to make the classes consistent, but also because no 3D API use a
signed type for offsets, sizes, and strides. (except OpenGL for some)
When it comes to strides (for vertex inputs and raw image texture
uploads), those are already all quint32s. This is straightforward
because most of the 3D APIs use 32-bit uints for these regardless of
the architecture.
Sizes and offsets are often architecture-dependent (Vulkan, Metal),
but there is at least one API where they are always 32-bit even on
64-bit Windows (UINT == unsigned int, D3D11). In addition, we do not
really care about buffer or texture data larger than 4 GB, at least
not without realistic use cases and real world testing, which are
quite unlikely to materialize for now (esp. since we still have the
width/height of 2D textures limited to 16 or 32K in many cases even on
desktops, whereas 2GB+ buffers are not guaranteed in practice even
when an API seemingly allows it).
In any case, the important change here is the signed->unsigned
switch. A number of casts can now be removed here and there in the
backends, because the offsets and sizes are now unsigned as well,
matching the underlying API reality. The size can be potentially
increased later on with minimal effort, if that becomes necessary for
some reason.
Change-Id: I404dbc365ac397eaeeb3bd2da9ce7eb98916da5f
Reviewed-by: Inho Lee <inho.lee@qt.io>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
- QFileInfo::fileName() is not the name of a directory, so we need
absoluteFilePath() to construct a QDir
- QDir::entryList() returns only the name suffix, not the whole path
- stop at any arbitrary depth, and add a find command which does full
recursion
Amends 04a5a74685
Change-Id: I9870db092125a797e8b654e98954ac611dde1ab2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
...that uses the old name after a recent change in the
name of a function.
Change-Id: Ife36fbb0c5d28b350cb1cfc48625528a205af8f9
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
Since we cannot rely on the clients specifying a suitable CSP that will
not forbid execution of js injections, we have to refrain from using
any explicit <script> elements. To keep the promise system working, a
thunk pool was introduced which keeps track of a limited pool of promise
callback exports. In case the resources are busy, pending calls are
enqueued. This works since the JS Promise.then/catch/finally always fire,
even on ready/failed promises.
As the situation of full thunk pool allocation is unlikely to happen
en masse IRL, the solution should not adversely affect the performance.
Heavy unit tests were created to confirm the solution works as expected.
Task-number: QTBUG-99611
Change-Id: I0e6982d4ee76a4263b59e72b004b3ff2f167e4df
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Implement a11y support by adding html elements of the
appropriate type and/or with the appropriate ARIA attribute
behind the canvas.
Also add a simple manual-test.
Change-Id: I2898fb038c1d326135a1341cdee323bc964420bb
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
The promise tests have been ported to qtwasmtestlib so that they do not
have to use asyncify anymore.
Task-number: QTBUG-99611
Change-Id: Id1b5742c90e36a89540e7a2387cb4110c21ace9b
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Added the functionality to report text statuses from tests, reporting
file and line of assertion failures. Refactored the qtwasmtestlib.js
for improved stability.
Task-number: QTBUG-99611
Change-Id: I717e0cc38ac7f155fe870710f6b5e4bfb81b9317
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
qtwasmtestlib supports writing asynchronous tests for
the web platform.
Asynchronous test functions differ from normal test
functions in that they allow returning from the test
function before the test has completed:
void TestObject::testTimer()
{
QTimer::singleShot(100, [](){
completeTestFunction(); // Test pass if we get here
});
}
Currently one logging backend is supported which
writes the results to an html element. See the README
file for further documentation.
Change-Id: Ia633ad3f41a653e40d6bf35dd09d62a97c608f84
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This convenience should be, according to the Apple docs, equivalent to
calling present from a scheduled handler. (which on its own makes it
unclear why we switched in the first place)
In practice it seems the two approaches are not identical. It looks
like that once a frame is submitted earlier than the next display link
callback, the throttling behavior we implement in beginFrame()
(waiting on the semaphore for the completion of the appropriate
command list etc.) starts exhibiting unexpected behavior, not
correctly throttling the thread to the refresh rate. Changing back to
presentDrawable does not exhibit this at all.
The suspicion is that presentDrawable is probably doing more than what
the docs suggest, and so is not fully equivalent to calling present
manually from a scheduled handler.
Therefore, switch to presentDrawable now, which restores the expected
cross-platform behavior, but make a note of the oddity, and also
prepare the hellominimalcrossgfxtriangle manual test to provide an
easy, self-contained application to allow experimenting in the future,
if needed.
This allows Qt Quick render thread animations to advance at the
expected speed (because the render thread is correctly throttled to
the refresh rate), even if the render thread decides to generate a new
frame right away, without waiting for the next display link update.
Without this patch, attempting to get updates not via requestUpdate(),
but by other means (timer etc.) leads to incorrect throttling, and so
the triangle in the test app is rotating faster than expected - but
only with Metal. Running with OpenGL on macOS or with any API on any
other platform the behavior will be correct. Even if scheduling
updates without display link is not efficient, and should be
discouraged, not doing so cannot break the core contract of vsync
throttling, i.e. the thread cannot run faster just because it renders
a frame not in response to an UpdateRequest.
Amends 98b60450f7 (effectively reverts
but keeps the code and the notes because we might want to clear this
up some day)
Pick-to: 6.4 6.3 6.2
Fixes: QTBUG-103415
Change-Id: Id3bd43e94785384142337564ce4b2644bf257100
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
