Duplicating the number of classes is a high price to pay to be able to
have some QAction functionality behave differently, or be only available
in widgets applications.
Instead, declare the entire API in QtGui in QAction* classes, and
delegate the implementation of QtWidgets specific functionality to
the private. The creation of the private is then delegated to the
Q(Gui)ApplicationPrivate instance through a virtual factory function.
Change some public APIs that are primarily useful for specialized tools
such as Designer to operate on QObject* rather than QWidget*. APIs that
depend on QtWidgets types have been turned into inline template
functions, so that they are instantiated only at the caller side, where
we can expect the respective types to be fully defined. This way, we
only need to forward declare a few classes in the header, and don't
need to generate any additional code for e.g. language bindings.
Change-Id: Id0b27f9187652ec531a2e8b1b9837e82dc81625c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
It's not possible anymore, since many years. The desktop's don't use the
X11 root window anymore :)
Fixes: QTBUG-82880
Change-Id: I923f29f23e61d93640cacb2ac20620c5ddc480b9
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
By sending it to all top level windows it will make it possible for
non widget based controls to listen for this event if it cares about it
so it can handle translation updates as appropriate.
Task-number: QTBUG-78141
Task-number: QTBUG-82020
Change-Id: I8f35cdcccd81a199ff780c3f4f3d2c663480d638
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
The idea is to reserve device() to return a pointer to a QInputDevice
in the future, which is in sync with QQuickPointerEvent::device()
and with QTouchEvent::device().
Change-Id: Ifda6e8aea72d5121955b31bdcbd91bf1bfa4cec4
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
When the tested widget has a focus proxy, then we should check if the
current focus widget is not the same as that focus proxy before setting
it to be the widget that gets focus. This ensures that when back-tabbing
from a widget like QDoubleSpinBox that it will not get stuck inside that
widget and will back-tab to the next correct one.
Fixes: QTBUG-81097
Change-Id: I3f689c7715da7f3ce8c3d2f616041528f5778a2f
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
When closing a popup (submenu) triggers closing another popup (the menu)
programatically it can happen that QApplicationPrivate::popupWidgets is
destroyed. Therefore we have to check if popupWidgets is still valid
after the focus change event was delivered.
Fixes: QTBUG-81222
Change-Id: Ide3a6897e43f389d396a80d8b158f7c8eb04e3aa
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@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>
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>
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>
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>
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>
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>
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 c49c96fbb1, "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>
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>
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>
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>
We want to ensure that the qt4D and qt4O members are still initialized
the same way whenever deprecated constructors are used; and we want to
be able to verify it using qDebug. So we merely suppress these
warnings.
Change-Id: Ic2e5f0dd6feeabe81f06f9c31693c550ac0781e3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Had to port a lot of caching temporaries, too. Decided to leave them as
crefs to unique_ptr to catch any mischief users may be doing with the
raw pointer instead (like deleting it).
Also fixed a use of 0 as nullptr (by standardizing on pointer-to-bool
conversion, as is done everywhere else in qwidget.cpp), and made one
impregnable if condition readable.
Change-Id: Ifdc240bf352c52de0bc3c186fa7a5f4cb2882dd0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Build docs for deprecated APIs conditionally, based on deprecation
version. Remove the docs of methods deprecated since 5.0.0, these
methods are not compiled anymore.
Change-Id: If9302eecc8b3fff4a27c2e4a66ac102add7d66c5
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Added QApplicationPrivate::keypadNavigationEnabled() as a
replacement of deprecated QApplication::keypadNavigationEnabled(),
for the internal usage.
Task-number: QTBUG-76491
Change-Id: I75f4c628b72d86b5e428e7e285a786d23abbf3f2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The public QWidget::create still has them, but we don't need to
propagate them on - that just makes debugging the window creation
flow harder.
The window argument to QWidget::create is technically used to
guard an early exit in the function, but to keep behavior the
same we leave it for now.
Change-Id: Ic0287575aa25f1272e216adc1b75e34d6f55f6d9
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
In Qt 5.0, delta() and orientation() were already marked obsolete,
but Widgets and tests have kept on depending on them all this time.
We now start using alternative API so they can really be deprecated.
All constructors except the newest one are also deprecated.
The plan is for all events from pointing devices to have
QPointF position() and globalPosition(), so we deprecate
the other position accessors.
[ChangeLog][QtGui] Obsolete constructors and accessors in QWheelEvent
now have proper deprecation macros. What is left is intended to be
compatible with planned changes in Qt 6.
Change-Id: I26250dc90922b60a6ed20d7f65f38019da3e139e
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Use the QSet QWidgetPrivate::allWidgets directly instead of
calling QApplication::allWidgets(), which allocates a QList.
Change-Id: I16d289030cecefae7811d4b2c94f865f46f700d5
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The old code used the implicit conversions from QAtomicPointer<T> to T*
and vice versa. The semantics of these differ from the ones std::atomic
uses, so we're going to deprecate these, like we did for load() and
store(), too.
This patch fixex some users of these APIs before we deprecate them.
Change-Id: I0a88bb1c359392538bb64b511bfc62381a56a468
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Apply fixits by Creator and results of manual search focusing on
QCore/Gui/Applicaton(Private) methods and variables to prepare for
splitting out some classes.
Task-number: QTBUG-69478
Task-number: QTBUG-76497
Task-number: QTBUG-76493
Change-Id: Iaf468166793e0cabb514b51c827b30317bf45a2d
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Explain why there are two accessor functions for the global statics,
and use the global statics directly inside qapplication.cpp for
consistency.
Change-Id: Ibf3952052c1d0e780a8aab220a72f05af0c070a5
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
initSystemPalette() already takes care of this.
Change-Id: I6521763a74ec3ec629d9fcf05aa2a7cd71a7f26d
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
initSystemPalette() already calls this when there's a platform theme, which
is the only case where initializeWidgetPaletteHash will have an effect.
Change-Id: I814ea2bb17ef40aee769f2c36f8ef4296cfca020
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Only uses a single place and avoids following the init logic through
multiple layers when trying to debug it.
Change-Id: I8fc119385edf407f69fb5431dc6584288022a7fe
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Volker Hilsheimer
Simon Hausmann
Andy Shaw
Shawn Rutledge
Qt Forward Merge Bot
Christian Ehrlicher
Tor Arne Vestbø
Liang Qi
Tor Arne Vestbø
Allan Sandfeld Jensen
Giuseppe D'Angelo
Marc Mutz
Sona Kurazyan
Friedemann Kleint