The whitelist is kept in ACE form, so if the TLD came in Unicode, we
need to run ToASCII before we can check the whitelist. This is slightly
inefficient because we'll run the same operation later in this domain.
Change-Id: Iadfecb6f28984634979dfffd14b831f37b0f4818
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Florian Bruhin <qt-project.org@the-compiler.org>
.. when running event loop with QEventLoop::ExcludeUserInputEvents.
In a properly functioning code, g_main_context_iteration is expected
to block until any event source becomes ready to dispatch an event
(or interrupt occurs). Qt provides several custom event sources to
the Glib event loop. The bug (busy loop) was caused by faulty event
source implementation when QEventLoop::ExcludeUserInputEvents is set.
As long as the window system's event queue was not empty, we signaled
to the event dispatcher that there is an event ready to be dispatched.
This results in the dispatcher calling the relevant dispatch function
(which does handle the ExcludeUserInputEvents flag correctly). As we
do not dispatch user events, the window system's event queue never
becomes empty and we enter a busy loop (CPU running at 100%) where we
signal that we have events to dispatch, but we actually do not dispatch
them and g_main_context_iteration never gets to block.
This busy loop can cause blocking GTK functions such as gtk_dialog_run()
never return.
Task-number: QTBUG-59760
Task-number: QTBUG-57101
Change-Id: I545b7951108eeaba019614ae8f5a1168c8b26c27
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Gunnar Sletta <gunnar@crimson.no>
Add it to the qtcore documentation, but mark it as a tool (code does
not get shipped with customer application).
Change-Id: I75cc199a2bbd86f9e40a75396144645ea69a7bd1
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
Strip the quotes from the field name in QSqlRelationalDelegate
implementation to able to find the field in the dictionary.
Task-number: QTBUG-59137
Change-Id: I2f1dc9ce3b9c91ca6cc3d3b82e61e1456c3b22c7
Reviewed-by: Samuel Gaist <samuel.gaist@edeltech.ch>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Tablet vendors allow user configurable pen buttons
where the user may assign a logical mouse button to
a given physical button.
In the case of Wacom tablets this mapping is not reflected
in the buttonMask API, which returns the state of
the physical buttons.
Use NSEvent buttonNummber instead, which returns the
logical button number, after applying user mappings.
Unifiy button state stacking with the mouse handlers.
Handle a special case where buttonNumber returns 0
for tablet right mouse presses. We get these events
via rightMouse* event handlers and can hardcode the
button number.
Change-Id: I06b9b1aa98c49b84f7e3871e694c22c7ad0169d6
Task-number: QTBUG-57487
Task-number: QTBUG-54160
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
This change restores usability of Qt with older versions of CMake which
do not provide a language feature used in the implementation of the new
Qt5::<ModuleName>Private targets.
Task-number: QTBUG-60229
Change-Id: I6a6a1b09be3edca200692250bb8f0d7f6a1b8f7a
Reviewed-by: Stephen Kelly <steveire@gmail.com>
The widget might be in the QObject destructor when the event is received,
so we can't static cast.
There is no need to check for isWindow for ChildRemoved because it would
not otherwise be on our list.
Change-Id: Ifc0a2979f1f6720f1963399276a28ac4a3224fff
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
The destructor of QStandardItem needs to access the model. So we need to
destroy them before the QStrandardItemModel gets destroyed.
In the destructor of the private, it is already too late because we are
already in the ~QObject
Since the destructor of QStandardItemPrivate is now empty, remove it
completely. There is no need for QStandardItemPrivate to have a virtual
table as there are no class that inherit from it.
Change-Id: Id6639e21f277f1c4e85c3f9bc720b4f29eb16c2c
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
... as it has outlived its original purpose:
Qt3 implementation on X11:
void QApplication::flush() { flushX(); }
void QApplication::flushX() { if (appDpy) XFlush( appDpy ); }
Qt4 implementation on X11:
Did nothing when QApplication::flush() was called (the flush()
overrides in {unix,glib} event dispatchers with empty bodies).
In Qt5 this function somehow has been repurposed (inconsistently)
to do what QCoreApplication::sendPostedEvents already does:
QAbstractEventDispatcher::flush() = 0;
=> QCocoaEventDispatcher::flush() {}
=> QEventDispatcherCoreFoundation::flush() {}
=> QIOSEventDispatcher (does not override ::flush())
=> QEventDispatcherGlib::flush() {}
=> QPAEventDispatcherGlib (does not override ::flush())
=> QEventDispatcherUNIX::flush() {}
=> QUnixEventDispatcherQPA (when QT_NO_GLIB=true)
::flush() { if (qApp) qApp->sendPostedEvents(); })
==> QAndroidEventDispatcher (does not override ::flush())
=> QEventDispatcherWin32::flush() {}
=> QOffscreenEventDispatcher::flush() {
if (qApp) qApp->sendPostedEvents();
QEventDispatcherWin32::flush();
}
=> QWindowsGuiEventDispatcher (does not override ::flush())
=> QWindowsDirect2DEventDispatcher (does not override ::flush())
=> QEventDispatcherWinRT::flush() {}
=> QOffscreenEventDispatcher::flush() {
if (qApp) qApp->sendPostedEvents();
QEventDispatcherWinRT::flush();
}
=> QWinRTEventDispatcher (qminimaleglintegration.cpp) (does not override ::flush())
=> QWinRTEventDispatcher (qwinrteventdispatcher.h) (does not override ::flush())
Whatever this function was doing on macOS in Qt3 and Qt4 also has been
dropped in Qt5. It appears that the other event dispatchers in Qt5 that
have overrides for flush() have simply copy-pasted this logic.
Clearly the documentation of QCoreApplication::flush() is outdated and
has nothing to do with the actual implementation in Qt5.
This function is rarely used in Qt5 sources. It should be safe to remove
the calls to QCoreApplication::flush() from Qt source code, as this
function has been doing nothing on most platforms anyways. Repurposing
it even broke handling of posted events (see QTBUG-48717).
[ChangeLog][QtCore][Event loop] QCoreApplication::flush() is now
deprecated. Use QCoreApplication::processEvents() and
QCoreApplication::sendPostedEvents() instead.
Task-number: QTBUG-33489
Task-number: QTBUG-48717
Change-Id: Icc7347ff203024b7153ea74be6bf527dd07ce821
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: David Faure <david.faure@kdab.com>
Reviewed-by: Gunnar Sletta <gunnar@crimson.no>
This was simply not working for two reasons:
- The index passed to QMetaObject::metacall was not right (there was an offset
because of the return type)
- If the registration succeeded, the arguments were not even initialized.
The tests in tst_moc always called QMetaMethod::parameterType before calling invoke,
which was properly registering the type. So this was not seen in the tests before.
[ChangeLog][QtCore][QMetaMethod] Fixed crash in invoke() with QueuedConnection and
types whose metatype gets automatically registered.
Task-number: QTBUG-60185
Change-Id: I4247628484214fba0a8acc1813ed8f112f59c888
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Calling initWithFrame repeatedly on the same object
leaks memory since internal structures allocated on
the previous init call will not be released.
However, initWithFrame is the only API that can set
scroller direction, which is does based on the geometry.
Use two scroller objets, one for each of the horizontal
and vertical cases.
Task-number: QTBUG-60004
Change-Id: I5d07b62e6969a1824ab705941ac4d0340139b99c
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
Cocoa is better than us at vertically flipping views,
so we use that API instead of fiddling with the graphics
context transforms. But only so from 10.12 onwards. Go
figure.
This also fixes a one pixel offset with horizontal sliders
handle on non-retina displays.
Change-Id: Ia3da8431ad0499a4b6fb7bf6973ed353d91c2905
Task-number: QTBUG-59666
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
QBackingStore should be able to handle a non-created QWindow just fine.
Change-Id: I42299aa0e985422e1fe4279c1385b9979d267a47
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
After 5b78fcd03b the raster backingstore tries to use the platform window
to resolve the native DPR, but we might not always have a platform window.
Instead we go though the window, like before, which has fallback paths for
the case of no platform window, and then remove the Qt scaling factor
manually.
Change-Id: I19c8383b0a33f3d97aaf0d0e886ed03e14cb1592
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
qnetworkreply.cpp:307: warning: Can't link to 'QNetworkRequest::UserVerifiedRedirectsPolicy'
Change-Id: Ic96f834f3ca9984f626833e45e69f6322b83d12d
Reviewed-by: Martin Smith <martin.smith@qt.io>
Getting the localized family name of a font involves quite a bit of work
internally in CoreText, e.g. creating and sorting font descriptors.
By deferring population of family aliases until a font match misses
we shave off ~1 second of startup time for applications that use non-
localized font families (most applications).
Change-Id: I021952c311c0d70d7769ccf764dbf997ebf30a4b
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
QGuiApplication::devicePixelRatio() should only be used when we don't
know which window we're targeting. For QWindow::devicePixelRatio(),
we can go though the associated screen to get a more accurate DPR.
Change-Id: Idf511fa5c09562a6daf391cd4d0b8b99471045e7
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
qstringbuilder.cpp:75: warning: Command '\li' outside of '\list' and '\table'
Change-Id: I2353462cfd14a4f7cf60d5064ecb069155d1cd34
Reviewed-by: Martin Smith <martin.smith@qt.io>
While a previous commit added the logic for handling arm from a qmake
perspective, the responsible mkspec was forgotten.
Change-Id: I5f36d411f2d2c22d8b048e0931da50d911e7e1b4
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
these variables have no legitimate use when building qt itself, but have
great potential to wreak havoc.
Task-number: QTBUG-60016
Change-Id: I161837463443af82d48145e75952fa529212fe75
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
It only contained a concatenation of the individual rule sets,
probably to fix their order in a central place, as well as
simplifying iteration in defaultCategoryFilter().
Fix these two issues differently, but introducing a RuleSet
enum that lists rule sets in the order in which they should
be applied by defaultCategoryFilter(), and turn individual
rule sets vectors into a C array of vectors.
This enables two nested loops in defaultCategoryFilter to
replace the one loop over 'rules'. Apart from building up
'rules' in updateRules(), this was the only access to that
member. That leaves updateRules() with just the task of
running defaultCategoryFilter() on the new rule sets.
Consequently, a call to updateRules() can now replace the
identical loop in installFilter().
Performance should not suffer. Iterating over a fixed-size
array of vectors is hardly any slower than iterating over
a single vector, and while the construction of 'rules'
was probably a one-off task in most programs, this way
of keeping the rules also saves memory because rules are
not kept in two different vectors.
It is also more maintainable, of course.
Change-Id: Ibc132d096c8137dd02b034752646212e51208637
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Nothing seems to be telling the popup on which screen it should be shown
on. To fix this, simply set same screen the QComboBox uses to the popup.
Task-number: QTBUG-58392
Change-Id: If62a26fe4e51bcf3d770ee72c9baa998541618f4
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Extract Method msgType2i18nString() and use it to build 'rich' in a
single QStringBuilder expression.
Replace the switch over QtMsgType with an array of QT_TRANSLATE_NOOP'ed
strings. That introduces a dependency on the order and amount of enum
values, so add static and dynamic asserts to catch any change.
Saves memory allocations, as well as nearly 300B in text size on GCC 7
optimized Linux AMD64 builds.
Change-Id: I48cc916cba283e482a90ca4ae28aa17b26a4e5ab
Reviewed-by: David Faure <david.faure@kdab.com>
QEMU does not support all syscalls needed for tcp socket testing.
Skipped tests that can't pass on QEMU.
Task-number: QTBUG-59966
Change-Id: Ib6d12d0fc4c913a0222e13db57f0864b7fdf21ba
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
8a375341cf added swap() to QJson* classes
and marked them shared-not-movable-until-qt6.
This change made QMetaType start reporting that QJson* classes were
movable; however, the test used QTypeInfo and not QTypeInfoQuery to
double check that information.
Port the test to QTypeInfoQuery.
Change-Id: I3227a70a8f24c0013257e180e9cb9cfebe9947f9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Since commit bf2160e72c, we can rely on
charNN_t support in all compilers except MSVC 2013, and since that
commit, we use (in 5.10, not 5.9, yet)
!defined(Q_OS_WIN) || defined(Q_COMPILER_UNICODE_STRINGS)
when we only need charNN_t, the type, as opposed to its library
support (u16string, char_traits<char16_t>, ...).
This patch splits the Q_C_UNICODE_STRINGS macro into two, adding
Q_STDLIB_UNICODE_STRINGS for when we need std::uNNstring, leaving
Q_C_UNICODE_STRINGS for when we need just charNN_t support.
In QDebug, when constructing a QChar out of a char16_t, cast to ushort
first, since QChar(char16_t) was only officially introduced in Qt 5.10.
[ChangeLog][Potentially Source-Incompatible Changes] The internal
Q_COMPILER_UNICODE_STRINGS macro is now defined if the compiler
supports charNN_t, even if the standard library does not. To check for
availability of std::uNNstring, use the new Q_STDLIB_UNICODE_STRINGS
macro.
Change-Id: I8f210fd7f1799fe21faf54506475a759b1f76a59
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
That's before the return type or static, inline, constexpr or such
keywords (if any).
Perl Script:
s/^(\s+)(.*) Q_REQUIRED_RESULT(;)?(\s*\/\/.*)?$/\1Q_REQUIRED_RESULT \2\3\4/
Change-Id: I7814054a102a407d876ffffd14b6a16182f159e2
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
They're not affected by the GCC bug noted in the comment.
Change-Id: I7814054a102a407d876ffffd14b69e8a8e2527f1
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Creating a precompiled header exclusively for a one- or two-file module
is wasteful. The time that it takes to build the precompiled source is
on the same order as a regular compilation, so enabling precompiled
headers for those modules just makes the build slower.
Also make it possible to override the precompiled header by just setting
PRECOMPILED_HEADER to empty.
Change-Id: I0e1a09998253489388abfffd14b5f221288c4826
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Let's not allow any new code that uses non-conforming syntaxes. With
GCC and like, we already use -std=c++11 instead of -std=gnu++11 for that
very reason.
Change-Id: I4a7dc1fe14154695b968fffd14aba9f8cea69c47
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Do not use a self-assignment, as that may trigger compiler warnings.
Casting to void is also what Q_UNUSED is doing these days, but we can't
use it here because qgrayraster.c does not include qglobal.h.
Remove a 15-years old comment related to the self assignment.
Found by clazy.
Change-Id: I8cc92b7a1b0b5fb13824959740243e17606ec753
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This reverts commit 47cc9e23a3.
We use QCoreApplication::applicationDirPath in the logging initialization to find
a possible qtlogging.ini file. Because QCoreApplication::applicationDirPath requires
a QCoreApplication instance this leads to a qWarning, which in turn leads to a
recursive call to the logging initialization, and in turn to a recursive mutex deadlock.
Task-number: QTCREATORBUG-18031
Change-Id: Ic75e1e8c062eb647991725378489bf87c9648cca
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Commit 288bfb0bbd added a test that uses QLineEditIconButton, which
requires QT_BUILD_INTERNAL to be defined in order for the findChild()
call to work as expected.
Change-Id: Ieda18f4e26a91322e8a83c14f8d1fbbe4313ecf0
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Delete the QGraphicsEffect from the QWidget destructor instead of from
the QWidgetPrivate destructor. The destructor of QGraphicsEffect still
access methods of the QWidget, but the QObjectPrivate being destroyed
from ~QObject, the pointer is no longer a QWidget.
Fix warning with UB sanitizer in tst_QWidget::setGraphicsEffect
qwidget_p.h:900:23: runtime error: member call on address 0x000001d822c0 which does not point to an object of type 'QWidget'
0x000001d822c0: note: object is of type 'QObject'
00 00 00 00 b0 46 5f 40 e5 7f 00 00 00 23 d8 01 00 00 00 00 f0 e6 00 44 e5 7f 00 00 00 00 74 47
^~~~~~~~~~~~~~~~~~~~~~~
vptr for 'QObject'
#0 0x7fe54767db76 in QWidgetEffectSourcePrivate::detach()
#1 0x7fe548f29815 in QGraphicsEffect::~QGraphicsEffect()
#2 0x7fe548f2a1b7 in QGraphicsBlurEffect::~QGraphicsBlurEffect()
#3 0x7fe548f2a208 in QGraphicsBlurEffect::~QGraphicsBlurEffect()
#4 0x7fe5475cd463 in QWidgetPrivate::~QWidgetPrivate()
#5 0x7fe5475ce62c in QWidgetPrivate::~QWidgetPrivate()
#6 0x7fe5400d0dda in QObject::~QObject()
#7 0x7fe54763d411 in QWidget::~QWidget()
#8 0x7fe54763d7f4 in QWidget::~QWidget()
#9 0x4cc309 in QScopedPointerDeleter<QWidget>::cleanup(QWidget*)
#10 0x4cc309 in QScopedPointer<QWidget, QScopedPointerDeleter<QWidget> >::reset(QWidget*)
#11 0x4cc309 in tst_QWidget::setGraphicsEffect()
Change-Id: I19c049e979cfce2adda908af8336cb4adac8f6c4
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
We can't just static_cast a child to QLayout, because the child might
not be a QLayout, and even if it was, we might be called from the
QObject destructor so we would not be a layout anymore.
Instead we can just qobject_cast the deleted object to a QLayout and
remove it from the layout with removeItem.
This would not take in account the case where we would be called because
the QLayout gets destroyed, so we handle this case from ~QLayout by
removing ourself from the parent.
Note that the comment in ~QLayout was wrong, as the layout gets destroyed
explicitly from ~QWidget, not from ~QObject.
Change-Id: I49c6f17a76f207b9d750b6e5d987469498b96b31
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
We don't need to defer to NSWindow creation before determining the initial
window geometry, and we don't need to redetermine each time we re-create
an NSWindow for a QCocoaWindow.
Change-Id: Ie13380830b44e96670ff16513f29deef5f5ae313
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
qimage.cpp:2127: warning: Can't link to 'isDetached()'
qmatrix4x4.cpp:1933: warning: Can't link to 'operator()()'
Change-Id: I93a2ead9650faf139040173f8d3b24cfa1e730ae
Reviewed-by: Martin Smith <martin.smith@qt.io>
CoreWindow::GetAsyncKeyState returns flags and not enums so checking
equality does not give the needed result.
As seen in qwindowskeymapper.cpp key events that only contain a modifier
key should not have the key itself as a modifier when calling
handleExtendedKeyEvent.
With the current approach the modifier states are the same as
on desktop Windows.
Task-number: QTBUG-58750
Change-Id: Ie0f3e1d3e8294e1a6b41c9223a7a5153306579f6
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
CorePhysicalKeyStatus::KeyStatus does not give the information we are
after so we have to keep track of "auto repeat" state of the keys
ourself.
Task-number: QTBUG-59232
Change-Id: I22aa185780e5fa1f7f3c23c2deb2a0dde0c4a582
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Fixes two separate errors. QImage::transform was incorrectly adding
colors to the color-table of the returned image when the converted image
would not be indexed, and qpnghandler was looking at non-empty color-
table instead of color format.
Task-number: QTBUG-43708
Change-Id: Ife14b6428ca65ac7d3a0b36a89a73e56d64586b4
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
