| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I made a clazy automated check that replaced the use of QVariant::Type
by the equivalent in QMetaType.
This has been deprecated since Qt 5.0, but many uses were not yet removed.
In addition, there was some manual changes to fix the compilation errors.
Adapted the Private API of QDateTimeParser and QMimeDataPrivate
and adjust QDateTimeEdit and QSpinBox.
QVariant(QVariant::Invalid) in qstylesheet made no sense.
But note that in QVariant::save, we actually wanted to use the non-user type.
In the SQL module, many changes were actually reverted because the API
still expects QVarient::Type.
Change-Id: I98c368490e4ee465ed3a3b63bda8b8eaa50ea67e
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This property is obsolete with today's user interface reality, and was
never consistently implemented in all styles and widgets. Deprecating
it for Qt 5.15 as preparating for removing the code for Qt 6.
[ChangeLog][QtWidgets][QApplication] The globalStrut property has been
deprecated and will be removed from Qt 6
Change-Id: Iaea88e563144481a395de6cf0745a512e386407d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|\
| |
| |
| | |
Change-Id: I8dbcf23835d52d3aa7d018ed250814d60c68aa83
|
| |
| |
| |
| |
| |
| | |
Task-number: QTBUG-79824
Change-Id: I94dc566c9fb11bc8c598c0d5c043b6f388ebdc80
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
|
| |
| |
| |
| |
| |
| | |
Fixes: QTBUG-74985
Change-Id: I7379865ab9564301c1e636ba1fda40cbb9e04c61
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The logic is now mostly handled in QGuiApplication, with QApplication
only dealing with the widget-specific palettes and interaction between
the style and the palette.
The application now picks up changes to the platform theme and will
re-resolve the current application palette appropriately. This also
works even if an explicit application palette has been set, in which
case any missing roles are filled in by the theme.
The palette can now also be reset back to the default application
palette that's fully based on the theme, by passing in the default
constructed palette (or any palette that doesn't have any roles set).
This is also correctly reflected in the Qt::AA_SetPalette attribute.
Conceptually this means QGuiApplication and QApplication follow the
same behavior as QWidget, where the palette falls back to a base or
inherited palette for roles that are not set, in this case the theme.
Behavior-wise this means that the default application palette of the
application does not have any roles set, but clients should not have
relied on this, nor does QWidget rely on that internally.
It also means that setting a palette on the application and then
getting it back again will not produce the same palette as set,
since the palette was resolved against the theme in the meantime.
This is the same behavior as for QWidget, and although it's a
behavior change it's one towards a more sane behavior, so we
accept it.
[ChangeLog] Application palettes are now resolved against the platform's
theme palette, the same way widget palettes are resolved against their
parents, and the application palette. This means the application palette
reflected through QGuiApplication::palette() may not be exactly the same
palette as set via QGuiApplication::setPalette().
Change-Id: I76b99fcd27285e564899548349aa2a5713e5965d
Reviewed-by: Vitaly Fanaskov <vitaly.fanaskov@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
|
|\|
| |
| |
| |
| |
| |
| | |
Conflicts:
src/corelib/kernel/qobject.cpp
Change-Id: I4780b25665672692b086ee92092e506c814642f2
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The argument is only used when the application palette is set,
(as opposed to setting the palette for a specific widget class),
and that code path is only triggered from QApplication::setPalette,
which passes 'true' for this argument.
Change-Id: I67a1cc3741f6f62653b0f95ff88d28228f9977d4
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| |
| |
| |
| |
| | |
Change-Id: I43cc25207026f174e46534baedf08e0c300728d1
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| |
| |
| |
| |
| | |
Change-Id: I2f582358efaadcd33b39c52317222322c589423f
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|\|
| |
| |
| | |
Change-Id: I9b4816b4aa6f0c51a446742db58b9d0dcf69aa09
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
QApplication tries to close all windows on quit using closeAllWindows,
but closeAllWindows skips some windows, in particular any widget with
WA_DontShowOnScreen set.
QApplication then tries to verify that all windows have been closed,
and that logic should skip the same kind of windows as closeAllWindows
does.
We include WA_DontShowOnScreen so that widgets that are proxied via
QGraphicProxyWidget will not prevent the application from quitting.
There's still some divergence between closeAllWindows and the logic
in QApplication::event's quit handling, but aligning that requires
more work than this particular fix, and should probably also be
based on using the return value of tryCloseAllWindows() directly.
Change-Id: I2555eeee0cb04b8e736109fed57f37150efd1964
Fixes: QTBUG-81107
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
|
|\|
| |
| |
| |
| |
| |
| | |
Conflicts:
src/corelib/kernel/qvariant.h
Change-Id: I8f3873e74b9795ac889e7c7ec5de2619bca92160
|
| |
| |
| |
| |
| | |
Change-Id: I4f350e3c209dc9a39e849c9c39c41da700abeb60
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
src/corelib/tools/qhash.cpp:2596: (qdoc) warning: clang found diagnostics parsing \fn template <class Key, class T> template <class InputIterator> QMultiHash::QMultiHash(InputIterator begin, InputIterator end)
error: 'QMultiHash' is not a class, namespace, or enumeration
src/corelib/kernel/qobject.cpp:4593: (qdoc) warning: Undocumented parameter 'EXPORT_MACRO' in QObject::Q_NAMESPACE_EXPORT
src/corelib/global/qfloat16.cpp:129: (qdoc) warning: Cannot tie this documentation to anything
src/corelib/text/qlocale.qdoc:1204: (qdoc) warning: Overrides a previous doc
src/corelib/text/qlocale.qdoc:1187: (qdoc) warning: (The previous doc is here)
src/network/kernel/qhostinfo.cpp:597: (qdoc) warning: clang found diagnostics parsing \fn QHostInfo(QHostInfo &&other)
src/printsupport/dialogs/qabstractprintdialog.cpp:346: (qdoc) warning: clang found diagnostics parsing \fn int QAbstractPrintDialog::exec(): error: out-of-line definition of 'exec' does not match any declaration in 'QAbstractPrintDialog'
src/testlib/qsignalspy.qdoc:101: (qdoc) warning: clang found diagnostics parsing \fn QSignalSpy(const QObject *obj, const QMetaMethod &signal): error: expected unqualified-id
src/testlib/doc/src/qttest-best-practices.qdoc:28: (qdoc) warning: Can't link to 'Q_VERIFY2()'
src/widgets/kernel/qactiongroup.cpp:291: (qdoc) warning: Undocumented parameter 'b' in QActionGroup::setExclusive()
src/widgets/kernel/qactiongroup.cpp:305: (qdoc) warning: Undocumented return value (hint: use 'return' or 'returns' in the text
src/widgets/kernel/qshortcut.cpp:542: (qdoc) warning: No such parameter 'context' in QShortcut::QShortcut()
src/widgets/widgets/qdatetimeedit.cpp:632: (qdoc) warning: No such parameter 'minimumTime' in QDateTimeEdit::setTimeRange()
src/widgets/widgets/qdatetimeedit.cpp:632: (qdoc) warning: No such parameter 'maximumTime' in QDateTimeEdit::setTimeRange()
src/widgets/widgets/qdatetimeedit.cpp:632: (qdoc) warning: No such parameter 'less' in QDateTimeEdit::setTimeRange()
Change-Id: I9799b5135e84c4d811674b2d114ef27315bc12df
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
|
|\|
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
.qmake.conf
src/plugins/platforms/xcb/qxcbscreen.cpp
src/widgets/accessible/qaccessiblewidget.cpp
Change-Id: Ib3138e61ba7981610940509a7ff02ba2dd281bf0
|
| |
| |
| |
| |
| | |
Change-Id: I88b36e800139389895ecb1a15553207a24b3e3a4
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| |
| |
| |
| |
| | |
Change-Id: I1f1be554a72a385985eeee0b79b49acdfcf40d8e
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The two static setPalette methods in QApplication and QGuiApplication
should have the same behavior in terms of what signals and events
they emit.
Change-Id: I54579d490e31f3783e2d4fea689ca799a070ff1d
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| |
| |
| |
| |
| | |
Change-Id: I7a8e6c0b54d2a16a17b292a4102e05f743bcbe29
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
|\|
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/network/ssl/qsslsocket.cpp
src/widgets/kernel/qapplication.cpp
Change-Id: Ib7421cc2df59d0969f89b3fbd65a17ea76ffef3b
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Its purpose was to track the default palette set by the programmer,
but after 8fb881900c this is tracked by the Qt::AA_SetPalette attribute.
The palette itself is always reflected 1:1 in the palette tracked
by QGuiApplicationPrivate::app_pal.
Change-Id: If3e84c8b3ae6070b6c50be7a33adb38799b3f3a5
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The only effect calling QApplication::setPalette will have is the polish,
so opt for doing it explicitly instead of the weirdly looking no-op
assignment.
Change-Id: Ia80b3f60e3e513b68c2993ea8417966f9ab6721e
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| |
| |
| |
| |
| | |
Change-Id: I9f01e7cc5fa90fd9b1f5d12c7ce694c231158c32
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
QApplication::setStyle has quite a bit of logic to clean up from the
old style before setting a new one. If a style has been set before
the application is created, it's not enough to just delete the existing
style, we need to treat it like a normal style switch.
Change-Id: I2bcc2eb75567bf1bc8a32ac31467b22315a70a0b
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A style may have been set before the application was created, which
would have resulted in setting the system palette based on the style's
palette. Once the application is initialized and we have a platform theme
we need to reset the system palette.
Change-Id: Ia48f57d3983535c8633741d8027f75bc0c214018
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We let initSystemPalette() do all the work, instead of leaving the first
time initialization of the system palette to the caller, which makes the
logic harder to follow.
This also means first time initialization of the system palette will
pick up a platform theme if available and resolve the palette using
that, which was missing from the original logic.
Change-Id: I84da557caf8ecedf6d96d87ebee93168ea9d73ba
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The call was added in c49c96fbb13912, "Reinitialize system palette
when setting a new style", but adding it along with the palette code
seems like a mistake. The potentially dirty widget font hash needs
to be reset for all style changes.
Change-Id: I411f56bb833819213c5485d7585fc5e3e9bd8983
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| |
| |
| |
| |
| |
| |
| | |
It is being deprecated.
Change-Id: If1b0b058140e197d41efae93025c4eefc2ed9bbd
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
|
|\|
| |
| |
| |
| |
| |
| | |
Conflicts:
tests/auto/network/kernel/qnetworkinterface/BLACKLIST
Change-Id: I1e8866c63b54bcd95fc2a044276ee15b7f60e79a
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Users that have large mouse pointers configured in their settings
can not see tooltips, as they are obscured by the pointer.
Native applications on Windows and macOS have the same problem,
which includes the tooltips for the minimize/maximize/close controls
in the window frame of e.g. Explorer.
Introduce QPlatformCursor::size that returns a value that is based
on the user's settings, or a default value. We can then use that
value to move the tooltip out of the way.
On Windows, the calculation of the cursor size is based on
experimenting with the settings, which are in logical independent
pixels. The placement of the tooltip attempts to keep existing
behavior, and to not end up with a tooltip that's very far away
from the tip of the arrow even for very large mouse cursors.
[ChangeLog][QtWidgets][QToolTip] Make sure that the tooltip
is not obscured by very large mouse pointers on Windows and macOS.
Change-Id: I8e13b7a166bfe8b59cef4765c950f90fefeaef9d
Fixes: QTBUG-79627
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The platform window may create or destroy its surface from other entry
points than the QWidget API, in which case QWidget needs to sync up
its own state to match. In particular WA_WState_Created and the winId
needs to be recomputed.
Fixes: QTBUG-69289
Fixes: QTBUG-77350
Change-Id: I769e58ead3c2efcf8c451c363108848feade9388
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Move away from using 0 as pointer literal.
Done using clang-tidy. This is not complete as
run-clang-tidy can't handle all of qtbase in one go.
Change-Id: I1076a21f32aac0dab078af6f175f7508145eece0
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|\|
| |
| |
| |
| |
| |
| | |
Conflicts:
src/corelib/serialization/qcborvalue.cpp
Change-Id: I675a3029955c96e81a33ed9d98b72b55b6784b52
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When the geometry of a hidden widget was set with setGeometry(),
WA_PendingMoveEvent and WA_PendingResizeEvent were set unconditionally
even if the crect already had the correct value. This lead to
unneeded Move/Resize events within sendPendingMoveAndResizeEvents().
Fixes: QTBUG-75475
Fixes: QTBUG-79906
Change-Id: Ibbe03882f039948b6b7c04887420741ed2e9c0f7
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Remove the include path for wintab which is no longer needed in Qt 5
(the code is in the QPA plugin).
Remove the inclusion of win.pri for the Windows vista styles plugin
and specify the theme library directly.
This should result in simpler CMakeList.txt files.
Change-Id: I736db5c965982cdf79a234a94fc723f0556c1717
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
QLayoutItem::widget() should be const since it does not modify the
class. Since this can not be done within Qt5 in a binary compatible way,
change it for Qt6.
Fixes: QTBUG-41997
Change-Id: I9211eb1c36a5bc4f06ab417a9df790ebedb7fcda
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
declaration
Set them to be designable by default, fixing:
kernel/qaction.h:66: Warning: Providing a function for DESIGNABLE in a property declaration is deprecated and will not be supported in Qt 6 anymore.
kernel/qwidget.h:178: Warning: Providing a function for DESIGNABLE in a property declaration is deprecated and will not be supported in Qt 6 anymore.
kernel/qwidget.h:179: Warning: Providing a function for DESIGNABLE in a property declaration is deprecated and will not be supported in Qt 6 anymore.
kernel/qwidget.h:180: Warning: Providing a function for DESIGNABLE in a property declaration is deprecated and will not be supported in Qt 6 anymore.
kernel/qwidget.h:181: Warning: Providing a function for DESIGNABLE in a property declaration is deprecated and will not be supported in Qt 6 anymore.
kernel/qwidget.h:182: Warning: Providing a function for DESIGNABLE in a property declaration is deprecated and will not be supported in Qt 6 anymore.
kernel/qwidget.h:204: Warning: Providing a function for DESIGNABLE in a property declaration is deprecated and will not be supported in Qt 6 anymore.
widgets/qabstractbutton.h:67: Warning: Providing a function for DESIGNABLE in a property declaration is deprecated and will not be supported in Qt 6 anymore.
widgets/qgroupbox.h:60: Warning: Providing a function for DESIGNABLE in a property declaration is deprecated and will not be supported in Qt 6 anymore.
The toolbar properties were not caught by the warnings, but it appears
the checks do not work; the properties are designable when parented
on a non-QMainWindow parent.
Change-Id: Ib7dfb878ba593f2dfa05b85db2c384bf3d860e46
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Fix include, removing:
QtWidgets WARNING qtbase/src/widgets/kernel/qtestsupport_widgets.h includes qtwidgetsglobal.h when it should include QtWidgets/qtwidgetsglobal.h
Change-Id: I3dc608cba48e9ae36b0683a94a4bf411e23f5136
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Amends qtbase/af2daafde72db02454d24b7d691aa6861525ab99.
Where applicable, port over to member initialization, thus also
fixing nullptr warnings.
Change-Id: Iaaf2dbbbcf2952253390b8839fd15a1b17be32c0
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This was used to support QFlags f = 0 initialization, but with 0 used
as a pointer literal now considered bad form, it had been changed many
places to QFlags f = nullptr, which is meaningless and confusing.
Change-Id: I4bc592151c255dc5cab1a232615caecc520f02e8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The menu bar size calculation didn't take into account the margin of the
layout content which makes said menu bar sticking out of the widget.
This patch includes the margin to ensure the menu bar has the correct
size.
Fixes: QTBUG-76585
Change-Id: Ia2c163137fa2889f4028ee3b31766b2747d97b72
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Provide pointer to member function overloads for the QShortcut ctor. The
ctor with two functors but no contexts is not provided since it creates
ambiguousness.
[ChangeLog][QtWidgets][QShortcut] QShortcut ctor has now pmf overloads
Fixes: QTBUG-77816
Change-Id: Ic9a759cde5150dbb94c2fd351b88ee8e447e0852
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QObjectPrivate::threadData used to be a QThreadData *, and was
read and written from multiple threads without proper synchronization.
As an example, it was read from QCoreApplication::postEvent and
written from QObject::moveToThread, therefore causing UB.
Port threadData to a proper atomic, removing the races. Fix all usage
points.
In general, QObject is documented to be simply reentrant,
not thread-safe, and certain bits (e.g. timers, moveToThread)
are not even reentrant. The reasoning therefore is that a given
QObject's threadData is not supposed to be touched by multiple
threads without some synchronization happening elsewhere, and
therefore relaxed loads should be sufficient.
As drive-by change: refactor QCoreApplication::postEvent.
It was particularly subtle, because it had a loop using a volatile
to cope with the possibility of the receiver object switching thread
while we tried to lock its thread's event queue.
However, volatile does not achieve any synchronization, so drop it,
and refactor the algorithm using better locking primitives.
Put this algorithm in a common place, and also reuse it from
removePostedEvents, which was lacking any synchronization.
Change-Id: Icc755f7eb418ff54b33db4bdd87fd8eaf4e82c7a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
.qmake.conf
mkspecs/features/mac/default_post.prf
src/corelib/tools/qsimd_p.h
src/platformsupport/fontdatabases/mac/qcoretextfontdatabase.mm
util/qfloat16-tables/gen_qfloat16_tables.cpp
Change-Id: If48fa8a3bc3c983706b609a6d3822cb67c1352a4
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When a window is closed, then it will cause the child windows to be
closed as well as a result. Therefore in order to ensure that they are
shown again as a result, we need to remove the WA_WState_ExplicitShowHide
attribute if the widget was not already hidden before. This enables us to
test for this attribute when calling showChildren(), so that if the
window has a windowHandle then we can make sure that this widget is shown
again.
Fixes: QTBUG-73021
Change-Id: I1186242b889899dfcd38d782a67567348e2055ee
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|\|
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/corelib/io/qstandardpaths_unix.cpp
src/corelib/tools/qsharedpointer_impl.h
tests/auto/corelib/tools/qsharedpointer/tst_qsharedpointer.cpp
Change-Id: Iae95c5778dc091058f16f6db76f04a0178a9e809
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Widgets might be destroyed when handling a dragMoveEvent, in which case
the following code will operate on dangling pointers or null pointers.
Use a QPointer to watch for the original event receiver to disappear,
and add the necessary checks for the objects we deliver events to being
null.
Change-Id: I4ca2f182540ae21113f4bea4e5c569e983cc58bf
Fixes: QTBUG-78907
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Instead of having each platform plugin deal with application termination
in their own weird ways, we now have a QPA API to signal that the system
requested the application to terminate.
On the QGuiApplication side this results in a Quit event being sent to
the application, which triggers the default behavior of closing all app
windows, and then finally calling QCoreApplication::quit().
The quit event replaces the misuse of a close event being sent to the
application. Close events are documented as being sent to windows.
The close events that are sent to individual windows as part of the
quit process can be ignored. This will skip the final quit() of
the application, and also inform the platform that the quit was
not accepted, in case that should be propagated further.
In the future the logic for closing windows should be unified
between the various approaches in closeAllWindows, shouldQuit,
and friends.
Change-Id: I0ed7f1c0d3f0bf1a755e1dd4066e1575fc3a28e1
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Prevent call to activateWindow() for minimized windows in
QWidget::setWindowState() by clearing the flag.
Fixes: QTBUG-46763
Change-Id: I40389d0906438ffe251fc79f18a523ecb53edb1b
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|