summaryrefslogtreecommitdiffstats
path: root/src/widgets/kernel
Commit message (Collapse)AuthorAgeFilesLines
* Fix font and palette propagation for themed children created at runtimeVolker Hilsheimer2020-02-202-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* widgets: Translate QWindow move events into widget relative positionTor Arne Vestbø2020-02-192-16/+22
| | | | | | | | | | | | | | | | | 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>
* Send the LanguageChange event to all top level windows, not just widgetsAndy Shaw2020-02-181-1/+4
| | | | | | | | | | | 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>
* Deprecate QTabletEvent::device() in favor of deviceType()Shawn Rutledge2020-02-171-1/+1
| | | | | | | | | 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>
* Improve error message when mixing incompatible Qt library versionsTor Arne Vestbø2020-02-141-9/+1
| | | | | | | | | | | | | | | 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>
* Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2020-02-061-1/+3
|\ | | | | | | | | | | | | Conflicts: src/network/ssl/qsslsocket_openssl_symbols.cpp Change-Id: I8c13b5c48a8ecce96540b39c6d5f8ca146eb2339
| * widgets: Don't create winId when the widget is being destroyedVaL Doroshchuk2020-02-051-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2020-02-042-2/+2
|\| | | | | | | | | | | | | | | | | | | Conflicts: .qmake.conf examples/widgets/widgets/imageviewer/imageviewer.cpp src/corelib/text/qchar.cpp src/corelib/time/qdatetime.cpp Change-Id: I9762f5c4ff650799219729d6aee79ac07ce9024a
| * Fix 'the the' typo in commentsLinus Jahn2020-02-021-1/+1
| | | | | | | | | | Change-Id: I00fcb1c2374e7ca168b6240f9d41c0323fb0867c Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
| * QGraphicsProxyWidget: fix handling of proxy focusGiuseppe D'Angelo2020-01-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2020-01-281-1/+2
|\| | | | | | | | | | | | | Conflicts: src/gui/image/qpnghandler.cpp Change-Id: I8630f363457bb613d8fb88470a71d95d97cdb301
| * Make sure the focus is passed on correctly when back-tabbingAndy Shaw2020-01-251-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | QGestureManager: fix one (of many) inefficient loop(s)Marc Mutz2020-01-261-4/+3
| | | | | | | | | | | | | | | | | | | | | | 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>
* | QMenu: don't crash when another popup is closed when a popup is closedChristian Ehrlicher2020-01-251-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Fix some qdoc-warningsFriedemann Kleint2020-01-242-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Replace most use of QVariant::type and occurrences of QVariant::TypeOlivier Goffart2020-01-232-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Mark QApplication::globalStrut as deprecatedVolker Hilsheimer2020-01-222-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2020-01-152-2/+6
|\| | | | | | | Change-Id: I8dbcf23835d52d3aa7d018ed250814d60c68aa83
| * Doc: Correct non-link related qdoc compilation errorsNico Vertriest2020-01-141-1/+1
| | | | | | | | | | | | Task-number: QTBUG-79824 Change-Id: I94dc566c9fb11bc8c598c0d5c043b6f388ebdc80 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
| * Doc: Add note about mac-specific behavior for setWindowIconPaul Wicking2020-01-141-1/+5
| | | | | | | | | | | | Fixes: QTBUG-74985 Change-Id: I7379865ab9564301c1e636ba1fda40cbb9e04c61 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* | Unify application palette handling between QGuiApplication and QApplicationTor Arne Vestbø2020-01-132-140/+101
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge remote-tracking branch 'origin/5.14' into 5.15Liang Qi2020-01-092-35/+28
|\| | | | | | | | | | | | | Conflicts: src/corelib/kernel/qobject.cpp Change-Id: I4780b25665672692b086ee92092e506c814642f2
| * Remove clearWidgetPaletteHash argument from setPalette_helperTor Arne Vestbø2020-01-092-6/+5
| | | | | | | | | | | | | | | | | | | | 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>
| * Move tracking of widget specific app palettes to QApplicationPrivateTor Arne Vestbø2020-01-092-25/+23
| | | | | | | | | | Change-Id: I43cc25207026f174e46534baedf08e0c300728d1 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
| * Share updates to QGuiApplicationPrivate::app_pal via helper functionTor Arne Vestbø2020-01-091-5/+1
| | | | | | | | | | Change-Id: I2f582358efaadcd33b39c52317222322c589423f Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* | Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2020-01-091-1/+1
|\| | | | | | | Change-Id: I9b4816b4aa6f0c51a446742db58b9d0dcf69aa09
| * Skip WA_DontShowOnScreen widgets when checking whether application can quitTor Arne Vestbø2020-01-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2020-01-062-3/+4
|\| | | | | | | | | | | | | Conflicts: src/corelib/kernel/qvariant.h Change-Id: I8f3873e74b9795ac889e7c7ec5de2619bca92160
| * Fix syncqt warning in qtestsupport_widgets.hTor Arne Vestbø2020-01-021-1/+1
| | | | | | | | | | Change-Id: I4f350e3c209dc9a39e849c9c39c41da700abeb60 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
| * Fix some qdoc warningsFriedemann Kleint2020-01-022-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2019-12-271-12/+11
|\| | | | | | | | | | | | | | | | | Conflicts: .qmake.conf src/plugins/platforms/xcb/qxcbscreen.cpp src/widgets/accessible/qaccessiblewidget.cpp Change-Id: Ib3138e61ba7981610940509a7ff02ba2dd281bf0
| * Contain Qt::AA_SetPalette logic in QApplicationPrivate::setPalette_helperTor Arne Vestbø2019-12-211-3/+4
| | | | | | | | | | Change-Id: I88b36e800139389895ecb1a15553207a24b3e3a4 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
| * Simplify QApplication::paletteTor Arne Vestbø2019-12-211-3/+2
| | | | | | | | | | Change-Id: I1f1be554a72a385985eeee0b79b49acdfcf40d8e Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
| * Sync implementation of QGuiApplication and QApplication setPaletteTor Arne Vestbø2019-12-171-6/+3
| | | | | | | | | | | | | | | | | | 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>
| * Let sendApplicationPaletteChange() decide when it needs to exit earlyTor Arne Vestbø2019-12-171-3/+5
| | | | | | | | | | Change-Id: I7a8e6c0b54d2a16a17b292a4102e05f743bcbe29 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* | Merge remote-tracking branch 'origin/5.14' into 5.15Liang Qi2019-12-162-69/+70
|\| | | | | | | | | | | | | | | Conflicts: src/network/ssl/qsslsocket.cpp src/widgets/kernel/qapplication.cpp Change-Id: Ib7421cc2df59d0969f89b3fbd65a17ea76ffef3b
| * Remove QApplicationPrivate::set_palTor Arne Vestbø2019-12-132-13/+6
| | | | | | | | | | | | | | | | | | | | Its purpose was to track the default palette set by the programmer, but after 8fb881900c this is tracked by the Qt::AA_SetPalette attribute. The palette itself is always reflected 1:1 in the palette tracked by QGuiApplicationPrivate::app_pal. Change-Id: If3e84c8b3ae6070b6c50be7a33adb38799b3f3a5 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
| * Explicitly polish palette instead of relying on QApplication::setPaletteTor Arne Vestbø2019-12-121-4/+4
| | | | | | | | | | | | | | | | | | The only effect calling QApplication::setPalette will have is the polish, so opt for doing it explicitly instead of the weirdly looking no-op assignment. Change-Id: Ia80b3f60e3e513b68c2993ea8417966f9ab6721e Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
| * Clean up QApplication::style default style constructionTor Arne Vestbø2019-12-121-25/+24
| | | | | | | | | | Change-Id: I9f01e7cc5fa90fd9b1f5d12c7ce694c231158c32 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
| * Ensure override style properly clears out previous style if setTor Arne Vestbø2019-12-121-18/+14
| | | | | | | | | | | | | | | | | | | | QApplication::setStyle has quite a bit of logic to clean up from the old style before setting a new one. If a style has been set before the application is created, it's not enough to just delete the existing style, we need to treat it like a normal style switch. Change-Id: I2bcc2eb75567bf1bc8a32ac31467b22315a70a0b Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
| * Update system palette on application init if neededTor Arne Vestbø2019-12-121-0/+6
| | | | | | | | | | | | | | | | | | | | A style may have been set before the application was created, which would have resulted in setting the system palette based on the style's palette. Once the application is initialized and we have a platform theme we need to reset the system palette. Change-Id: Ia48f57d3983535c8633741d8027f75bc0c214018 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
| * Unify system palette initialization during style changeTor Arne Vestbø2019-12-121-15/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | We let initSystemPalette() do all the work, instead of leaving the first time initialization of the system palette to the caller, which makes the logic harder to follow. This also means first time initialization of the system palette will pick up a platform theme if available and resolve the palette using that, which was missing from the original logic. Change-Id: I84da557caf8ecedf6d96d87ebee93168ea9d73ba Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
| * Clarify call to initializeWidgetFontHash in QApplication::setStyleTor Arne Vestbø2019-12-121-1/+7
| | | | | | | | | | | | | | | | | | | | The call was added in c49c96fbb13912, "Reinitialize system palette when setting a new style", but adding it along with the palette code seems like a mistake. The potentially dirty widget font hash needs to be reset for all style changes. Change-Id: I411f56bb833819213c5485d7585fc5e3e9bd8983 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* | Avoid initializing QFlags with 0 or nullptr in macOS-specific codeFriedemann Kleint2019-12-111-2/+2
| | | | | | | | | | | | | | It is being deprecated. Change-Id: If1b0b058140e197d41efae93025c4eefc2ed9bbd Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* | Merge remote-tracking branch 'origin/5.14' into 5.15Liang Qi2019-12-102-15/+45
|\| | | | | | | | | | | | | Conflicts: tests/auto/network/kernel/qnetworkinterface/BLACKLIST Change-Id: I1e8866c63b54bcd95fc2a044276ee15b7f60e79a
| * Move the tooltip out of the way of very large mouse cursorsVolker Hilsheimer2019-12-091-15/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Users that have large mouse pointers configured in their settings can not see tooltips, as they are obscured by the pointer. Native applications on Windows and macOS have the same problem, which includes the tooltips for the minimize/maximize/close controls in the window frame of e.g. Explorer. Introduce QPlatformCursor::size that returns a value that is based on the user's settings, or a default value. We can then use that value to move the tooltip out of the way. On Windows, the calculation of the cursor size is based on experimenting with the settings, which are in logical independent pixels. The placement of the tooltip attempts to keep existing behavior, and to not end up with a tooltip that's very far away from the tip of the arrow even for very large mouse cursors. [ChangeLog][QtWidgets][QToolTip] Make sure that the tooltip is not obscured by very large mouse pointers on Windows and macOS. Change-Id: I8e13b7a166bfe8b59cef4765c950f90fefeaef9d Fixes: QTBUG-79627 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
| * QWidget: React to platform surface being created or destroyedTor Arne Vestbø2019-12-091-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | The platform window may create or destroy its surface from other entry points than the QWidget API, in which case QWidget needs to sync up its own state to match. In particular WA_WState_Created and the winId needs to be recomputed. Fixes: QTBUG-69289 Fixes: QTBUG-77350 Change-Id: I769e58ead3c2efcf8c451c363108848feade9388 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
* | Tidy nullptr usageAllan Sandfeld Jensen2019-12-0623-347/+347
| | | | | | | | | | | | | | | | | | | | | | Move away from using 0 as pointer literal. Done using clang-tidy. This is not complete as run-clang-tidy can't handle all of qtbase in one go. Change-Id: I1076a21f32aac0dab078af6f175f7508145eece0 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* | Merge remote-tracking branch 'origin/5.14' into 5.15Ulf Hermann2019-12-031-3/+8
|\| | | | | | | | | | | | | Conflicts: src/corelib/serialization/qcborvalue.cpp Change-Id: I675a3029955c96e81a33ed9d98b72b55b6784b52
| * QWidget: don't set WA_PendingMoveEvent when geometry does not changeChristian Ehrlicher2019-11-271-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When the geometry of a hidden widget was set with setGeometry(), WA_PendingMoveEvent and WA_PendingResizeEvent were set unconditionally even if the crect already had the correct value. This lead to unneeded Move/Resize events within sendPendingMoveAndResizeEvents(). Fixes: QTBUG-75475 Fixes: QTBUG-79906 Change-Id: Ibbe03882f039948b6b7c04887420741ed2e9c0f7 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-10 05:22:57 +0000