- Set the respective flags of dmFields in
QWin32PrintEngine::setProperty()
- Properly initialize newly allocated structs
This is merely for completeness, the allocation code paths are
not currently hit since the DEVMODE from the current printer is
used, which also has most dmFields bits set.
Pick-to: 6.6
Task-number: QTBUG-114604
Change-Id: I880d9faef9b1d491db4accd53d0d75b718f7f244
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Wladimir Leuschner <wladimir.leuschner@qt.io>
It's used to build different variations of the unittest,
linking against QtCore-only/QtGui, with/without GLib, that's four
individual tests.
Change-Id: Iaf0f37041dbb148134631f86be99feaa881a8ce8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The configure script always returned exit code 0 even if the
underlying cmake call failed. Make sure to exit with the same exit
code that the cmake process does.
[ChangeLog][Build System] The configure script on UNIX systems will
now exit with the same exit code that the underlying cmake process
exited with.
Pick-to: 6.5 6.6
Change-Id: I2cb43e162bb96f4e60320522895aac9bb5c5bc9e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Change the object's name type in QObject::findChild/ren() to
QAnyStringView, because they are only used for comparison against
objectName property.
qt_qFindChild{,ren}_helper() functions taking an objectname as
QString have to stay in the ABI as they were exported in inline
methods before Qt 6.7.
Unlike QString, constructing a null QAnyStringView doesn't involve
any code-size overhead. So, get rid of the split in qt_qFindChildren_helper
that was introduced for QString. Remove unneeded
qt_qFindChildren_with_name helper function and qt_qFindChildren_helper
overload without a name.
findChildren(options) method used to call qt_qFindChildren_helper overload.
Instead, call findChildren overload with name argument and pass
QAnyStringView{} as the object name.
[ChangeLog][QtCore][QObject] Ported QObject::findChild/ren() and
their helper functions to QAnyStringView.
Task-number: QTBUG-103986
Change-Id: I68bda0e581f984ae48b7581ad86cc1b95008c1b0
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Since we cannot re-use the pre-existing QPartialOrdering type due to
binary-compatibility issues (it's not BC to std::partial_ordering),
we're no longer bound to copy its API for consistency.
So copy std::*_ordering type API for consistency instead, to ease
porting for users that can already use C++20 and everyone else come
Qt 7.
This patch is another step in that direction, renaming classes and
their memmbers to std-compatible names. QPartialOrdering cannot
change, as it's pre-existing. So add a completely new type
Qt::partial_ordering.
Adding conversions from QPartialOrdering is left for a follow-up
patch.
As a drive-by, change `\c Less` to `\l Less` in the \class
documentation blocks of the new classes.
Amending c6fe64b17c, which didn't have a
ChangeLog:
[ChangeLog][QtCore] Added Qt::{partial,weak,strong}_ordering as
drop-in C++17 stand-ins for C++20's std::{partial,weak,strong}_ordering.
Task-number: QTBUG-119108
Change-Id: Ib1296de6b708571a6abca8843ba36c114f6fd34f
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
std::is_eq etc work fine on our Q*Ordering types when C++20 is
available. But in C++17 mode, they're absent.
Plug the hole by providing them for our own types as hidden friends,
so that users can use unqualified calls to transparently support both
std::*ordering and Q*Ordering types, just like with comparison to
literal zero.
For some reason, we running here into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100903, even though this
wasn't seen in other commits of the chain that use comparisons to
literal zero. Suppress the warning. Then at least is_eq etc provide a
safe fall-back for compilers and users affected by this bogus warning.
Fixes: QTBUG-119100
Change-Id: Ie8519c92363401a0c9c8efba6eb0b6e030a8e235
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Use cxx17_filesystem config instead of Q_OS_INTEGRITY.
Change-Id: I1d3fdae449a534dd25a32ce2820a4ebf788de2b0
Reviewed-by: Hatem ElKharashy <hatem.elkharashy@qt.io>
Reviewed-by: Janne Koskinen <janne.p.koskinen@qt.io>
Use std::array<QPointF, 4> instead a dynamic QPolygonF since there is no
dynamic allocation needed here.
Change-Id: I45e124de7db7263c9291e169165bf74174f032a6
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
When the text alignment is AlignRight the opened editor is wrongly
aligned and therefore the text can not be read. There is no reason to
align the editor window on the right only because of the text alignment.
Also remove the hack to not let occupy the editor the whole cell in a
QTreeView but in a QTableView.
Fixes: QTBUG-98525
Change-Id: I6f2d88e461bcfd505adde745041b5d4fdf679201
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
In rtl mode the text was not aligned right so a gap between the text and
the icon occurred. This was due to the fact that the textFlag given to
qt_format_text() was modified based on the application wide rtl/ltr mode
and so our Qt::RightToLeft was reverted to Qt::LeftToRight. Therefore
only set the textFlag to Qt::AlignRight when the button layout direction
does not match the global one.
Pick-to: 6.6
Fixes: QTBUG-64373
Change-Id: I283a99de8f59bc3db53c4150f417ffef9ff68db7
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
The platform window may in some cases be gone, without its NSWindow yet
being deallocated, and if we receive an application activation event at
this point we would try to dereference a null-pointer.
Fixes: QTBUG-119219
Pick-to: 6.6 6.5 6.2
Change-Id: I72bb2482059d1a256e448705b132e4a8f22ec297
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@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>
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>
