For top level windows, the window size will still reflect the screen's
available geometry, as the window state will be maximized by default.
[ChangeLog][iOS] The default normalGeometry() of a window is now 160x160,
instead of following the screen geometry. Top level windows are still
maximized by default, as before.
Change-Id: Ice752f74d943bf4fbb9be9e39f07798431fc2b0c
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Also update the QCollator::compare() docs for consistency.
Task-number: QTBUG-114822
Change-Id: I5fca896cacedd93ce5a4a1a8aead1986a21f6993
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Was private by mistake => make it public.
Pick-to: 6.6 6.5
Change-Id: I6b07a19687ddf84e8456aa70bc34b1cc714a299e
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
A severe incompatibility was detected in 2.3, which is why 2.4
is being released so soon afterwards. The mimetype for *.bz2 files
changed (from bzip to bzip2), breaking much code in KDE for instance.
This is now handled in a more compatible way. And the two last-minute
fixes in the Qt copy of 2.3 are part of 2.4, so this is now more in line
with upstream shared-mime-info.
Change-Id: Ibca358cf2ca9f341d148f54bb18044683c4a05eb
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Currently we are only checking if windowMinimumSize is not violated,
and we dont check windowMaximumSize at all, which may results in
windows being bigger than they ought to be.
When the sizeHints are updated, call the setGeometry() function which
makes sure that size constraints are respected and will resize window
if needed.
Pick-to: 6.5 6.6
Change-Id: I703bddec85ba6e02eea74a39e06d1f70d59e1677
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Move the remaining QTestResult::setBlacklistCurrentTest()
call from checkBlackLists() into TestMethods::invokeTest()
Change-Id: I6f0bb26ef612e707ad013d1e42e47b06f40482a0
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Jason McDonald <macadder1@gmail.com>
Reviewed-by: Dimitrios Apostolou <jimis@qt.io>
We only care about no longer being a child of the old parent window,
not what the system does when we reparent to nullptr.
Pick-to: 6.6
Change-Id: Ibd670432f0fd2595195d3951014a570dfdb7a998
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
When in a unity-build GCC 13 sees the implementation of
forkfd_wait4(), called dfrom forkfd_wait(), it can prove that there
are paths that do not initialize *info: Those paths are the returns
following fcntl() in system_forkfs_wait() in forkd_linux.c and read()
in forkfd_wait4().
To work around the issue and unbreak unity-builds, initialize info = {}.
Task-number: QTBUG-119081
Pick-to: 6.6 6.5
Change-Id: I1b3504e7f83c766ebccc851233d4c3e677bf2acd
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
A floating dock widget could either be a single QDockWidget object,
or a QDockWidgetGroupWindow with a single QDockWidget child.
The former could be dropped on the latter. Dropping the latter on
the former caused a crash.
The existence of QDockWidgetGroupWindows with a single dock widget
child was accepted to be by design.
Previous fixes, such as 9ff40b59da,
attempted to wrap all single floating dock widgets in
QDockWidgetGroupWindows.
These attempts fell short, because of the manifold programmatic and
manual options to create a floating dock widget:
- drag a single dock widget out of a main window dock area
- drag a dock widget out of a tab bar on the main window
- drag a dock widget out of a floating tab
- call `QDockWidget::setFloating(true)` in any situation
- create a new QDockWidget, that floats from the beginning
Whenever a QDockWidgetGroupWindow with a single QDockWidget child
was hovered and/or dropped on a QDockWidget without a group window,
crashes or screen artifacts were observed. Previous fixes made them
occur less often.
QDockWidgetGroupWindow is not designed to hold a single QDockWidget
child. Such a state is inconsistent and may only exist, while a
QDockWidgetGroupWindow is constructed.
The reason why such invalid QDockWidgetGroupWindows started to exist,
is a bool trap: QDockWidgetPrivate::mouseMoveEvent() starts a drag
operation, when a dock widget is moved by mouse.
It called startDrag() with no argument, which defaulted to
startDrag(true) and caused a group drag.
This assumption is
*correct*, when a tabbed group of dock widgets is dragged out of the
main dock as a whole, to become floating tabs.
*wrong*, when a single dock widget is dragged out of a docked group,
to become a single floating dock widget.
In the second case, the dock widget was wrapped in a new, floating,
invisible QDockWidgetGroupWindow. Looking like a single, floating dock
widget, the group window caused a crash, when attempted to be dropped
on another dock widget.
This patch eliminates all cases, where a QDockWidgetGroupWindow with
a single QDockWidget is created:
(1) Implement QDockWidgetPrivate::isTabbed().
This enables mouseMoveEvent to determine, whether the move relates to a
group of tabbed dock widgets, or to a single dock widget.
startDrag() can therefore be called with the right argument. It will no
longer create a QDockWidgetGroupWindow with a single QDockWidget child.
(2) Change QMainWindowTabBar::mouseReleaseEvent
When a dock widget was dragged out of a tab bar and became a single,
floating dock widget, it was still parented to the group window.
That is wrong, because it has no more relationship with that group
window.
=> Reparent it to the main window, just like any other single floating
dock widget. That enables QDockWidgetGroupWindow to detect, that the
2nd last child has gone and no more group window is needed (see next
point).
(3) React to reparenting, closing and deleting
If the second last dock widget in a floating tab gets closed (manually
or programmatically), reparented or deleted, also unplug the last one
and remove the group window.
(4) Amend 9ff40b59da
Remove the code path where a QDockWidgetGroupWindow with a single
QDockWidget child was created 'just in case', to make it compatible
others, created by (1), (2) or (3).
(5) Change QMainWindowLayout::hover()
When the hover ends without a successful drop and a temporary group
window with a single dock widget child has been created, remove the
group window.
The patch fixes smaller inconsistencies, which have not become visible
due to assertions and crashes earlier in the chain.
The patch finally extends tst_QDockWidget, to cover all 4 cases.
- Creation of floating tabs
The creation of floating tabs is extracted from floatingTabs() to
the helper function createFloatingTabs(). In addition to creating
floating tabs, the helper verifies that dragging a dock widget out
of the main window doesn't accidently wrap it in a group window.
This covers case (1).
- tst_QDockWidget::floatingTabs()
The test function verifies now, that both test dock widgets have the
same path before plugging them together and after unplugging them from
the floating tab. This covers case(4).
- tst_QDockwidget::deleteFloatingTabWithSingleDockWidget()
This test function is added, to cover cases (2) and (3).
- tst_QDockWidget::hoverWithoutDrop()
This test function hovers two floating dock widgets hover each other,
and returns the moved dock widget to its origin before releasing the
mouse. This covers case(5).
This fixes a lot of long standing bugs, making the author of this patch
modestly happy :-)
Fixes: QTBUG-118223
Fixes: QTBUG-99136
Fixes: QTBUG-118578
Fixes: QTBUG-118579
Fixes: QTBUG-56799
Fixes: QTBUG-35736
Fixes: QTBUG-63448
Fixes: QTBUG-88329
Fixes: QTBUG-88157
Fixes: QTBUG-94097
Fixes: QTBUG-44540
Fixes: QTBUG-53808
Fixes: QTBUG-72915
Fixes: QTBUG-53438
Found-by: Keith Kyzivat <keith.kyzivat@qt.io>
Found-by: Frederic Lefebvre <frederic.lefebvre@qt.io>
Pick-to: 6.6 6.5
Change-Id: I51b5f9e40cb2dbe55fb14d769541067730538463
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The test function was temporarily blacklisted on Ubuntu, but also
failing on other Linux platforms (e.g. openSuSE).
It tested, whether closing all dock widgets and the main window, would
close the application as well. It used one single shot timer, to close
the windows and later one to check, whether the application was shut
down.
While that mechanism must work in an application environment, it is not
guaranteed to work in testlib. More specifically, I could happen that
the XCB / glib event loop continued to spin and wait for events.
=> Check the signal QGuiApplication::lastWindowClosed() instead. If the
signal is fired, it is proven that all windows have been closed and
the application would quit in a production environment.
The underlying test case was: Application didn't quit with the last
dock widget closed, because there was a dangling
QDockWidgetGroupWindow.
=> finally: Clean up BLACKLIST
Pick-to: 6.6 6.5
Change-Id: Ic5fde5967fc8dde70ab64dc30cc7367c908b5c51
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QMainWindowLayout re-uses tab bars. A QSet and a QList member are kept,
to track used and unused tab bars.
Corner cases upon application close down leave dangling pointers in
those containers.
=> Add a destructor to QMainWindowTabBar
=> remove the tab bar from used and unused tab bar containers, if
not directly parented to the main window.
=> No longer reparent unused tab bars of a QDockWidgetGroupWindow
to the main window. Let them be destroyed as a group window child,
and its destructor remove it from the used/unused tab bar container.
Pick-to: 6.6 6.5
Change-Id: If2388cf878553dc89583dbc8585748fad65bbab2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
The documentation for some of the members of `QAnyStringView` is not in sync
with the intended target template declaration.
Hence, add the missing information to the relevant "\fn" commands.
Task-number: QTBUG-118080
Change-Id: I6c37a8bf90e3de8cc254e9b1ff3077fc9ebe6636
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
The documentation for some of the members of `QByteArrayView` is not in sync
with the intended target template declaration.
Hence, add the missing information to the relevant "\fn" commands.
Task-number: QTBUG-118080
Change-Id: I93abd3d0aaa2ae2bb3807b1aea5a938aabac848c
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
The documentation for some of the members of `QFutureWatcher` is not in sync
with the intended target template declaration.
Hence, add the missing information to the relevant "\fn" commands.
Task-number: QTBUG-118080
Change-Id: I33932d0ef693f6e045ecf4414d05dadfb66d3d09
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
The documentation for some of the members of `QJniObject` is not in sync
with the intended target template declaration.
Hence, add the missing information to the relevant "\fn" commands.
An additional `\fn` command was added for `jobject
QJniObject::object()`.
`object` has two overloads that are only distinguishable by their
template declaration, where the `jobject` returning overload has none
and the `T` overload has a template declaration.
The only documented overload was the templated version, but due to QDoc
not considering template information it was incorrectly being matched to
the non templated version.
Now that template information are taken into consideration, the provided
documentation correctly matches the templated version and the non
templated version was left undocumented.
The documentation block for the templated version is documented so that
both versions are covered by it.
Hence, an `\fn` command for the non templated version was added to the
documentation block for the templated version.
Task-number: QTBUG-118080
Change-Id: Ib77603bae99fdebbeec5d012a6c671246f4f2d1e
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
The documentation for `qHash(std::nullptr_t, size_t)` was providing a
unnecessary template declaration.
Hence, the incorrect additional information was removed from the `\fn`
command.
Task-number: QTBUG-118080
Change-Id: Iea406abbeb7aabd66e5b2ab092212d56b03cf42f
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
The documentation for some of the members of `QMetaType` is not in sync
with the intended target template declaration.
Hence, add the missing information to the relevant "\fn" commands.
Task-number: QTBUG-118080
Change-Id: I642bbc1ab90e3cc0d32a11592ab5ad93bd181364
Reviewed-by: Topi Reiniö <topi.reinio@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>
Upcoming changes to QDoc require accurate definition for
template arguments in \fn commands.
Task-number: QTBUG-118080
Change-Id: I75f8956c5fc094402837f96bd4598b60e3a7c649
Reviewed-by: Luca Di Sera <luca.disera@qt.io>
Upcoming changes to QDoc require accurate definition for
template arguments in \fn commands.
Task-number: QTBUG-118080
Change-Id: I761e99060caa64750eecf4fde4acc7f68d029936
Reviewed-by: Luca Di Sera <luca.disera@qt.io>
Upcoming changes to QDoc require accurate definition for
template arguments in \fn commands.
Task-number: QTBUG-118080
Change-Id: Ia905211d2b2bc5b49e5f9b50f2407544e939779d
Reviewed-by: Luca Di Sera <luca.disera@qt.io>
Upcoming changes to QDoc require accurate definition for
template arguments in \fn commands.
Task-number: QTBUG-118080
Change-Id: I3fde4b0c8867eaf50162dec3178e5c6e5dad3a6f
Reviewed-by: Luca Di Sera <luca.disera@qt.io>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
The documentation for `QCoreApplication::requestPermission` is not in
sync with the intended target template declaration.
Hence, add the missing information to the relevant "\fn" commands.
Task-number: QTBUG-118080
Change-Id: Idd1f32f48ef8b2a8d22d90a4df346b931f1f9cfa
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
The documentation for `QMetaEnum::fromType` is not in sync with the
intended target template declaration.
Hence, add the missing information to the relevant "\fn" commands.
Task-number: QTBUG-118080
Change-Id: I9160c1d76c0078f599d028c39fb3db17a34c3dd7
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
The documentation for `QObject::findChildren` is
not in sync with the intended target template declaration.
Hence, add the missing information to the relevant "\fn" commands.
Task-number: QTBUG-118080
Change-Id: I325008c22e82c002afe8cbeaa847af7a28277a0b
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
The documentation for some of the members of `QPointer` is not in sync
with the intended target template declaration.
Hence, add the missing information to the relevant "\fn" commands.
Task-number: QTBUG-118080
Change-Id: Iefaa12a4ac4f05cb5dbadd126b920cfc6a118d91
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
The documentation for `QUtf8StringView::QUtf8StringView(const Char*,
qsizetype)` and `QUtf8StringView::QUtf8StringView(const Char*, const
Char*)` are not in sync with their intended target template declaration.
Hence, add the missing information to the relevant "\fn" commands.
Task-number: QTBUG-118080
Change-Id: I916e840677f26d855f0bd825e6a913100ac261e2
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
The documentation for some of the members of `QFuture` is not in sync
with the intended target template declaration.
Hence, add the missing information to the relevant "\fn" commands.
Task-number: QTBUG-118080
Change-Id: I142124e02c9264c8c1b82bb8130162ee89c0f3a5
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
These are POD types, so there's nothing to be unwound in case of
exceptions (and the only one that could happen is the Q_CHECK_PTR).
Change-Id: I79e700614d034281bf55fffd178f91fe21685f03
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
The shaped clock example has the appearance of the analog clock, which
was refurbished with 619ec1a640. This
change applies the refurbished design to the shaped clock.
Task: QTBUG-118871
Pick-to: 6.6
Change-Id: Ibcfc8e9fb239a1c6f7ea685f6cab1e50b2060a53
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
It's the actual system call on Linux, inspired by the 4.4BSD call of the
same name (and our BSD code also uses statfs(), except for NetBSD, but
it probably could use statfs() there too). statvfs() wasn't introduced
until POSIX.1-2001, though glibc added it in 1998 for version 2.1 and
Bionic only for NDK version 19 in 2019.
So we could merge the Android code to the POSIX version, but it's easier
to merge the non-Android code to the raw system call.
Change-Id: I8f3ce163ccc5408cac39fffd178dbd83567a78d5
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
It's what the public API returns. There's little reason to use ulong,
despite that being the type that struct statvfs uses (on Windows, that
was 32-bit anyway).
Saves 8 bytes on the size of the QStorageInfoPrivate class.
Change-Id: I8f3ce163ccc5408cac39fffd178db8cfb9e5e4f6
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
There is a difference between findChild() and findChild("") that was
not explained in the documentation. So, add a sentence to clarify it.
The object's search when there are several direct ancestors was
documented as "undefined". Change it to "first child in children()".
Task-number: QTBUG-103986
Pick-to: 6.6 6.5
Change-Id: I25cb01b87d3b24af498ad494b3f353840ee78807
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
QWindowsScreen uses setupAPI.h's SetupDiOpenDevRegKey function to read
EDID data for monitors. This function is documented as returning
INVALID_HANDLE_VALUE in case of failure.
The QWindowsScreen code was ambiguous in the sense that it considered
both nullptr and INVALID_HANDLE_VALUE as being invalid handle values.
This inconsistency is likely not a bug, but makes the code harder to
understand.
This patch removes this ambiguity, and QWindowsScreen now follows the
documented behavior when SetupDiOpenDevRegKey fails. In addition, we
replace use of unique_ptr with the new QUniqueHandle template class
because HKEY is a handle type, not a regular pointer type.
Pick-to: 6.5 6.6
Change-Id: Ia863bda504077e59833f6f7a0f855e7915e4edd9
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
There is no need to run the catch-all DPR update if
the window is not visible.
Pick-to: 6.6
Fixes: QTBUG-117762
Change-Id: Ib4e235fed4b21e5aa2ecafa960ab0900e2b68295
Reviewed-by: David Edmundson <davidedmundson@kde.org>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
In rare situation, base size could be (-1,-1) or (-2,-2) for high
dpi, it will be converted into huge positive numbers.
https://tronche.com/gui/x/icccm/sec-4.html
If a base size is not provided, the minimum size is to be used
in its place and vice versa.
Pick-to: 6.6 6.5 6.2 5.15
Task-number: QTBUG-117702
Change-Id: I900ed82f2291fb454d7e34a0dee27459d0a57240
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Add missing include of global module header.
Drop unneeded global namespace qualifier for constant in
our namespace.
Amends 6017695bfa
Change-Id: I04633030af13df3c3359fc09b08b4a5f031013a9
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Using this trick we force CMake xcode generator to give the more
specific project name when configuring standalone tests.
Change-Id: Ic679003c574c0407bdc8df9eecf3762db214fd50
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Method is trying to infer the signature from the types of the
arguments, but since the argument for the view is a plain jobject
this signature is wrong, method is not found and the view is never
inserted.
Change-Id: I3cbf9bccbcb1e5526f843213ba0f66e5bd1e7107
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
When a QWindow is parented into another window, either via its constructor,
or via setParent(), we also update the QObject parent of the window. This
in turn sends ChildAdded and ChildRemoved events to the new and old parent
of the window, as well as ParentAboutToChange and ParentChange to the window
itself.
But at the point when these events are sent, the QWindow parent relationship
has not been fully established. We have not updated d->parentWindow, nor
have we propagated the parent relationship to the platform window.
This is problematic because clients can not use these events to react to
window parent changes synchronously. For example. trying to raise a child
window when added to a parent is not going to work, because at that point
the child window isn't a native child of the parent.
Instead of re-using the QObject events for QWindow, like QWidget does,
by delaying the events or sending them manually at a point when the
window parent relationship has been fully formed, we opt to add new
dedicated events.
Change-Id: I019c14eba444861f537e4f68ab3a82297f843cf7
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This is somewhat of a corner case, where there is a single sub-window,
setViewMode(TabbedView) is called before addSubWindow(), and the latter
is called before show(). The sub-window would be active, i.e.
subwindow->d_func()->isActive is true and QMdiArea::aboutToActivate() is
emitted, but QMA::emitSubWindowActivated() is never called for that
sub-window, resulting in that sub-window shown as
unmaximized/with-a-title-bar instead of as maximized/tabbed as is
expected in TabbedView.
Pick-to: 6.6 6.5
Fixes: QTBUG-114188
Change-Id: Ia7b2cfd07c51867707866a1f99f70129bbdc0e3e
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
endDrag(false) meant to end a drag with a dock location change.
endDrag(true) meant to abort a drag without a dock location change.
Replace this with a meaningful enumeration.
Define a dummy enum for builds w/o QDockWidget.
Task-number: QTBUG-118578
Task-number: QTBUG-118579
Pick-to: 6.6 6.5
Change-Id: I786f4210f5a3ee67ffcf0dc9285f77a480148569
Reviewed-by: David Faure <david.faure@kdab.com>
