When we recreate a top level QWidget due to the RHI config not matching,
we need to re-apply the window state, as the state is lost on destroy().
But we should do this on the QWidget we are recreating, not on its
closest QWindow. These are usually the same, so it didn't matter in
practice for most cases (besides the more convoluted way of getting
to the QWidget's window).
But if the top level widget does not have a winId yet, the call to find
the closest QWindow via QWidgetPrivate::windowHandle() will traverse from
the top level widget to its transient parent widget, via nativeParentWidget,
which is strange and likely a bug.
As a result of that, we would store the window state of the transient
parent widget, and then, once we had created() the new top level, we
would apply the window state to the top level, which now had a winId.
We can simplify all of this by just storing and applying the window
state on the widget we are re-creating. There's no need to go via
the closest QWindow for this. We do however need to set the window
state on the widget's window, as going via QWidget will just bail
out since the window state hasn't changed.
Amends c88211d1e4
Fixes: QTBUG-119795
Pick-to: 6.7 6.6 6.5
Change-Id: I0ad6e7bbac5f29d095cc643e9a7094784e9a2122
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The call site may pass in a null-widget, so guard for that.
Pick-to: 6.7
Change-Id: I631cb2fc105bad69faf3daaeac4b893457d27cc1
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
As a result of using QWidget::setVisible to show the child widgets we
would end up also setting ExplicitShowHide. This is not in line with
the intent of ExplicitShowHide, which is to flag a widget as explicitly
shown/hidden by the developer, which in turn prevents Qt Widgets from
toggling WState_Hidden when the widget is reparented.
By using QWidgetPrivate::setVisible instead, we can show the child
without setting ExplicitShowHide.
As side effect of this is that we no longer reset WA_WState_Hidden
from QWidgetWindowPrivate::setVisible(). This is an issue when the
setVisible call comes as a result of destroying the QWidgetWindow,
as that is an implicit hide, and should not result in the widget
having WA_WState_Hidden. QWidget handles this case in hideChildren
by not calling QWidgetPrivate::setVisible -- instead doing its own
reset of WA_WState_Visible. We don't want to untangle this just yet,
so as a workaround we detect that the widget is already !isVisible(),
thanks to hideChildren having hidden it, and then skip the call
to QWidgetPrivate::setVisible that results from QWindow::destroy().
Task-number: QTBUG-121398
Pick-to: 6.7
Change-Id: Ib5b4d9c84f0569124c5f3ca2169cabff18934e2d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
To aid readability.
Task-number: QTBUG-121398
Pick-to: 6.7
Change-Id: I3cb231584c2b7aee72e9f01c669fed1e01fbe475
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
We were assuming that QWidget was in full control of QWidgetWindow
destruction, via deleteTLSysExtra(), and that we could limit any
cleanups to that function.
But in some situations QWidgetWindow is destructed from other code paths,
in which case we were left with dangling pointers to the QWidgetWindow
in both QTLWExtra, as well as the backingstore.
This can happen if there's a child widget hierarchy where there is not
a 1:1 mapping between QWidgets and QWindows, for example if the window
attribute WA_DontCreateNativeAncestors has been set. In this situation
our normal recursion into children in QWidget::destroy() stops at the
first widget without a window handle. When we then delete the top level
QWindow, the QWindow destructor will delete any child QWindows, which
includes our leaf QWidgetWindow.
We should probably fix up QWidget::destroy to continue looking for
children, even if we don't destroy the current child. But independently
of that we should make sure the QWidgetWindow cleans up when it's being
deleted, regardless of how it ended up there.
There's further room to clean up the deleteTLSysExtra() function and
friends, but that's been left for a later time.
Fixes: QTBUG-120509
Pick-to: 6.7 6.6 6.6.2 6.5
Change-Id: Ib691df164d7c9c83cb464c0a6bf3bc2116e8ca43
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Make sure to pass the widget to QStyle::pixelMetric() as some styles
might use this (e.g. the new windows styles) to determine the correct
pixel metric.
Pick-to: 6.7 6.6 6.5 6.2
Task-number: QTBUG-1857
Change-Id: I5c32f5af8b284749732b610e56b4e3d8c8ed1946
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: David Faure <david.faure@kdab.com>
The Qt::WindowState enum is documented to specify the current state of
top-level windows, and does not make sense for child windows. It's up to
the client code to ensure any sizing of child windows/widgets, e.g. via
layouts.
Many of our QPA backends bail out on QPlatformWindow::setWindowState()
for a child window. Ideally we would do this at a higher level, in
QWindow, but that's a bigger task, and the semantics of what happens
when a window is moved from being top level to child or back are not
fully clear.
As a first step, we ensure that the default window state when showing
the window via show() is Qt::WindowNoState.
Unfortunately, the QPlatformIntegration::defaultWindowState() API only
takes into account the window flags, which sadly do not have a way to
reflect whether the window is a child window or not (Qt::SubWindow is
not a child window, see QTBUG-115729).
We don't want to pass a QWindow to this API, as it would mean QWidget
would need to create a window when requesting the default window state.
Instead we hard-code the opt-out for child windows/widgets.
[ChangeLog][Gui/Widgets] Child windows and widgets are now always shown
in their normal state by show().
Pick-to: 6.7
Change-Id: Ie8caf2df2d854194b9985c9427a9eac1312aba65
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
The logic was needed for the old QMacCocoaViewContainer, which was a
QWidget, that set Qt::ForeignWindow, and hence Qt::Window, on its
windowHandle().
The modern way of embedding a foreign window into a widget hierarchy
is via QWindow::fromWinId() and QWidget::createWindowContainer(),
which manages the foreign window as a child QWindow of the window
container's window handle, instead of replacing or modifying the
window container's own window handle.
The opposite case is a QWidget embedded into a foreign/non-widget
window hierarchy. Ideally, in this case, we should return false for
isWindow(), as the function is documented to only return true for
"if the widget is an independent window", and "a window is a widget
that isn't visually the child of any other widget and that usually
has a frame and a window title". This notion is used in many places,
including in QApplication::topLevelWidgets(), which in turn affects
the quit logic of QApplication to prevent quitting the application
as long as the child/embedded widget is visible.
Unfortunately, embedding the widget as a non-Qt::Window is not an
option at this point, as we have a lot of code paths that assume
isWindow() || parentWidget(), and these code paths break down in
flames when we end up dereferencing the (non existing) parent
widget.
As a result of removing the logic, we can now embed a QWidget into
a non-widget window hierarchy as a Qt::Window, without the removed
logic resetting the widget back to a Qt::Widget on create(), which
would send us into into the broken code paths described above.
Removing this logic should not cause issues for child widgets backed
by a native window, as those are created with Qt::Widget window flags,
not Qt::Window, so we never relied on the removed logic to sanitize
those window flags.
Task-number: QTBUG-119652
Change-Id: Id6b8e5c67bf8f83af8c2f1594806f3419303b1a1
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The active window of QApplication overlaps largely with the focus window
of QGuiApplication. As a first step towards potentially removing the
active_window member, make it private so we control access to it.
Task-number: QTBUG-119287
Change-Id: I95785fea3ba4444db64063f4e4d3d3004465ef64
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Upcoming changes to QDoc require accurate definition for
template arguments in \fn commands.
Task-number: QTBUG-118080
Change-Id: I3a193ca69a911ee2f62e7663aaf4c032a35ee5dd
Reviewed-by: Luca Di Sera <luca.disera@qt.io>
Restore the WindowState, when a Window has to be recreated due to
changed SurfaceType.
Fixes: QTBUG-118194
Pick-to: 6.6 6.5
Change-Id: I40ba552cda9dfc8ab543611595c068f80b8fa1d6
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Reviewing and improving the docs for QWidget is part of the objectives
for the 2023 Q4 OKRs.
Most of the work in this patch is fixing grammatical errors and typos.
It is tempting to move much, if not all, of the Detailed Description content from the QWidget class reference page (qwidget.cpp) into its own overview/explanation page, which would be more in line with the diátaxis framework. But I think that should be a different patch.
Fixes: QTBUG-117758
Pick-to: 6.6 6.5 6.2 5.15
Change-Id: Ibb3f367c4677f7e6615bc0cd39d0ffe921862cb9
Reviewed-by: Safiyyah Moosa <safiyyah.moosa@qt.io>
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
Another one in the series of problems around having texture-based and
regular widgets in hierarchies where some widgets are native and some
are not.
Pick-to: 6.6 6.5
Fixes: QTBUG-115652
Task-number: QTBUG-108344
Task-number: QTBUG-113557
Change-Id: I34306503cb17ccb915b90168ec3f39e209f668e5
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Found in API-review.
Pick-to: 6.6
Change-Id: I261aa450d25288e7a3e8caa033ce5000e5dd77f2
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
The Android QPA implementation requires a 1:1 link between a platform
window and a platform backing store, to correctly flush a backing
store to the screen. QAndroidPlatformBackingStore has a bool member
m_backingStoreSet, to remember if this link exists. It defaults to
false and is set to true, when setBackingStore() is called in the
constructor. It falsely remains true, when a platform window is
deleted, e.g. because a QWindow has been hidden. When the QWindow is
shown again, a new Android platform window is created. With
m_backingStoreSet still being true, this new platform window will
never be associated with a backing store. As a consequence, it will
never be displayed on the screen.
The 1:1 relationship of an Android platform window and an Android
backing store is neither ideal, nor in line with other QPA layers
(e.g. XCB). Changing the Android QPA implementation is complex and a
short term fix is necessary.
This patch removes the member m_backingStoreSet. Instead of it,
QAndroidPlatformBackingStore::flush() directly checks, if the platform
window corresponding to the QWindow argument is associated to a backing
store. If that is not the case, setBackingStore() is called.
QTBUG-97482 has been fixed with another approach, which this patch
reverts.
The following commits are effectively reverted by this patch:
9a39ad8dfbf91588923ba4ca9e8065dbb072eb28959a8b3967
Fixes: QTBUG-97482
Pick-to: 6.6 6.5 6.2
Change-Id: Ic4344f8df2e954c057dd2705340f11dfd2d4c6fe
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
QWidget re-uses an existing backing store. Platform windows depend on
being associated to a backing store, in case they become toplevel
windows. If a platform window gets deleted and re-created each time it
is shown or hidden, it has to be manually associated to the re-used
backing store.
This patch partly reverts fbf0aeea7d3b38ced7a16fcd5c3e2e9b45536292.
It removes Android specific code from QWidgetPrivate::create(), which
has been added to suppress re-using backing stores in the absence of
the new API.
Fixes: QTBUG-97482
Pick-to: 6.6
Change-Id: Iaa1b7652efa120ec1955914c0383e8ccd8a41429
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
QWidget re-uses backing stores created in QWidgetPrivate::create().
The Android platform plugin creates a new platform window, when a
widget becomes a toplevel window. When it is hidden, the platform
window is deleted. The link between QAndroidPlatformWindow and its
backing store is made in the constructor of
QAndroidPlatformBackingstore. When a new QAndroidPlatformWindow is
constructed and the backing store is re-used, there is no more link
between platform window and platform backing store.
This has lead to screen assets not being painted, when shown more than
once.
This patch forces QWidgetPrivate::create() to construct a new backing
store on Android. This way, toplevel windows always have a backing
store associated with it. It adds an assertion to
QAndroidPlatformScreen::addWindow(). That will make e.g.
tst_QWidget::visible() crash without the fix.
Fixes: QTBUG-97482
Pick-to: 6.6 6.5 6.2
Change-Id: Ib1b172068b03549df161ab93ac24a273221d5423
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Correct the typo inherts to inherits in QWidget::backgroundRole() docs,
as it is incorrect english.
Fixes: QTBUG-115160
Change-Id: I03892753d6ec7d81c1f818fd9caa279ca11cc3ec
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QWidgetPrivate::focusObject() always returns nullptr. That has lead to
mismatches between QGuiApplication::focusObject() and
QApplication::focusWidget(), when a widget got focus by the window
system (e.g. mouse click).
This patch implements QWidgetPrivate::focusObject.
It returns the current widget, if it doesn't have a focus proxy.
If it has a focus proxy, it resolves the proxy chain and returns the
deepest focus proxy.
(Note: It does not return QWidget::focusWidget(), because the focus
widget might not yet have been set, when the method is called).
Fixes: QTBUG-92464
Fixes: QTBUG-108522
Pick-to: 6.6 6.5 6.2
Done-With: Liang Qi <liang.qi@qt.io>
Change-Id: Icf01e8ac4fc5f722fbf8e0ca5a562617ae9ae8f2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Liang Qi <liang.qi@qt.io>
The Qt Widgets Application example was moved to manual tests,
and no longer contains the snippet identifiers. Fix \snippet
and \quotefile commands to quote similar code snippets from
other examples or snippet files.
Fix also the following documentation warnings:
* No such parameter 'parsingMode' in QUrl::fromEncoded()
* Missing image: rsslisting.cpp
Pick-to: 6.6 6.5
Change-Id: Ibc989e83abc49837db08628facaf8e5f72b2f123
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Rename it to "Translucent Background", as that's what the example shows
how to do. And modern applications shouldn't use a (binary) mask to
create shaped windows. Instead, set the TranslucentBackground attribute,
don't paint pixels that should be fully transparent and use anti-aliased
or semi-opaque painting for pixels that should be translucent.
Adjust the example and documentation accordingly. Move the statment that
widget masks create coarse visual clipping to the QWidget::setMask
documentation.
Pick-to: 6.5
Change-Id: Id49d854093f2cb471afb178d32723081c7543543
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
b1802a164b added handling for a parent to
become focus proxy of a child. The respective 'else if' branch didn't
check whether setFocusProxy() was called with a nullptr argument.
This patch adds the missing nullptr check.
It also adds functionality to tst_QWidget::tabOrderComboBox() to test
the removal of a focus proxy, as well as the complete removal of an
element from the focus chain.
Change-Id: I4cb865b9ac4497fc5e2595910738fb77694f5837
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
When a parent became a new child's focus proxy in an existing focus
chain, the child was appended at the end of the chain.
That leads to broken tab order, e.g. with a QComboBox which became
editable after a focus chain has been set.
This patch captures the case and insertes the new child after its
parent in the focus chain.
A corresponding test function is added in tst_QWidget.
Fixes: QTBUG-111978
Pick-to: 6.5
Change-Id: I3a426c0560fa830b7b7ffead54f26dd0adef499f
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The "two widgets at a time" API to set the tab order is awkward and
easily misused (as the documentation explicitly explains). Add an inline
overload that takes an initializer_list, and call the existing function
for each consecutive pair of widgets in the list.
Add documentation with snippet, and a test.
Change-Id: I8e6f14a242866e3ee7cfb8ecade4697d6bdfb4d4
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
On some platforms, such as Wayland (and also eglfs), manual window
positioning is not supported. Since this has caused confusion in the
past, we add a note to the documentation.
Pick-to: 6.2 6.5
Fixes: QTBUG-86780
Change-Id: Idf8dcdfad8ccfb9eb0f704fce05216562e433e20
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Previously the widget stayed black and we printed
"QBackingStoreDefaultCompositor: the QRhi has changed unexpectedly,
this should not happen".
To make it work the compositor is recreated in addition to the rhi
and the widgets are informed with the internal events.
Change-Id: I982d08bd3530478fe0f827080154c008a92a812e
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
If a composite widget is put behind one of it's contained children via
QWidget::setTabOrder, then our logic might replace the composite widget
with the contained child. In that case, we'd end up with a broken tab
chain, possibly resulting in incomplete clean-ups and triggering asserts
when shutting down the UI.
Handle this by stopping the last-child searching logic at the respective
other widget, and by not allowing both widgets to be the same.
Augment test case, and apply some minor refactoring to the code.
Pick-to: 6.5 6.2
Change-Id: I7d97dfa85315b6c01daa283253025d94a1727048
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
It is essentially the same as the other mainwindow examples, showing
how to create a text editor. The only special code here is the tiling of
the different main windows, which - without any documentation or
explanation - is neither very helpful, nor relevant in 2023.
Pick-to: 6.5
Change-Id: I48b92b1cf057f586e0d2842d1c0a3312154e9a13
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
It's been a while since we had a single Tutorial for all of Qt.
Pick-to: 6.5
Change-Id: I7317291c445c09b0bf728513670b6a575dd536bc
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
There is a mix between screen device pixel ratio. Currently we store the
property on a per-window basis, but the change notifications are still
on a per screen basis which can fall apart on edge cases.
On wayland we are getting per window DPR changes without as useful
screen change events so it's important to fix. It also has potential to
clean up the Windows backend in the future where the backend is
currently papering over the two concepts.
This patch introduces two new events:
A QWindowSystemInterface to trigger a window DPR change
independently of a screen change.
An event to notify windows the new DPR rather than needing to track
signals on the screen. This happens either when the window dpr changes
or implicitly through a screen change. This can deprecate an existing
event ScreenChangeInternal so the value is reused and renamed for
clarity.
Change-Id: I637a07fd4520ba3184ccc2c987c29d8d23a65ad3
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
\internal needs to be on its own line, otherwise qdoc doesn't know what
\a means.
Pick-to: 6.5
Change-Id: Ie7bd2fd779540b8d7ea92f9d1dd94e73a771d2b6
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Linking to 'Drag and Drop' target will link to a page local to Qt
Widgets with that section title. The intention is to link to the
topic page located in Qt GUI module.
Add a descriptive keyword to the correct target page and use that
for linking.
Pick-to: 6.5 6.4 6.2
Fixes: QTBUG-109289
Change-Id: Ib6a39b43f9080cf5bb72fb07ab163e75eefb4da9
Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
If a widget's geometry is restored to a screen, which is smaller than
the one it was saved from,
- the widget could appear (partly) off screen
- the widget's title bar and resize handles could be inaccessible
This patch refactors and documents checkRestoredGeometry.
In a first step, the restored geometry's size is checked against
a given screen size. It is corrected if necessary.
In a second step, the restored geometry is moved inside the screen,
if necessary.
It makes the function a static member of QWidgetPrivate in order to
expose it for auto testing and adds a respective test function to
tst_QWidget.
Fixes: QTBUG-77385
Fixes: QTBUG-4397
Task-number: QTBUG-69104
Pick-to: 6.5 6.4
Change-Id: I7172e27bfef86d82cd51de70b40de42e8895bae6
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Use static_cast to convert a QEvent to a QKeyEvent,
replacing (QKeyEvent*)e
Change-Id: I52ac3f46aec42600251cf737db2e71c04f2b45c7
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Most code uses the window/backing store DPR, except for this path that
uses the screen.
On wayland it's possible to get a different ratio for the screen and
window which causes some subtle rendering issues. For other platforms
behavior shouldn't change.
Change-Id: Ie390ba3bdfc183815df9e7e79e508d3e15d61f25
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
This effectively reverts a4a51f6a64
while solving the problem that change intended to fix by an
alternative approach: Swap the order of checks for rhi-based
flushing. Checking the widgets' wishes first was a mistake. We should
first check what is forced, e.g. via the env.vars. Then only move on
investigating the child widget hierarchy if there was nothing specific
requested.
This way having a QOpenGLWidget in a window and running with
QT_WIDGETS_RHI=1 QT_WIDGETS_RHI_BACKEND=vulkan will prioritize the
forced request (Vulkan) and so the QOpenGLWidget will gracefully not
render anything while printing the expected warning to tell what's
going on.
The expensive recursion plaguing the construction of larger widget
hierarchies is now avoided, that should no longer take seconds due to
walking the entire widget hierarchy of the top-level window every time
a new widget is added to it.
However, this then uncovered a set of problems concerning native child
widgets. The repaint manager seems to have an obvious mistake where
the usage of rhi (and so textures and whatnot) is decided based on
'widget' (which is either a top-level or a native child) instead of
'tlw' (which is the top-level with the backingstore). The usesRhiFlush
flag only really matters for a real top-level, not for native child
widgets. The rhi-based flushing is tied to the backingstore, and the
backingstore comes from the top-level widget.
Finally, make the qopenglwidget autotest to actually exercise
something when it comes to QOpenGLWidgets (or their ancestors) turned
native. The original code from a long time ago does not really test
native child widgets, because it turns the top-level into native which
is quite superfluous since the toplevel is backed by a native window
(and a backingstore) anyway.
Pick-to: 6.4
Task-number: QTBUG-105017
Fixes: QTBUG-108344
Fixes: QTBUG-108277
Change-Id: I1785b0ca627cf151aad06a5489f63874d787f087
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
When a compound widget is created not directly before its children,
then another widget will be in the focus chain between the compound and
the compound's first child. If one of those children is then made the
focus proxy of the compound, then the widget in between becomes
unreachable by tabbing.
To fix this, detect that we set the focus proxy to be a descendent of
the compound widget, and then move the compound widget directly in front
of its first child in the focus chain. This way we can't have any gaps
in the focus chain.
Augment the test case with a corresponding scenario. As a drive-by, move
the debug helper up in the code so that it can be easier used, and set
object names on relevant widgets.
Pick-to: 6.4 6.2 5.15
Fixes: QTBUG-89156
Change-Id: I17057719a90f59629087afbd1d2ca58c1aa1d8f6
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
This reverts commit 79a11470f3, which
resulted in QTBUG-105735. The new behavior is worse and affects multiple
screen readers, while the old issue is isolated to Windows Narrator and
could be considered a narrator bug.
Task-number: QTBUG-105735
Pick-to: 6.2 6.4
Change-Id: Ic8be1dbd592a3fdf2c3219ec4c5524bc2c7f0f6a
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
-1 is the default value for QSurfaceFormat::alphaBufferSize. Changing it
to 0 may result an unexpected pixel format change by ARB OpenGL
extension.
Pick-to: 6.4
Fixes: QTBUG-107629
Change-Id: Ia6a1b90fba6c43b6872b406f4fd946d937135cf8
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
We've been requiring C++17 since Qt 6.0, and our qAsConst use finally
starts to bother us (QTBUG-99313), so time to port away from it
now.
Since qAsConst has exactly the same semantics as std::as_const (down
to rvalue treatment, constexpr'ness and noexcept'ness), there's really
nothing more to it than a global search-and-replace, with manual
unstaging of the actual definition and documentation in dist/,
src/corelib/doc/ and src/corelib/global/.
Task-number: QTBUG-99313
Change-Id: I4c7114444a325ad4e62d0fcbfd347d2bbfb21541
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Tor Arne Vestbø
Christian Ehrlicher
Topi Reinio
Wladimir Leuschner
Andreas Eliasson
Liang Qi
Laszlo Agocs
Axel Spoerl
Keith Kyzivat
Volker Hilsheimer
Eskil Abrahamsen Blomfeldt
David Redondo
David Edmundson
Jan Arve Sæther
Tasuku Suzuki
Lu YaNing
Peter Varga
Marc Mutz