| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Fixes: QTBUG-109289
Change-Id: Ib6a39b43f9080cf5bb72fb07ab163e75eefb4da9
Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
(cherry picked from commit 8a30b22930d3a3d15fba97ff7aec7f812721869e)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
This is a 6.4 re-run of the script we ran in dev, in order to avoid
conflicts between the branches when cherry-picking.
Change-Id: I5eca3df3179dfb2b2682c75a479ba9a4259cc703
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the same semantic patch (qt-port-to-std-compatible-api V5
with config Scope: 'Container') as in dev. I've re-ran it in 6.4 to
avoid cherry-pick conflicts.
Like in dev, added two NOLINTNEXTLINEs in tst_qbitarray and
tst_qcontiguouscache, to avoid porting calls that explicitly test
count().
Change-Id: I9621dee5ed328b47e78919a34c307105e4311903
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This effectively reverts a4a51f6a641f4bf0a863251d6d3e026d81de6280
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.
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>
(cherry picked from commit 244daf4cfc44587c8c7c87e481688e840cc21c77)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_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.
Fixes: QTBUG-89156
Change-Id: I17057719a90f59629087afbd1d2ca58c1aa1d8f6
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
(cherry picked from commit 46648436d4dae529b81f5d7a987c0016cf54bf6d)
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 79a11470f3c4c61951906223f97001a77ce36500, 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
Change-Id: Ic8be1dbd592a3fdf2c3219ec4c5524bc2c7f0f6a
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
(cherry picked from commit d300a0fe765259d490c3510c9e2a8bac58e0aa15)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
-1 is the default value for QSurfaceFormat::alphaBufferSize. Changing it
to 0 may result an unexpected pixel format change by ARB OpenGL
extension.
Fixes: QTBUG-107629
Change-Id: Ia6a1b90fba6c43b6872b406f4fd946d937135cf8
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
(cherry picked from commit 600752aa972d1e46792e18f1ec6dd0b519722e65)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From 6.3 onward, hiding a widget doesn't automatically clear
QT::WA_UnderMouse attribute.
This leads to multiple buttons drawn with highlighted rectangle at the
same time (refer bug). The behavior is observed after
commit 0246bfd40a2cc5ea9cfc035146e6dd865b334c68 made as part of
bug QTBUG-53286.
This patch clears WA_UnderMouse attribute in widget hideChildren() and
subsequently, widgets that are hidden will not inherit this attribute
on the next show operation.
The attribute will be set only when the widget is under mouse cursor.
Fixes: QTBUG-104805
Change-Id: I4988eb72577fd557a328fd08bb09fa2fbded3138
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 82e7ac23a035a1c034d2ed665ecaeeb72914b715)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
| |
Fixes: QTBUG-105017
Change-Id: If5826172efb53b6df15dd3b7ba91b09d733cc77f
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
(cherry picked from commit a4a51f6a641f4bf0a863251d6d3e026d81de6280)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem is reported in combination with the new 6.4 way of
handling texture-based widgets, but this looks like something that has
always been missing:
Setting WA_TranslucentBackground changes the QWidgetWindow's format,
and this is done upon calling setAttribute(). That's good for most
cases, but the changes to the QWindow's format are lost when the
window is destroyed and then the widget gets another window
later. This is not that common, but can happen.
For example, if a top-level widget is parented under something else,
and then later it is parented to null again, so that it is toplevel
once again, background transparency can be lost because nothing
re-evaluates the WA_TranslucentBackground flag after the initial
setAttribute(), and so the widget's second QWidgetWindow is not set up
accordingly (because this new QWindow may not have alpha specified in
the QSurfaceFormat which may or may not be a problem, depending on the
platform / windowing system)
The simple solution is to evaluate the attribute not just when setting
it, but also when a new QWidgetWindow is created for the widget.
Fixes: QTBUG-104952
Change-Id: I92746caea5561544f90395d5473ac28d43143924
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 856bb38eafcf55113a3debbdd6905dc71600cc61)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Smooth scaling of icons etc. give far better visual results,
particularly with fractional dpr scaling. So enable this generally in
QStylePainter, and make more of the relevant widgets use QStylePainter
instead of QPainter directly.
Differences can be seen in the widgets examples, e.g. textedit,
gallery, stylesheet (Pagefold), mdi.
Task-number: QTBUG-96223
Fixes: QTBUG-101058
Change-Id: I3c34a455d097e5f6a6a09d3b020528b4fbda4d85
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit c78ec505293ed576779c0ee7342746cde39281d6)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In Qt 6.3, a check for WA_InputMethodEnabled was removed
in QWidget, to support IM queries also for read-only
widgets (7c6e4af48). This caused a regression on iOS, which
made the input panel open for widgets that didn't support
IM at all.
A patch was merged that solved the regression (3b12305575),
but it didn't take the widget attribute into account.
Since not doing so has the potential to cause regressions,
this patch will modify the affected code once more, so that
we instead fall back to test WA_InputMethodEnabled when
ImEnabled is not implemented. This will match closely
to the way ImEnabled was implemented in Qt 6.2.
Since we, with this change, now require that either ImEnabled
or WA_InputMethodEnabled is set, our own input widgets will
fail to support IM text selection when they're read-only, since
they actually don't implement ImEnabled.
This patch will therefore also make sure that we do so.
Task-number: QTBUG-104527
Change-Id: I70ad910aec38d0a74f4dd7d3115d3c45c16d2b3b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit e44edaac2c575df9b2f065b18b716cb21a0c2b75)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A new property Qt::ImEnabled was added in Qt 5.3.
Since the already existing widgets with IM support
(3rd party included) didn't implement this property,
QWidget got the fall back logic that if a widget
was queried for Qt::ImEnabled, and the returned QVariant
was invalid (the widget didn't implement it), we
would, for backwards compatibility with Qt 4, return "true"
(meaning that the widget supports IM).
But a side effect from this fallback logic, is that now
any widget that doesn't implement ImEnabled (or input
methods at all) report that they support IM. This will
confuse platforms like iOS, which uses ImEnabled to decide
if the input panel should show, and if text selection tools
should be enabled. The result is therefore that if you click
on a QPushButton, the input panel will open.
This patch will implement a more careful strategy to check if
a widget implements IM, if ImEnabled is missing. Rather than
saying that all widgets that don't implement ImEnabled supports
IM, we now require that the widget also returns a valid QVariant
for Qt::ImSurroundingText. We assume then, that a widget that
doesn't do so will anyway not be in need of input method support
from the platform.
Fixes: QTBUG-104527
Change-Id: Ib391fd1daae92c4325e9ccb59730fbdd7c9328fc
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit 3b123055755db3f11bd64b276a8f92fe39cf0e1e)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a window becomes active, then the accessibility system gets informed
about that already. Qt puts focus on the focus child of the activated
window afterwards, and if this emits another accessibility event, then
accessibility clients like Windows Narrator will stop reading the
activated window, and instead read about the focused widget.
This makes dialogs like message boxes poorly accessible.
Accessibility clients already know that a window became active, and can
query Qt about the focused child within that window.
Amend test case.
Fixes: QTBUG-101585
Change-Id: I2d6bff7c415a6f29c4a4f7f4e4be38079fb976ca
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
(cherry picked from commit 79a11470f3c4c61951906223f97001a77ce36500)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
| |
Change-Id: Iee4bd8970810be1b23bdba65a74de912401dca65
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
(cherry picked from commit f53f7095044275767e389d16aabad5ff7144ec9f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Enable by setting QT_WIDGETS_HIGHDPI_DOWNSCALE=1 and QT_WIDGETS_RHI=1.
This will make the backing store and painter operate at the next
highest integer DPR in cases where QWindow::devicePixelRatio() returns
a fractional value. The backing store image will then be downscaled
to the target DPR at flush time, using the RHI flush pipeline.
[ChangeLog][QWidgets] Added experimental support for always
painting at an integer device pixel ratio (rounding the DPR up if
necessary), followed by a downscale to the target DPR.Enable by setting
QT_WIDGETS_HIGHDPI_DOWNSCALE=1 and QT_WIDGETS_RHI=1.
Task-number: QTBUG-86344
Change-Id: Id5b834a0e3499818b0b656161f5e0c38a6caa340
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
(cherry picked from commit 79bead6c3b507331614dcc3c789e18438bc10395)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
|
|
|
|
| |
Change-Id: I597d5cbdddf4a2fbbe8b9de2ae252cdeadce9d11
Reviewed-by: Thorbjørn Lund Martsum <tmartsum@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use the widget screen dpr in calculations rather than
qApp->devicePixelRatio(). The screen may have been
directly set (without the window handle being initialized)
Task-number: QTBUG-103309
Task-number: QTBUG-49663
Task-number: QTBUG-101947
Task-number: QTBUG-102982
Change-Id: I2af2073640b171baf68575e3bc93b29b6a9a471d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
When drawing widgets with graphics effect using repaint manager,
if we do not combine the effect region some child widgets are not
affected by the graphics effect since they are not included in the dirty
region. However always using region bounds breaks the referenced bug use case.
Fixes: QTBUG-102374
Pick-to: 6.3 6.2 5.15
Change-Id: Iaf4eaba34db863500a0600b344e5062f2b36b9bf
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Task-number: QTBUG-67283
Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
|
|
|
|
|
|
|
|
| |
These debug statements come from the Nokia import and it seems unlikely
that they are being used at all.
Change-Id: I3143f83b0acdc5130fb743808003a55b789f2398
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-98434
Change-Id: I310ea8f19d73a79d985ebfb8bfbff7a02c424360
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes mocs_compilation.cpp empty again, removing those moc files
that were added after the last sweep in 2016,
0e6ad275498dc8cc60a7d163bac9ed0add8e48d5.
Including moc files directly into their classes' TU tends to improve
codegen and enables extended compiler warnings, e.g. about unused
private functions or fields.
Pick-to: 6.3 6.2 5.15
Task-number: QTBUG-102886
Change-Id: Iee35e82d18690469ad889f9b4a7394e706fe037d
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the active QWidget gets destroyed, then QWidgetWindow::focusObject
will return nullptr. If then no other object takes focus, then we'd
never emit change signals, and QGuiApplication's _q_updateFocusObject
(which then informs the input context and emits signals) didn't get
called. This left the input context with a dangling focus object
pointer, which resulted in crashes.
If the QWidget clears its focus, but the corresponding window doesn't
know that it had focus, then fall back to the widget's focus widget
to see if we have a change in focus, so that signals get emitted.
Add a test case that shows that we didn't call _q_updateFocusObject
by counting emissions of the QGuiApplication::focusObjectChanged
signal, which we emit in this function. The signal is emitted more
than once both when showing a widget, and now also when destroying
a widget that has a focus child. The former is a previous issue,
the latter is an improvement to not emitting the signal at all.
Pick-to: 6.3 6.2
Fixes: QTBUG-101423
Fixes: QTBUG-101321
Change-Id: Ib96a397211d442f52ce795a3eebd055a0ef51b0d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is from a fix unrelated to the recent rhi-based composition
work, which means it still had to enclose the block in an ifdef
due to the variables being only present in OpenGL-enabled builds.
Now with the other patches in place, the variables are no longer
conditional, and the similar ifndef QT_NO_OPENGL checks are already
gone pretty much everywhere so the ifdef is not needed here either.
Change-Id: I497c7a4fad7cd7d8fc1a479e7032de3e2cbb3b32
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was lost when QtCore, QtGui and QtWidgets were split up. Restored
now via a virtual function on QObjectPrivate.
Chose to return std::string instead of QString or QByteArray because
its SSO is usually sufficient to hold these flag strings.
[ChangeLog][QtCore][QObject] Restored printing of Qt3-style
information from dumpObjectTree().
[ChangeLog][QtWidgets][QWidget] Restored printing of Qt3-style
information from QWidget::dumpObjectTree().
Fixes: QTBUG-101732
Change-Id: I39ff5728ea5f5abbdbf81b5d7e13b8d16b6ee8b7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
|
|
|
|
|
|
|
|
| |
Pick-to: 6.3 6.2
Change-Id: I136b486d30e31acadd6b1b837dc7e834ee3e23fb
Fixes: QTBUG-101620
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QPlatformTextureList holds a QRhiTexture instead of GLuint. A
QPlatformBackingStore now optionally can own a QRhi and a
QRhiSwapChain for the associated window. Non-GL rendering must use
this QRhi everywhere, whereas GL (QOpenGLWidget) can choose to still
rely on resource sharing between contexts. A widget tells that it
wants QRhi and the desired configuration in a new virtual function in
QWidgetPrivate returning a QPlatformBackingStoreRhiConfig. This is
evaluated (among a top-level's all children) upon create() before
creating the repaint manager and the QWidgetWindow.
In QOpenGLWidget what do request is obvious: it will request an
OpenGL-based QRhi. QQuickWidget (or a potential future QRhiWidget)
will be more interesting: it needs to honor the standard Qt Quick
env.vars. and QQuickWindow APIs (or, in whatever way the user
configured the QRhiWidget), and so will set up the config struct
accordingly.
In addition, the rhiconfig and surface type is (re)evaluated when
(re)parenting a widget to a new tlw. If needed, this will now trigger
a destroy - create on the tlw. This should be be safe to do in
setParent. When multiple child widgets report an enabled rhiconfig,
the first one (the first child encountered) wins. So e.g. attempting
to have a QOpenGLWidget and a Vulkan-based QQuickWidget in the same
top-level window will fail one of the widgets (it likely won't
render).
RasterGLSurface is no longer used by widgets. Rather, the appropriate
surface type is chosen.
The rhi support in the backingstore is usable without widgets as well.
To make rhiFlush() functional, one needs to call setRhiConfig() after
creating the QBackingStore. (like QWidget does to top-level windows)
Most of the QT_NO_OPENGL ifdefs are eliminated all over the place.
Everything with QRhi is unconditional code at compile time, except the
actual initialization.
Having to plumb the widget tlw's shareContext (or, now, the QRhi)
through QWindowPrivate is no longer needed. The old approach does not
scale: to implement composeAndFlush (now rhiFlush) we need more than
just a QRhi object, and this way we no longer pollute everything
starting from the widget level (QWidget's topextra -> QWidgetWindow ->
QWindowPrivate) just to send data around.
The BackingStoreOpenGLSupport interface and the QtGui - QtOpenGL split
is all gone. Instead, there is a QBackingStoreDefaultCompositor in
QtGui which is what the default implementations of composeAndFlush and
toTexture call. (overriding composeAndFlush and co. f.ex. in eglfs
should continue working mostly as-is, apart from adapting to the
texture list changes and getting the native OpenGL texture id out of
the QRhiTexture)
As QQuickWidget is way too complicated to just port as-is, an rhi
manual test (rhiwidget) is introduced as a first step, in ordewr to
exercise a simple, custom render-to-texture widget that does something
using a (not necessarily OpenGL-backed) QRhi and acts as fully
functional QWidget (modeled after QOpenGLWidget). This can also form
the foundation of a potential future QRhiWidget.
It is also possible to force the QRhi-based flushing always,
regardless of the presence of render-to-texture widgets. To exercise
this, set the env.var. QT_WIDGETS_RHI=1. This picks a
platform-specific default, and can be overridden with
QT_WIDGETS_RHI_BACKEND. (in sync with Qt Quick) This can eventually be
extended to query the platform plugin as well to check if the platform
plugin prefers to always do flushes with a 3D API.
QOpenGLWidget should work like before from the user's perspective, while
internally it has to do some things differently to play nice and prevent
regressions with the new rendering architecture. To exercise this
better, the qopenglwidget example gets a new tab-based view (that could
perhaps replace the example's main window later on?). The openglwidget
manual test is made compatible with Qt 6, and gets a counterpart in form
of the dockedopenglwidget manual test, which is a modified version of
the cube example that features dock widgets. This is relevant in
particular because render-to-texture widgets within a QDockWidget has
its own specific quirks, with logic taking this into account, hence
testing is essential.
For existing applications there are two important consequences with
this patch in place:
- Once the rhi-based composition is enabled, it stays active for the
lifetime of the top-level window.
- Dynamically creating and parenting the first render-to-texture
widget to an already created tlw will destroy and recreate the tlw
(and the underlying window). The visible effects of this depend on the
platform. (e.g. the window may disappear and reappear on some,
whereas with other windowing systems it is not noticeable at all -
this is not really different from similar situtions with reparenting
or when moving windows between screens, so should be acceptable in
practice)
- On iOS raster windows are flushed with Metal (and rhi) from now on
(previously this was through OpenGL by making flush() call
composeAndFlush().
Change-Id: Id05bd0f7a26fa845f8b7ad8eedda3b0e78ab7a4e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Even QtCore alone cannot be built without the properties feature since
Qt 5.5. While fixing this is easy, other modules like dbus,
networking are also using QObject::property() and friends liberally.
All in all I doubt that anybody will miss the feature (otherwise it
would have been fixed in the last decade).
Change-Id: Iaf3cc20bda54ee2ff3b809fac8fa82b94ecc88c0
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Widgets embedded in a graphics view via QGraphicsProxyWidget don't have
an associated screen, even though they are top level windows in the
widget hierarchy.
Their screen has to be based on the screen of the toplevel widget they
are embedded in. This fallback is taken care of by QWidget::screen
already.
Task-number: QTBUG-20531
Pick-to: 6.3
Change-Id: I77af092b2f8e6322662499be464eec40cfd9ac1c
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QWidget and QWindow use bits in QObjectPrivate to provide for a couple
of shortcuts -- one in qobject_cast, and another in the isWidgetType() /
isWindowType() functions in QObject. These can be optimized by simply
looking at the bits, without actually doing more expensive runtime
casts.
These bits were set on construction, but not unset on destruction. The
result was for instance that destroying a QWidget would report that the
object was still a QWidget when ~QObject was reached.
Fix this
1) by setting the bits only when QWidget / QWindow constructors start;
2) by resetting the bits once ~QWidget / ~QWindow are completed.
Technically speaking this is not 100% correct in the presence of data
members, but luckily those classes don't have any.
Amend an existing test for QWidget (whose comment said exactly the
opposite of what the test actually did) and add a test for QWindow.
Some other code was wrongly relying on isWidgetType() returning true
for destroyed QWidgets; amend it as needed.
[ChangeLog][QtCore][QObject] Using qobject_cast on partially constructed
or destroyed QWidget/QWindow instances now yields correct results.
Similarly, using the convenience isWidgetType() / isWindowType()
functions now correctly return false on such instances. Before,
qobject_cast (and the convenience functions) would erroneously report
that a given object was a QWidget (resp. QWindow) even during that
object's construction (before QObject's constructor had completed) or
destruction (after QWidget's (resp. QWindow's) destructors had been
completed). This was semantically wrong and inconsistent with other ways
of gathering runtime type information regarding such an object (e.g.
dynamic_cast, obj->metaObject()->className() and so on).
Pick-to: 6.3
Change-Id: Ic45a887951755a9d1a3b838590f1e9f2c4ae6e92
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A widget (e.g QLineEdit) will set WA_InputMethodEnabled to
false if it's read-only. But it can still contain selected
text (e.g from a mouse drag). In many cases, it therefore
makes sense to be able to query the focus object for what
that selection is, e.g to be able to show selection handles
from the QPA plugin (iOS/Android).
Therefore, remove the check if a widget has WA_InputMethodEnabled,
and always process the query. The caller can always check this
flag himself (or Qt::ImEnabled) before sending the query, if needed.
Task-number: QTBUG-91545
Change-Id: Ia3dfa289283b5c157ba47cf0b508f9fddadd2861
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Calculate effect bounds for the updated region when drawing the effect
so that the whole affected area gets updated. The effect bounds have
already been added to the region so it doesn't need to be handled in
the drawing function.
Pick-to: 6.2 5.15
Fixes: QTBUG-96240
Change-Id: I0c317311622e6299fb1a3015541408d1d83c93de
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
| |
It was a leftover from when the quitOnClose logic was duplicated in the
handleClose function.
Change-Id: I38903b7e30ef1cf1d0dce87f61097a83259aea8e
Reviewed-by: Doris Verria <doris.verria@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
| |
Pick-to: 6.2
Change-Id: I22f71a53b0f7f0698450123343e25548c889c3e2
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
The property reflects the widget's current geometry if it is not in a
full screen or maximized state.
Pick-to: 6.2
Change-Id: I5816687119500995654a926aef952d788ad74886
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
Doing so results in bailing out early for a widget that hasn't been
shown yet, or otherwise resulted in creating extra and topextra,
which means the normalGeometry will not reflect the widget's geometry.
Pick-to: 6.2
Change-Id: Ieb85e9a6109ae34fe20d79e3c12f4517f827a590
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since commit 7ba75d0 we close the QWindow in QWidget::close for native
widgets and trigger the closeEvent in QWidgetWindow. However, if the
widget's window handle is not a top level window, QWindow::close()
will not close the window, failing in this way to deliver the
closeEvent and call the close handling in QWidgetPrivate::handleClose.
To fix, call handleClose() from QWidget::close for such widgets.
Task-number: QTBUG-74606
Pick-to: 6.2
Change-Id: Ied342eced3340aaf19b5443762935b1a5fc5c27b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
|
|
| |
The signal is emitted from QGuiApplication these days.
Pick-to: 6.2
Change-Id: I7423cd4808e8df86960f225fd6e4a12a1a4f11f3
Reviewed-by: Doris Verria <doris.verria@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
| |
Pick-to: 5.15 6.2
Change-Id: I6b77f0ec043d08da3b7958d780dce9595daf97a6
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QWidget::setParent might be called to change the window flags, without
changing the parent. For those cases, we don't have to clear the focus.
Decouple the newParent state from the wasCreated flag. In most places
where newParent was tested, wasCreated was either tested previously and
can't be false anyway, or the code executed is irrelevant for widgets
that are not yet created (there can't be a paint manager). In the
remaining case, test wasCreated explicitly to maintain existing logic.
Add test for the cases where the previous code broke the focus, both
for QWidget and QDialog.
Fixes: QTBUG-93005
Pick-to: 6.2
Change-Id: I39dc179c2d348054de3927aa8b69eecef4935511
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Doris Verria <doris.verria@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The functionality now lives in QGuiApplication, and is triggered
by QGuiApplication and QApplication after dispatching the close
event to the window.
The slight difference between how a Qt GUI and Qt Widget app
determines if a window should contribute to the close-on-quit
behavior has been abstracted into a QWindowPrivate helper.
The additional checks that were in place for skipping out of
the whole maybeQuitOnLastWindowClosed machinery have been kept.
Task-number: QTBUG-53286
Change-Id: I81bd474755f9adb3a2b082621e5ecaa1c4726808
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move the status setting and resetting back into handleClose so that we
don't end up with it being set if handleClose is never called in response
to a close attempt. This can happen when QWindow's platform window has
already been destroyed.
Since QWindow::close handles that case gracefully and returns true,
we can safely call it multiple times.
Add test coverage to verify that we get exactly those close event
calls that we want.
Change-Id: Ica77bf17c26d923c3b79b1e5a688addbc88a6277
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The check for styleMask == NSWindowStyleMaskBorderless to decide whether
to clear the NSWindow background was broken, as NSWindowStyleMaskBorderless
has the value 0, but is only supposed to be compared to its companion
NSWindowStyleMaskTitled (with value 1). A window can perfectly well be
NSWindowStyleMaskBorderless and NSWindowStyleMaskMiniaturizable e.g.,
so by comparing directly to NSWindowStyleMaskBorderless instead of
masking to the first bit first we ended up making miniaturizable
windows non-translucent.
We now check the Qt::FramelessWindowHint directly, and also whether
the window is opaque. Ideally we'd have QWindow flags that could
plumb WA_NoSystemBackground from Qt Widgets, as well as a background
color property on QWindow to control the system background, but
in the meantime we'll have to use the FramelessWindowHint heuristic.
The QWidget docs have been updated to reflect this.
Task-number: QTBUG-95042
Pick-to: 6.2
Change-Id: I0d40eecace60883c205ebb8c76cef1092cdf1144
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
|
|
|
|
|
|
|
|
|
| |
Ensures that the QWindow and platform machinery is involved in closing
the widget.
Change-Id: I4ca4ed0b1b31b835d62d2fc0a2158e34e15d710e
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
If we are the one initiating the close (from Qt Widget land), we want
to mark the widget as closing as early as possible.
Clarified the role of close_helper by renaming it to handleClose.
Change-Id: Iae250a0ae1583d743c59e99fcb99fdf18d2a1882
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
| |
Fixes: QTBUG-68069
Pick-to: 6.2 5.15
Change-Id: I8fc99f708cfa19a9c8cc8d13f6889549c79dd3b3
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
| |
QWidget::addAction takes a QKeySequence, not a QShortcut.
Change-Id: Ia10adcf50133b306d484a122ed17dddcf94372a6
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We want to close the window, end full screen mode on macOS, and free
platform resources. This is all done by QWindow::close. QWindow::close
closes the platform window, triggering a closeEvent to QWidgetWindow,
which then calls QWidgetPrivate::close_helper.
This way, closing a window via QWidget::close, QWindow::close, or
interactively by the user are all equivalent.
The QCloseEvent generated by the widget needs to be spontaneous for
window-system generated events (i.e. the user clicked the close button),
and non-spontaneous if the window closes because of a call to
QWindow::close. To keep track of whether the event originated in an
explicit call to QWindow::close, add a boolean to the QWindowPrivate.
Add a test case that verifies that the window resources is destroyed,
and that events are delivered as they should.
Done-with: Morten Johan Sørvig <morten.sorvig@qt.io>
Fixes: QTBUG-46701
Pick-to: 6.2
Change-Id: Iacb6a2c8d5e880b16b0c8f0c9257ed94bed36f5b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
* Add missing . in \brief to silence warning.
* Move relevant text about behavior change since 4.7
from the end to the start of the documentation block.
Task-number: QTBUG-85839
Pick-to: 6.2 5.15
Change-Id: Id3671413f17d06023035c15fc7d5badbde59c5a6
Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
|