QWidgetBackingStore::markDirty has an optimization for QRect, so we don't
want to unify these two functions by calling update/repaint(QRegion(rect)).
Change-Id: Id2a42f478f71863da45697041e0ab0130c74b9d2
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
If QCoreApplication is recreated, it is possible the previous argv[0]
pointer has become invalid, so we should not rely on it. So to prevent
that, we copy the original argv[0] to a static QByteArray.
Task-number: QTBUG-58919
Change-Id: Idadd4cb78e4281830165fb681ea7925109f316ff
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
In Xcode, the default value for GCC_GENERATE_DEBUGGING_SYMBOLS is YES,
which causes Xcode to emit debug symbol bundles (.dSYM) on macOS and iOS
*if* DEBUG_INFORMATION_FORMAT is also set to dwarf-with-dsym. Since that
setting is already set to an appropriate value with debug vs release
builds, the default Xcode value for GCC_GENERATE_DEBUGGING_SYMBOLS is
already correct and in effect the only thing qmake was doing was always
setting GCC_GENERATE_DEBUGGING_SYMBOLS to a wrong value for release
builds - it should be YES in all cases, to allow the .dSYM bundles to
be generated in release mode, which is in fact the only case where
they're really needed in the first place.
Task-number: QTBUG-41246
Task-number: QTBUG-50896
Change-Id: I07639a3c4ff9f62d591cde3ad66748767d475e3b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
We set anchors from QSslConfiguration::caCertificates. On macOS these
anchors are by default copied from the system store, so I expected
setting 'trust those anchors only' should not break anything.
Somehow, on 10.11 SecTrustEvaluate fails to evaluate a valid
certificate chain (apparently because it has an intermediate
certificate, it's just a guess, since their API/docs are too poor
to explain well what was the real cause) as I can see connecting,
for example, to google.com - we have a chain with a valid root,
say it's GetTrust CA and we have it also in our list of anchors we set
on trust, but evaluation fails with: kSecTrustResultRecoverableTrustFailure:
"This means that you should not trust the chain as-is, but that
the chain could be trusted with some minor change to the evaluation
context, such as ignoring expired certificates or adding an
additional anchor to the set of trusted anchors."
Since none of certs is expired, and the required anchor already set,
this must be some bug in SecureTransport. For macOS (deployment
target) < 10.12 we fallback to the original version of the code
(the one that unfortunately does not allow us to limit the set
of trusted anchors by what client code wants to trust).
Change-Id: Ie42fd77c3eb6ef7469812aa0d7efff88a003c0b8
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
... from 1.7.4 to 1.7.5 (released Sep, 2015).
Some more locking issues were fixed after 1.7.4. Testing
for a prolonged period of time has showed that 1.7.5 does
not cause a system lock-up.
[ChangeLog][Platform Specific Changes][X11 / XCB] Minimal libXi
version requirement has been updated from 1.7.4 to 1.7.5. This
is because XIAllowTouchEvents is known to deadlock with libXi 1.7.4
and earlier. When touch events are never received, this is not
an issue. Plain mouse / keyboard systems are not affected.
Task-number: QTBUG-62224
Change-Id: Ie70264b9af0390df33c417f660350d4bce48c6d3
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
The safe area margins of a window represent the area that is safe to
place content within, without intersecting areas of the screen where
system UI is placed, or where a screen bezel may cover the content.
QWidget will incorporate the safe area margins into its contents margins,
so that they are are never smaller than the safe area margins. This can be
disabled by unsetting the Qt::WA_ContentsMarginsRespectsSafeArea widget
attribute, which is set by default.
QLayouts will automatically use the contents area of a widget for their
layout, unless the Qt::WA_LayoutOnEntireRect attribute has been set. This
can be used, along with a contents margin of 0 on the actual layout,
to allow e.g. a background image to underlay the status bar and other
system areas on an iOS device, while still allowing child widgets of
that background to be inset based on the safe area.
[ChangeLog][iOS/tvOS] Qt will now take the safe area margins of the
device into account when computing layouts for QtWidgets.
Change-Id: Ife3827ab663f0625c1451e75b14fb8eeffb00754
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The code that was supposed to initialize the joining property of
characters to the correct defaults was actually applied after reading
in the data from the Unicode file, and was in a couple of cases
overwriting explicitly specified data in ArabicShaping.txt
Task-number: QTBUG-63191
Change-Id: Ie35261039b2211a827322ca11afacd9555ccefc7
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Use the correct height/width values when calculating
the vector for resizing the window content and the
new size as viewport size.
Task-number: QTBUG-62475
Change-Id: I33a8dc1379a908e991b04bc31dfc6254a6d005c9
Reviewed-by: Andre de la Rocha <andre.rocha@qt.io>
Reviewed-by: Miguel Costa <miguel.costa@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
(or lack thereof).
* `QString::utf16()` reallocates if `*this` has been constructed using
`fromRawData()`.
* `QString::data()` ensures a writable string, so will detach from raw
data.
* `QString::unicode()`, `constData()`, and `data() const` do not. They
just return `QStringData::data()`, which may point to raw,
non-NUL-terminated data.
These functions can therefore not possibly have the same behavior, but
were documented the same.
Fix.
Also drop the discussion of operator[](size()), as that, too, was not
correct, and anyone who indexes with op[] beyond size() - 1 should not
rely on proper behavior.
[ChangeLog][QtCore][QString] QString::unicode(), constData() and
`data() const` do not return a NUL-terminated string. This was true
before, but the documentation claimed the opposite.
Change-Id: I1437f57cd02bdf80264e8559608b46aa749c23a8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Change the include header to sys/slog2.h, which is available
in both QNX 6.6.0 and 7.
Task-number: QTBUG-64033
Change-Id: I26d8c5451376bab33e11f4784ca772f84cd6fc28
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Autotest is taken from the previously reverted
8b1377fde1.
Task-number: QTBUG-60231
Change-Id: I44dd79cba22b6baefdd6d95c176790bef0b7eafe
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
The user can set QT_QPA_NO_TEXT_HANDLES to 1 to disable the text handles.
Change-Id: I974af4d79c86259288035fe20b6a9d0c6d047af8
Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
The hash from QOpenGLContext* to cursor texture/shader data can
accumulate dangling pointers if the program uses multiple contexts on
the same screen. This is fixed by moving the cursor data into the
platform context. The code for deleting the texture and shader program
is omitted as it is tied to the life time of the context and the GL
context deletes its resources automatically upon destruction.
Task-number: QTBUG-65119
Change-Id: Ic3b8e5669d14949af811bdf047e7d47000216180
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
QHeaderViewPrivate::setupSectionIndicator() did not honor the font
set for the QHeaderView which results in a wrong font in the indicator
pixmap. Fix it by using the correct font for the dragged section as
it is done in paintEvent()
Task-number: QTBUG-65017
Change-Id: I5393c6861073de22f30ffa13e12c5e2cf8aa7776
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
In rtl mode, the headers were not painted correctly. The style option
selectedPosition was not filled correctly and the paint rect needed
to be adjusted by one pixel to fit the table grid.
Task-number: QTBUG-56520
Change-Id: Ib92d5ab6ff730bba67eca35c83cd638e613f58b9
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Thorbjørn Lund Martsum <tmartsum@gmail.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The file size column was not properly horizontally aligned. The model
only returned Qt::AlignRight with no horizontal alignment. This lead
to a top alignment within QStyle::alignedRect().
Task-number: QTBUG-64098
Change-Id: Iaef30200a63bd0975c88a67d0af2eb1d5254f588
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Check for QWindowPrivate::blockedByModalWindow in
QGuiApplicationPrivate::processDrag().
Task-number: QTBUG-46287
Change-Id: I8f43de8389f34458f9e10b37b94806b47a50d40a
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
If the cursor is at the top of the screen, it may end up with a cursor
rect that extends beyond the screen after we pad it. We need to make
sure it's constrained by the screen geometry before checking if it's
within the available geometry.
Task-number: QTBUG-65041
Change-Id: I115f49d359b3c2e10219a6b8aa5ad051f44256a7
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
When the mode is center we are typically moving the dock widget,
but we should however not stop if the mode is Center.
Though the regression
(in commit e662b4ed721ee36f0a17cc413494b7d09395d52e)
is not easy to reproduce it is clear
that the code later may call "mouseMoveEvent(e)" and the
mode is also checked for being Center and in that case
the eventfilter (function) returns true (not false).
Change-Id: I3936ec56833d613f78920d9ccf8ddb66e19e9802
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
This is mostly relevant for Apple platforms, where we can use the new
unguarded availability warnings to guarantee that proper version checks
are present when using APIs that are not necessarily available on the
deployment target.
Change-Id: Ie408704b2924e1220491a9ea30f0141dfa4867d9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry-picked from 70422449ef)
MetaKeyKeyListener augments the meta state of the keyboard, we need
to also check the KeyEvent.getMetaState().
Task-number: QTBUG-61369
Change-Id: I07a5d7b1b741a958bc94e1f1677dc1f2256220b6
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
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>
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>
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>
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>
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>
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>
