| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Followup to ed3ed0b9db97a8fab0c03add23228b6b0a96f171
68916fede41d1eca5d07eb6b1db518d41a007616 and
3c159957f863cf8d367a9261e7016e52cd0348c1.
In QWindowSystemInterfacePrivate::fromNativeTouchPoints() and
QWindowSystemInterfacePrivate::toNativeTouchPoints() we continue using
struct TouchPoint's QRectF area as storage for the screen position +
ellipse diameters; as the comment says, this is _unrotated_, meaning
that rotation is stored separately, and area should not be construed as
the bounding box of the rotated ellipse. (In Qt 6 we can make the
QPA touchpoint look the same as the QTouchEvent::TouchPoint to
eliminate the need to calculate the center of the rect.)
In QGraphicsScenePrivate::updateTouchPointsForItem(), setRect() sets the
position and the ellipse diameters, but the latter is redundant because
the purpose of this function is to localize a touchpoint to the
coordinate system of a particular QGraphicsItem. Ellipse diameters
should stay the same.
In QApplicationPrivate::updateTouchPointsForWidget(), as in
QGraphicsScene, we are localizing touchpoints to a widget
and to the screen that the widget is shown on, so only the position
needs to be set, while preserving the sub-pixel resolution that
mapFromGlobal(QPoint) loses.
Fixes: QTBUG-83403
Change-Id: I61d29e14cbe38567767b164af6ae895082c5e1a1
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
| |
|
|
|
| |
Change-Id: I49c285604694c93d37c9d1c7cd6d3b1509858319
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
| |\
| |
| |
| |
| |
| |
| | |
Conflicts:
tests/auto/widgets/itemviews/qabstractitemview/tst_qabstractitemview.cpp
Change-Id: Ifaa56153f5f0d687a6b4d94f84fcfa1e1751afd2
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
With nested popup widgets, pressing a mouse button on the lower
popup will close the active popup. MouseMove events that are generated
before the button is released again should not have that button
included, as it is likely to result in incorrect state handling in
the widget. This change removes all buttons from the MouseMove event,
which is the second best option.
This is mostly consistent with the behavior when closing a popup and
no other popup remains. The widget underneath will get MouseMove
events without the respective button included.
This change doesn't include a fix for the final release event, which
should ideally also not be delivered to the remaining popup, as it
never got a corresponding press event. Qt has already reset the states
in which it stores which widget received the press event at the time
the release is generated, such as qt_button_down and qt_popup_down.
So we can't separate a release grabbed by a newly opened popup (which
we want) from a release to the popup that became active after closing
(which we don't want).
However, widgets can more easily work around this issue, and the risk
of breaking things by changing the code further becomes too high.
Change-Id: I603bbdbc7e7355952d96ab77c5e2d2f1e6f94987
Fixes: QTBUG-82538
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Paint events are delivered with the client rect of the widget, and
this applies to paint-on-screen widgets as well. The same goes for
how the widget repaint manager tracks dirty rects. Internally we
were also calling paintOnScreen() with client rects, so the use
of geometry() in the resize handler was likely a bug/oversight.
Change-Id: I1312ccf77218d1162e0971e4cbabaa80f49c852c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
| |\|
| |
| |
| | |
Change-Id: Ib2a2e3a292af43be3a980c2ccc943c08f4bbf72f
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This ammends change baed8534bc1dac36a9d0ef4240fc14398076a192, which
might have introduced a hard to reproduce segmentation fault when the
screen number is out of bounds, or when the QScreen object doesn't
return a valid pointer for QScreen::handle.
As the issue doesn't reliably reproduce, this is a speculative fix that
adds bounds and nullptr checking.
Change-Id: I0cec0a344e80159ee1723d840f207267a608cef4
Fixes: QTBUG-82807
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
| | |
| |
| |
| |
| | |
Change-Id: I0a449068a0d4557b7bd6581ddf71c590b72d76a1
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
It was introduced in Qt 4.4 (e150f6a6e619) to work around slow resizes
on Windows and X11 due to excessive painting, but has since been removed
when old dead code never ported to QPA was removed in a2337f79ffd229.
Change-Id: Ic14e714a02edb4194a445a6bb0759b601799fdc6
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
It's not possible anymore, since many years. The desktop's don't use the
X11 root window anymore :)
Fixes: QTBUG-82880
Change-Id: I923f29f23e61d93640cacb2ac20620c5ddc480b9
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
It was renamed to QTabletEvent::deviceType() in
882f340f62b8dc34633f5f296be12243b6e8999d.
Change-Id: I070404bfc9a04144ae3565bfa3cc3a016040a07d
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The new PMF ctors introduced with a4751f8824723acaee4b9d8aa78a59c2aa36cb3e
created some ambiguities with existing old-style connects. Fix it by
explitly checking if the given pointers are pointers from QObject
derived classes.
Fixes: QTBUG-82415
Change-Id: I70d51a6d50384fe6b5083fa3b94492ab6ed97086
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |\|
| |
| |
| | |
Change-Id: Iad459349ea8b4090d79b4771bfff8f656a8a8189
|
| | |
| |
| |
| |
| |
| |
| |
| | |
A \c{} section is already rendered using monospace, no need to escape
the \nullptr keyword explicitly.
Change-Id: I004a409892809e968c7a73c68a5b3c54a4680425
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Widgets have a default palette and font that is influenced by several
factors: theme, style, QApplication-wide overrides, and the parent's.
If an application sets a font or palette on a parent, then widgets
inherit those settings, no matter when they are added to the parent.
The bug is that this is not true for widgets that have an application-
wide override defined by the platform theme. For those, we need to merge
parent palette and font attributes with the theme, and this is currently
not done correctly, as the respective masks are not merged and inherited.
This change fixes this for fonts and palettes. Children are inheriting
their parent's inheritance masks, combined with the mask for the
attributes set explicitly on the parent. This makes the font and palette
resolving code correctly adopt those attributes that are set explicily,
while leaving everything else as per the theme override.
The test verifies that this works for children and grand children added
to a widget that has a palette or font set, both when themed and
unthemed. Children with own entries don't inherit from parent.
The QFont::resetFont test had to be changed, as it was testing the
wrong behavior. If the child would be added to the parent before the
font property was set, then the test would have failed. Since this
change makes sure that children inherit fonts in the same way, no
matter on when they are added to their parent, the test is now
modified to cover both cases, and ensures that they return identical
results.
[ChangeLog][QtWidgets][QWidget] Fonts and palette settings are inherited
by children from their parents even if the children have application-
wide platform theme overrides.
Change-Id: I179a652b735e85bba3fafc30098d08d61684f488
Fixes: QTBUG-82125
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Vitaly Fanaskov <vitaly.fanaskov@qt.io>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If a widget backed by a QWindow is moved we need to translate the window
geometry into a position relative to the parent widget. In most cases this
was incidentally working due to widgets backed by QWindows always having
QWindow parents too, so the QWindow position was applicable to the widget
as well. But when Qt::WA_DontCreateNativeAncestors is used this is no
longer the case, and we would end up with a widget geometry that included
the parent positions all the way up to the next native widget.
The updatePos() function has been squashed into handleMoveEvent(), since
we need to ensure the position in the move event sent to the widget is
correct as well.
Change-Id: I55894ad7ab42a6d4d65e446a332ecdd7dcdcc263
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
By sending it to all top level windows it will make it possible for
non widget based controls to listen for this event if it cares about it
so it can handle translation updates as appropriate.
Task-number: QTBUG-78141
Task-number: QTBUG-82020
Change-Id: I8f35cdcccd81a199ff780c3f4f3d2c663480d638
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
The idea is to reserve device() to return a pointer to a QInputDevice
in the future, which is in sync with QQuickPointerEvent::device()
and with QTouchEvent::device().
Change-Id: Ifda6e8aea72d5121955b31bdcbd91bf1bfa4cec4
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The implementation of the check has been moved to a single helper
function. The reason for doing this check in QWidgetPrivate as well,
when it's already done in QObjectPrivate, is to catch incompatible
libraries where QtWidgets is the odd one out, e.g.:
QtSomeModule 5.15.0 -> QtWidget 5.15.1 -> QtCore 5.15.0
Technically any non-final subclass of QObjectPrivate should have
this check.
Change-Id: Ia74064ad27de7335040a6d6b37d11574f818c878
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |\|
| |
| |
| |
| |
| |
| | |
Conflicts:
src/network/ssl/qsslsocket_openssl_symbols.cpp
Change-Id: I8c13b5c48a8ecce96540b39c6d5f8ca146eb2339
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When QWidget is being destroyed, its winId is cleared, and
a QEvent::WinIdChange is sent. If a listener of this event
reacted by calling winId() again, we might crash.
A crash can be observed when this child widget is destroyed in dtor of its parent.
E.g. here is a hierarchy of widgets:
1:QWidget
2:QObject
3:QWidget
4:QWidget
If a listener subscribed for WinIdChange events from (4),
and there is a connection to destroy (4) when (2) is destroyed.
This will lead to infinite loop:
1. QWidget::~QWidget
2. QWidget::destroy
3. QWidgetPrivate::setWinId(0)
4. QCoreApplication::sendEvent(q, QEvent::WinIdChange);
5. eventFilter
6. QWidget::winId
7. QWidgetPrivate::createWinId (this=0x555555957600) at kernel/qwidget.cpp:2380
8. QWidgetPrivate::createWinId (this=0x55555596b040) at kernel/qwidget.cpp:2387
9. QWidget::create (this=0x5555558f2010, window=0, initializeWindow=true, destroyOldWindow=true) at kernel/qwidget.cpp:1163
10. QWidgetPrivate::createWinId (this=0x55555596b040) at kernel/qwidget.cpp:2387
11. QWidget::create (this=0x5555558f2010, window=0, initializeWindow=true, destroyOldWindow=true) at kernel/qwidget.cpp:1163
12. QWidgetPrivate::createWinId (this=0x55555596b040) at kernel/qwidget.cpp:2387
Fixes: QTBUG-81849
Change-Id: Ib4c33ac97d9a79c701431ae107bddfb22720ba0d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
| |\|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
.qmake.conf
examples/widgets/widgets/imageviewer/imageviewer.cpp
src/corelib/text/qchar.cpp
src/corelib/time/qdatetime.cpp
Change-Id: I9762f5c4ff650799219729d6aee79ac07ce9024a
|
| | |
| |
| |
| |
| | |
Change-Id: I00fcb1c2374e7ca168b6240f9d41c0323fb0867c
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If a widget inside a QGPW has a proxy focus, the code would keep
sending focus in events to the proxy even if the proxy was already
focused. Amend the check in place to prevent this from happening.
Change-Id: Id28d3bfe4f396da5c9477df713441ca7d506662f
Fixes: QTBUG-51856
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
| |\|
| |
| |
| |
| |
| |
| | |
Conflicts:
src/gui/image/qpnghandler.cpp
Change-Id: I8630f363457bb613d8fb88470a71d95d97cdb301
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When the tested widget has a focus proxy, then we should check if the
current focus widget is not the same as that focus proxy before setting
it to be the widget that gets focus. This ensures that when back-tabbing
from a widget like QDoubleSpinBox that it will not get stuck inside that
widget and will back-tab to the next correct one.
Fixes: QTBUG-81097
Change-Id: I3f689c7715da7f3ce8c3d2f616041528f5778a2f
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I showed QGestureManager to a colleage and I just couldn't avert my
eyes...
Also remove a pointless container::clear() call (the data member's
dtor will do that implicitly).
Change-Id: Id2b3f471d62e5ea416e875f28ecee73f8614a469
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When closing a popup (submenu) triggers closing another popup (the menu)
programatically it can happen that QApplicationPrivate::popupWidgets is
destroyed. Therefore we have to check if popupWidgets is still valid
after the focus change event was delivered.
Fixes: QTBUG-81222
Change-Id: Ide3a6897e43f389d396a80d8b158f7c8eb04e3aa
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
src/corelib/tools/qmap.cpp:1199: (qdoc) warning: Can't link to 'QMultiMap::unite()'
src/gui/kernel/qevent.cpp:949: (qdoc) warning: Unknown command '\see'
src/gui/painting/qpaintengine_raster.cpp:344: (qdoc) warning: clang found diagnostics parsing \fn Type QRasterPaintEngine::type() const
error: unknown type name 'Type'
src/gui/doc/src/qtgui.qdoc:45: (qdoc) warning: Can't link to 'Build with CMake'
examples/widgets/doc/src/gallery.qdoc:28: (qdoc) warning: Cannot find file 'widgets/gallery/gallery.pro' or 'widgets/gallery/gallery.pyproject'
src/widgets/kernel/qwidget.cpp:5950: (qdoc) warning: Can't link to 'setFilePath'
src/widgets/kernel/qshortcut.cpp:542: (qdoc) warning: No such parameter 'context' in QShortcut::QShortcut()
Change-Id: I2395af854efebef719d4762da466f69f7c5aab9e
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I made a clazy automated check that replaced the use of QVariant::Type
by the equivalent in QMetaType.
This has been deprecated since Qt 5.0, but many uses were not yet removed.
In addition, there was some manual changes to fix the compilation errors.
Adapted the Private API of QDateTimeParser and QMimeDataPrivate
and adjust QDateTimeEdit and QSpinBox.
QVariant(QVariant::Invalid) in qstylesheet made no sense.
But note that in QVariant::save, we actually wanted to use the non-user type.
In the SQL module, many changes were actually reverted because the API
still expects QVarient::Type.
Change-Id: I98c368490e4ee465ed3a3b63bda8b8eaa50ea67e
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This property is obsolete with today's user interface reality, and was
never consistently implemented in all styles and widgets. Deprecating
it for Qt 5.15 as preparating for removing the code for Qt 6.
[ChangeLog][QtWidgets][QApplication] The globalStrut property has been
deprecated and will be removed from Qt 6
Change-Id: Iaea88e563144481a395de6cf0745a512e386407d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |\|
| |
| |
| | |
Change-Id: I8dbcf23835d52d3aa7d018ed250814d60c68aa83
|
| | |
| |
| |
| |
| |
| | |
Task-number: QTBUG-79824
Change-Id: I94dc566c9fb11bc8c598c0d5c043b6f388ebdc80
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
|
| | |
| |
| |
| |
| |
| | |
Fixes: QTBUG-74985
Change-Id: I7379865ab9564301c1e636ba1fda40cbb9e04c61
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The logic is now mostly handled in QGuiApplication, with QApplication
only dealing with the widget-specific palettes and interaction between
the style and the palette.
The application now picks up changes to the platform theme and will
re-resolve the current application palette appropriately. This also
works even if an explicit application palette has been set, in which
case any missing roles are filled in by the theme.
The palette can now also be reset back to the default application
palette that's fully based on the theme, by passing in the default
constructed palette (or any palette that doesn't have any roles set).
This is also correctly reflected in the Qt::AA_SetPalette attribute.
Conceptually this means QGuiApplication and QApplication follow the
same behavior as QWidget, where the palette falls back to a base or
inherited palette for roles that are not set, in this case the theme.
Behavior-wise this means that the default application palette of the
application does not have any roles set, but clients should not have
relied on this, nor does QWidget rely on that internally.
It also means that setting a palette on the application and then
getting it back again will not produce the same palette as set,
since the palette was resolved against the theme in the meantime.
This is the same behavior as for QWidget, and although it's a
behavior change it's one towards a more sane behavior, so we
accept it.
[ChangeLog] Application palettes are now resolved against the platform's
theme palette, the same way widget palettes are resolved against their
parents, and the application palette. This means the application palette
reflected through QGuiApplication::palette() may not be exactly the same
palette as set via QGuiApplication::setPalette().
Change-Id: I76b99fcd27285e564899548349aa2a5713e5965d
Reviewed-by: Vitaly Fanaskov <vitaly.fanaskov@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
|
| |\|
| |
| |
| |
| |
| |
| | |
Conflicts:
src/corelib/kernel/qobject.cpp
Change-Id: I4780b25665672692b086ee92092e506c814642f2
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The argument is only used when the application palette is set,
(as opposed to setting the palette for a specific widget class),
and that code path is only triggered from QApplication::setPalette,
which passes 'true' for this argument.
Change-Id: I67a1cc3741f6f62653b0f95ff88d28228f9977d4
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| | |
| |
| |
| |
| | |
Change-Id: I43cc25207026f174e46534baedf08e0c300728d1
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| | |
| |
| |
| |
| | |
Change-Id: I2f582358efaadcd33b39c52317222322c589423f
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |\|
| |
| |
| | |
Change-Id: I9b4816b4aa6f0c51a446742db58b9d0dcf69aa09
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
QApplication tries to close all windows on quit using closeAllWindows,
but closeAllWindows skips some windows, in particular any widget with
WA_DontShowOnScreen set.
QApplication then tries to verify that all windows have been closed,
and that logic should skip the same kind of windows as closeAllWindows
does.
We include WA_DontShowOnScreen so that widgets that are proxied via
QGraphicProxyWidget will not prevent the application from quitting.
There's still some divergence between closeAllWindows and the logic
in QApplication::event's quit handling, but aligning that requires
more work than this particular fix, and should probably also be
based on using the return value of tryCloseAllWindows() directly.
Change-Id: I2555eeee0cb04b8e736109fed57f37150efd1964
Fixes: QTBUG-81107
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
|
| |\|
| |
| |
| |
| |
| |
| | |
Conflicts:
src/corelib/kernel/qvariant.h
Change-Id: I8f3873e74b9795ac889e7c7ec5de2619bca92160
|
| | |
| |
| |
| |
| | |
Change-Id: I4f350e3c209dc9a39e849c9c39c41da700abeb60
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
src/corelib/tools/qhash.cpp:2596: (qdoc) warning: clang found diagnostics parsing \fn template <class Key, class T> template <class InputIterator> QMultiHash::QMultiHash(InputIterator begin, InputIterator end)
error: 'QMultiHash' is not a class, namespace, or enumeration
src/corelib/kernel/qobject.cpp:4593: (qdoc) warning: Undocumented parameter 'EXPORT_MACRO' in QObject::Q_NAMESPACE_EXPORT
src/corelib/global/qfloat16.cpp:129: (qdoc) warning: Cannot tie this documentation to anything
src/corelib/text/qlocale.qdoc:1204: (qdoc) warning: Overrides a previous doc
src/corelib/text/qlocale.qdoc:1187: (qdoc) warning: (The previous doc is here)
src/network/kernel/qhostinfo.cpp:597: (qdoc) warning: clang found diagnostics parsing \fn QHostInfo(QHostInfo &&other)
src/printsupport/dialogs/qabstractprintdialog.cpp:346: (qdoc) warning: clang found diagnostics parsing \fn int QAbstractPrintDialog::exec(): error: out-of-line definition of 'exec' does not match any declaration in 'QAbstractPrintDialog'
src/testlib/qsignalspy.qdoc:101: (qdoc) warning: clang found diagnostics parsing \fn QSignalSpy(const QObject *obj, const QMetaMethod &signal): error: expected unqualified-id
src/testlib/doc/src/qttest-best-practices.qdoc:28: (qdoc) warning: Can't link to 'Q_VERIFY2()'
src/widgets/kernel/qactiongroup.cpp:291: (qdoc) warning: Undocumented parameter 'b' in QActionGroup::setExclusive()
src/widgets/kernel/qactiongroup.cpp:305: (qdoc) warning: Undocumented return value (hint: use 'return' or 'returns' in the text
src/widgets/kernel/qshortcut.cpp:542: (qdoc) warning: No such parameter 'context' in QShortcut::QShortcut()
src/widgets/widgets/qdatetimeedit.cpp:632: (qdoc) warning: No such parameter 'minimumTime' in QDateTimeEdit::setTimeRange()
src/widgets/widgets/qdatetimeedit.cpp:632: (qdoc) warning: No such parameter 'maximumTime' in QDateTimeEdit::setTimeRange()
src/widgets/widgets/qdatetimeedit.cpp:632: (qdoc) warning: No such parameter 'less' in QDateTimeEdit::setTimeRange()
Change-Id: I9799b5135e84c4d811674b2d114ef27315bc12df
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
|
| |\|
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
.qmake.conf
src/plugins/platforms/xcb/qxcbscreen.cpp
src/widgets/accessible/qaccessiblewidget.cpp
Change-Id: Ib3138e61ba7981610940509a7ff02ba2dd281bf0
|
| | |
| |
| |
| |
| | |
Change-Id: I88b36e800139389895ecb1a15553207a24b3e3a4
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| | |
| |
| |
| |
| | |
Change-Id: I1f1be554a72a385985eeee0b79b49acdfcf40d8e
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
The two static setPalette methods in QApplication and QGuiApplication
should have the same behavior in terms of what signals and events
they emit.
Change-Id: I54579d490e31f3783e2d4fea689ca799a070ff1d
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| | |
| |
| |
| |
| | |
Change-Id: I7a8e6c0b54d2a16a17b292a4102e05f743bcbe29
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| |\|
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/network/ssl/qsslsocket.cpp
src/widgets/kernel/qapplication.cpp
Change-Id: Ib7421cc2df59d0969f89b3fbd65a17ea76ffef3b
|
