Not doing so might break the connection. We have had similar
issues before, e.g. QTBUG-45312.
Change-Id: I95f15d24773fc92b052578bd72d1ba264d0a5f63
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Reviewed-by: Uli Schlachter <psychon@znc.in>
To fix QTBUG-52493 we tied the exposed state of a window to the
application being in the foreground. This has the result of a
visible flash of black between hiding the launch screen and showing
the first frame of the application, as the application is still
waiting for UIApplicationStateActive to begin rendering, which
happens after iOS hides the launch screen.
According to the iOS OpenGL ES Programming Guide, it should be safe
to render GL in UIApplicationStateInactive as well, and even in
UIApplicationStateBackground, as long as the rendering finishes
before the UIApplicationDidEnterBackgroundNotification returns.
To ensure that we catch any bugs in this area, checks have been
added that verify that no rendering happens while in the background
state.
Task-number: QTBUG-63229
Task-number: QTBUG-52493
Task-number: QTBUG-55205
Change-Id: Ib42bedbeddd7479ab0fb5e5b7de9f5805658e111
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Despite the OpenGL ES Programming Guide telling us to avoid all
use of OpenGL while in the background, iOS will perform its view
snapshotting for the app switcher after the application has been
backgrounded; once for each orientation. Presumably the expectation
is that no rendering needs to be done to provide an alternate
orientation snapshot, just relayouting of views. But in our case,
or any non-stretchable content case such as a OpenGL based game,
this is not true.
Instead of continuing layout, which will send potentially expensive
geometry changes (with isExposed false, since we're in the background),
we short-circuit the snapshotting.
iOS will still use the latest rendered frame to create the application
switcher thumbnail, but it will be based on the last active orientation
of the application.
To ensure that we pick up the right geometry when rotating the device
while the app is in the background, we treat applicationWillEnterForeground
as Qt::ApplicationInactive, which matches the recommendations of the
OpenGL ES Programming Guide to "re-create any objects and restart your
animation timers".
Change-Id: Ia9c27f85f996ecf30284c825b43447aa7099224e
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Make sure we catch application state changes as early as possible,
and deal properly with any changes delivered before we have an app
to send them to.
Change-Id: I6d0ea0398f9fab88fc182342769b075cb144227f
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
A UIGestureRecognizer may have its delaysTouchesBegan or delaysTouchesEnded
properties set, which causes iOS to not deliver touch events to the view
until the recognizer has failed recognition of its gesture.
In that case, the touch event is not delivered via [UIWindow sendEvent:]
as usual, but via _UIGestureEnvironmentSortAndSendDelayedTouches. The
latter function is apparently not reentrant, as opening a native alert
dialog in response to the touch delivery will result in the dialogs's
buttons to stop working, probably because they themselves use gestures.
Unfortunately iOS maintains two internal gesture recognizers on iPad,
of type _UISystemGestureGateGestureRecognizer, probably related to the
swipe-from-bottom gesture used for multitasking. Without any workaround,
these two recognizers will result in any tap on the bottom part of the
screen to be delivered delayed, which may introduce stuck alert dialogs
as described above.
UITouch has a gestureRecognizers property, but unfortunately this property
does not give us any information in the cases where we need it, so we
have to use an heuristic involving a UIWindow subclass to detect the
case where event delivery is delayed. As there is no way to prevent
the user from recursing into an event loop when delivering the event,
our only hope is to deliver the event asynchronously.
Task-number: QTBUG-64577
Change-Id: I11d9caa8c4542dc80426a9e58ea555914bed433e
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Since 5.10, QIODevice resets the error string on opening. So, we should
set the error code to UnknownSocketError accordingly.
Change-Id: I0dd314788ffc182d6837f9d06b51e41d6de59d7e
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Test fails to start on FreeBSD:
FAIL! : tst_QUdpSocket::initTestCase() 'networkSession->waitForOpened(30000)' returned FALSE. ()
Loc: [/usr/home/tjmaciei/src/qt/qt5/qtbase/tests/auto/network/socket/qudpsocket/tst_qudpsocket.cpp(234)]
This commit is basically a revert of the Qt 4.8 commit
a951fb79139498774d021759d0466b4b2ff50e68. FORCE_SESSION was only used by
manual testing, as the commit message said
> 8. For manual testing, added the FORCE_SESSION macro to test behaviour
> of UDP sockets when they have an explicit network session associated
So I doubt it has been tested recently.
Change-Id: Ifb5969bf206e4cd7b14efffd14fb569ebf53497b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
When the QVarLengthArray was initialized with a size then append would
add to the end of that. Therefore we need to use reserve to get the
desired effect.
Task-number: QTBUG-64905
Change-Id: Ia1ebeb26cd31bc5e92bd7f81079506a266b845bf
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Android Marshmellow intentionally forbids use of hard links. See
https://code.google.com/archive/p/android-developer-preview/issues/3150
However, instead of using EPERM or another error code that indicates the
hard linking operation itself has a problem but there are no other
problems, Android developers stupidly chose to use EACCES, an errno code
that only indicates permission problems.
In any case, since the call will never succeed, we shouldn't even try.
Task-number: QTBUG-64103
Change-Id: I9e2892cb6c374e93bcb7fffd14fc5d1082bd60a3
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
I broke it in commit 4da2dda2aa. It wasn't
flaky or anything: it was plain broken and would never pass. That
indicates no node in the CI has an IPv4 link-local address (and
apparently neither did I at the time).
Change-Id: Ifb5969bf206e4cd7b14efffd14fb62176546916e
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
FreeBSD, for example, does not have SO_NREAD and its FIONREAD returns
the full socket buffer size, including IP and UDP headers.
Change-Id: Ifb5969bf206e4cd7b14efffd14fb5d8ca778d16a
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This prevents an out of range assert when monitoring directory
with activity (for example, temp).
Task-number: QTBUG-62841
Change-Id: Id3aa4098e9bbd665c7b17a667516885fa7c7f473
Reviewed-by: Jesus Fernandez <Jesus.Fernandez@qt.io>
Reviewed-by: Martin Rotter <rotter.martinos@gmail.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
When building Qt 5.6.2 with gcc 4.1.2 on Fedora 8, a compilation error
happened when compiling the code below
QColor::name()
{
...
case HexArgb:
return QLatin1Char('#') + QString::number(rgba() | 0x100000000, 16).rightRef(8);
...
}
qtbase/src/gui/painting/qcolor.cpp:527: error: integer constant is too large for ‘long’ type
gcc 4.1.2 was unable to handle 0x100000000. The patch is to use Q_INT64_C to
append "LL" to 0x100000000 to avoid the compilation error.
Change-Id: I000e65a5c897ef2d78fcfe4e212d832eb488a762
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
src/corelib/global/qrandom.cpp:915: warning: Cannot find 'bounded(...)' in '\fn' qreal QRandomGenerator::bounded(qreal highest)
src/corelib/tools/qstring.cpp:774: warning: Command '\snippet (//! [qCompareStrings-QSV-QSV])' failed at end of file 'qstring/main.cpp'
src/corelib/tools/qstring.cpp:5281: warning: Cannot find 'qTrimmed(...)' in '\fn' QStringView qTrimmed(QStringView s)
src/corelib/tools/qstring.cpp:5281: warning: Cannot find 'qTrimmed(...)' in '\fn' QLatin1String qTrimmed(QLatin1String s)
src/corelib/global/qrandom.h:171: warning: No documentation for 'QRandomGenerator::System'
src/corelib/global/qrandom.h:105: warning: No documentation for 'QRandomGenerator::bounded(double highest)'
src/corelib/global/qrandom.h:84: warning: No documentation for 'QRandomGenerator::generate64()'
src/corelib/global/qrandom.h:77: warning: No documentation for 'QRandomGenerator::generate()'
src/corelib/global/qrandom.cpp:799: warning: No such parameter 'sseq' in QRandomGenerator::seed()
src/corelib/global/qrandom.cpp:1096: warning: Can't link to 'operator()()'
src/corelib/tools/qstring.cpp:8982: warning: Can't link to 'qStartsWith()'
src/corelib/tools/qstring.cpp:9203: warning: Can't link to 'qTrimmed()'
src/corelib/tools/qstring.cpp:4798: warning: Can't link to 'qConvertToLatin1()'
src/corelib/tools/qstring.cpp:4825: warning: Can't link to 'qConvertToLocal8Bit()'
src/corelib/tools/qstring.cpp:4928: warning: Can't link to 'qConvertToUcs4()'
src/corelib/tools/qstring.cpp:4884: warning: Can't link to 'qConvertToUtf8()'
Change-Id: I5c7c89b230d3d1de8a679c10833319a470a44e80
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Wacom stylus proximity detection had stopped working: it was not
detecting which type of tool is in use, so all stylus types
acted as a generic drawing stylus.
Selecting XI_PropertyEvent on a root window fixes the problem.
There is nothing in the XI2 specification that says that this
property would not be supported on non-root windows. Possibly
it is bug in the X server. Anyways, selecting XI_PropertyEvent
on a root window in this case actually is better. Property event
contains a global state information, there is nothing window
specific in it, so there is no need to select it for every native
sub-window.
It is worth noting that XI_HierarchyChanged also seems to work
only when selected on the root window (according to my testing
results). And on XI2 author's blog post about XI_HierarchyChanged
it says [1]:
"These events are sent to all windows, so it doesn't really
matter where you register. The traditional approach is to
register on the root window."
This kind of further confirms that it might be bug in X Server's
implementation.
[1] http://who-t.blogspot.no/2009/06/xi2-recipies-part-2.html
Task-number: QTBUG-64911
Change-Id: I8582675bf835239932e23f4596966dc167495e30
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Follow native behavior and disable ⌘H and the “Hide”
menu item if there are any open popup windows.
Task-number: QTBUG-58727
Change-Id: Iad38cc5cce29e0081613417c53b154ae0f05857e
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
1. Make the checkbox's box size hidpi scale-able. Making the size
not only anchored to icon size, but also the menuItem's rect height
in empty or too small icon cases.
2. Make the checkmark's pen width in propotion to the box's size
to keep consistent visual effects among different dpi settings
3. Also make the radio button hidpi scale-able.
Task-number: QTBUG-63576
Change-Id: I4369aaa18ee68908a26a118cf04292ee4c3e9847
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The code checked on QFileInfo::size() whether the file had any content.
The check failed for NTFS symbolic links since QFileInfo::size() returns 0
for them. Workaround by using QFile::size() instead.
Task-number: QTBUG-64121
Change-Id: I303414b5a560d1ed8fbc53d969e53f9e2899ae5c
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When the response from res_nquery is too big for the buffer used to receive it
(of size PACKETSZ, a mere 512 bytes), the returned responseLength is the
size of the data that would have been delivered, had there been enough space.
Trying to process all of the data, including what wasn't delivered, leads to
reading past the end of the buffer, which either causes a crash or leads to
rubbish (from the stack) in the resulting QDnsRecords. Easy to reproduce
using many long TXT records.
Replace the array with a QVarLengthArray; when the response is big, resize()
and retry, so as to actually get all of the data, so that we can process
it all. A follow-up patch will fix the case when even the second call/resize
buffer is not enough and we have to use TCP.
Task-number: QTBUG-64742
Change-Id: I173beb531e11a3828fd9c97f437afc192766035e
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
... to make user code buildable with gcc [-Werror=zero-as-null-pointer-constant].
Change-Id: I309953acd7154511660302aa9826410276cfe41b
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Although the items were enabled for a dialog's menubar they were not
appearing as such because Cocoa will query the menu item's target to see
if it has a worksWhenModal selector. Therefore to ensure that the menu
item will be enabled, we need to add this selector to our delegate and
return YES from it when the window for the menubar is the dialog.
Task-number: QTBUG-44584
Change-Id: Ic62dc027d563069d2f5c2b7bf9810184bd76de39
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
Change-Id: I5bed1fd690daa72492e7ec5f24e80198a2592986
Reviewed-by: Janne Koskinen <janne.p.koskinen@qt.io>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
A mysterious file c:\dev\null appeared when running the auto tests on
Windows. Fix by using QMAKE_SYSTEM_NULL_DEVICE.
Amends 5f3529be32.
Change-Id: I0224a9ccd61c4f10b2ddb8f8d690e1849aa88d8a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
The test is flaky on Linux.
Task-number: QTBUG-64639
Change-Id: Iec56ebce4f656f52187b34c8f655b137e41c3d17
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
There seems to be an issue in CoreText which may cause an existing
font descriptor to give unreliable results if it refers to one of
the system theme fonts. Since we do not know all function calls
or events that may trigger this bug, the safe route is to always
create fresh font descriptors when creating fonts for these
descriptors. The impact on performance should be small, as Qt has
its own internal caches.
[ChangeLog][macOS/iOS][Text] Fixed an issue where text using
one of the system theme fonts would under certain circumstances
display random glyphs.
Task-number: QTBUG-63476
Change-Id: I9e9b253018c63976345eec1439a6b78de2cab869
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
qwindowsxpstyle.cpp(289,35): warning: Signature is not normalized. Use void* instead of void * [-Wclazy-connect-not-normalized]
qwindowsxpstyle.cpp(292,35): warning: Signature is not normalized. Use void* instead of void * [-Wclazy-connect-not-normalized]
Change-Id: I773530452c0837c5066f9174c25ae37e57086e76
Reviewed-by: Sérgio Martins <sergio.martins@kdab.com>
it could be somewhat surprising that specifying variant-specific libs
would not clear the common libs, so do that. of course, the default
for the common libs could theoretically contain common deps of the
variant-specific libs, in which case clearing them would be surprising
in turn - luckily, we have no such case.
Change-Id: Ifca08b9e1949c6a0cefed6931ade4021927d7c90
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
... and not only when the source explicitly specifies build variants.
Change-Id: Iac6c8fda8f431d5fb50fada8338d1b660ab040d7
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
unlike for the other fields, we forgot to eval() the values of the
build-specific library values, leading to over-quoting of values which
require any quoting at all.
amends c0cc50520.
Task-number: QTBUG-62521
Change-Id: I4dfce31040dd09248d3f9dd4294f7fb147c13bdd
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
qtConfLibrary_inline() used to set $${1}.builds.$${b}.libs, while
everything else assumed no such .libs suffix. fix the former.
amends 9172143f52.
Task-number: QTBUG-61431
Started-by: Konstantin Ritt <ritt.ks@gmail.com>
Change-Id: I0bd81591c46266d81baa9c12315411183bbc7a63
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
flex emits code using isatty(), but fails to include the required
unistd.h. we can work around it by including the header ourselves.
Task-number: QTBUG-64771
Change-Id: I05313eeb79f7a0e25365dee5f05a0142f87209ae
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When switching on/off multiple time the wifi (mainly, but not only) on
ios/macos the QNAM may wrongly stay on a NotAccessible state while the
configuration is Active.
This change make sure the QNAM::networkAccessible() is correctly
reporting the accessibility.
Task-number: QTBUG-49751
Task-number: QTBUG-58275
Task-number: QTBUG-60366
Change-Id: I238ab32030fbaa8072cce341db8da6bcfc346035
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
In addition to the (deprecated) applicationFrame property, we
base the available geometry on the root view's safe area, which
also takes into account system-reserved areas on iPhone X, and
the screen's bezel in the case of tvOS.
Change-Id: I252d960a0e486dd0c7e30843f88c0bf5684feb24
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
