summaryrefslogtreecommitdiffstats
path: root/src/widgets/kernel/qapplication.cpp
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* | 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>
* | Mark QApplication::globalStrut as deprecatedVolker Hilsheimer2020-01-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Unify application palette handling between QGuiApplication and QApplicationTor Arne Vestbø2020-01-131-134/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-091-31/+24
|\| | | | | | | | | | | | | Conflicts: src/corelib/kernel/qobject.cpp Change-Id: I4780b25665672692b086ee92092e506c814642f2
| * Remove clearWidgetPaletteHash argument from setPalette_helperTor Arne Vestbø2020-01-091-5/+4
| | | | | | | | | | | | | | | | | | | | 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-091-22/+20
| | | | | | | | | | 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 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-161-68/+70
|\| | | | | | | | | | | | | | | Conflicts: src/network/ssl/qsslsocket.cpp src/widgets/kernel/qapplication.cpp Change-Id: Ib7421cc2df59d0969f89b3fbd65a17ea76ffef3b
| * Remove QApplicationPrivate::set_palTor Arne Vestbø2019-12-131-12/+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>
* | Tidy nullptr usageAllan Sandfeld Jensen2019-12-061-87/+87
| | | | | | | | | | | | | | | | | | | | | | 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>
* | Make QObjectPrivate::threadData a proper atomicGiuseppe D'Angelo2019-11-131-1/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QObjectPrivate::threadData used to be a QThreadData *, and was read and written from multiple threads without proper synchronization. As an example, it was read from QCoreApplication::postEvent and written from QObject::moveToThread, therefore causing UB. Port threadData to a proper atomic, removing the races. Fix all usage points. In general, QObject is documented to be simply reentrant, not thread-safe, and certain bits (e.g. timers, moveToThread) are not even reentrant. The reasoning therefore is that a given QObject's threadData is not supposed to be touched by multiple threads without some synchronization happening elsewhere, and therefore relaxed loads should be sufficient. As drive-by change: refactor QCoreApplication::postEvent. It was particularly subtle, because it had a loop using a volatile to cope with the possibility of the receiver object switching thread while we tried to lock its thread's event queue. However, volatile does not achieve any synchronization, so drop it, and refactor the algorithm using better locking primitives. Put this algorithm in a common place, and also reuse it from removePostedEvents, which was lacking any synchronization. Change-Id: Icc755f7eb418ff54b33db4bdd87fd8eaf4e82c7a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Propagate application termination requests through QPATor Arne Vestbø2019-10-191-11/+8
| | | | | | | | | | | | | | | | | | | | | | | | | Instead of having each platform plugin deal with application termination in their own weird ways, we now have a QPA API to signal that the system requested the application to terminate. On the QGuiApplication side this results in a Quit event being sent to the application, which triggers the default behavior of closing all app windows, and then finally calling QCoreApplication::quit(). The quit event replaces the misuse of a close event being sent to the application. Close events are documented as being sent to windows. The close events that are sent to individual windows as part of the quit process can be ignored. This will skip the final quit() of the application, and also inform the platform that the quit was not accepted, in case that should be propagated further. In the future the logic for closing windows should be unified between the various approaches in closeAllWindows, shouldQuit, and friends. Change-Id: I0ed7f1c0d3f0bf1a755e1dd4066e1575fc3a28e1 Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
* Quiet several more warnings about QWheelEvent deprecationsShawn Rutledge2019-10-021-0/+6
| | | | | | | | | | We want to ensure that the qt4D and qt4O members are still initialized the same way whenever deprecated constructors are used; and we want to be able to verify it using qDebug. So we merely suppress these warnings. Change-Id: Ic2e5f0dd6feeabe81f06f9c31693c550ac0781e3 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QWidget: replace manual memory management with unique_ptr [6/N]: extraMarc Mutz2019-08-201-2/+2
| | | | | | | | | | | | | Had to port a lot of caching temporaries, too. Decided to leave them as crefs to unique_ptr to catch any mischief users may be doing with the raw pointer instead (like deleting it). Also fixed a use of 0 as nullptr (by standardizing on pointer-to-bool conversion, as is done everywhere else in qwidget.cpp), and made one impregnable if condition readable. Change-Id: Ifdc240bf352c52de0bc3c186fa7a5f4cb2882dd0 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Clean up documentation of deprecated APIs from QApplicationSona Kurazyan2019-08-011-41/+2
| | | | | | | | | | Build docs for deprecated APIs conditionally, based on deprecation version. Remove the docs of methods deprecated since 5.0.0, these methods are not compiled anymore. Change-Id: If9302eecc8b3fff4a27c2e4a66ac102add7d66c5 Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Remove usages of deprecated QApplication::keypadNavigationEnabledSona Kurazyan2019-07-231-4/+0
| | | | | | | | | | Added QApplicationPrivate::keypadNavigationEnabled() as a replacement of deprecated QApplication::keypadNavigationEnabled(), for the internal usage. Task-number: QTBUG-76491 Change-Id: I75f4c628b72d86b5e428e7e285a786d23abbf3f2 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Merge remote-tracking branch 'origin/5.13' into devQt Forward Merge Bot2019-07-171-1/+1
|\ | | | | | | | | | | | | | | | | | | Conflicts: src/corelib/global/qlogging.cpp src/gui/painting/qtextureglyphcache_p.h src/gui/text/qfontengine.cpp src/widgets/widgets/qlineedit.cpp Change-Id: Ic8798538df466b7141caa8bbf1fb7605eb56be37
| * Merge remote-tracking branch 'origin/5.12' into 5.13Qt Forward Merge Bot2019-07-131-1/+1
| |\ | | | | | | | | | Change-Id: I5d2a4fa33b4aa22da39ac045e6b85ab940b8720b
| | * Remove unused arguments from QWidgetPrivate::create_sysTor Arne Vestbø2019-07-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The public QWidget::create still has them, but we don't need to propagate them on - that just makes debugging the window creation flow harder. The window argument to QWidget::create is technically used to guard an early exit in the function, but to keep behavior the same we leave it for now. Change-Id: Ic0287575aa25f1272e216adc1b75e34d6f55f6d9 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
| * | Merge remote-tracking branch 'origin/5.12' into 5.13Liang Qi2019-06-251-48/+11
| |\| | | | | | | | | | | | | | | | | | | | | | Conflicts: src/corelib/io/qstorageinfo_unix.cpp src/network/ssl/qsslsocket_openssl.cpp Change-Id: Ibc9ce799bef62d60d616beaa9fbde8ebeadfbc20
* | | Finish deprecating obsolete members of QWheelEventShawn Rutledge2019-07-121-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In Qt 5.0, delta() and orientation() were already marked obsolete, but Widgets and tests have kept on depending on them all this time. We now start using alternative API so they can really be deprecated. All constructors except the newest one are also deprecated. The plan is for all events from pointing devices to have QPointF position() and globalPosition(), so we deprecate the other position accessors. [ChangeLog][QtGui] Obsolete constructors and accessors in QWheelEvent now have proper deprecation macros. What is left is intended to be compatible with planned changes in Qt 6. Change-Id: I26250dc90922b60a6ed20d7f65f38019da3e139e Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* | | QApplication::topLevelWidgets(): Avoid allocation of listFriedemann Kleint2019-07-041-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | Use the QSet QWidgetPrivate::allWidgets directly instead of calling QApplication::allWidgets(), which allocates a QList. Change-Id: I16d289030cecefae7811d4b2c94f865f46f700d5 Reviewed-by: Marc Mutz <marc.mutz@kdab.com> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* | | Port from implicit to explicit atomic pointer operationsMarc Mutz2019-06-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The old code used the implicit conversions from QAtomicPointer<T> to T* and vice versa. The semantics of these differ from the ones std::atomic uses, so we're going to deprecate these, like we did for load() and store(), too. This patch fixex some users of these APIs before we deprecate them. Change-Id: I0a88bb1c359392538bb64b511bfc62381a56a468 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | | QtWidgets: Fix static method invocationsFriedemann Kleint2019-06-281-25/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Apply fixits by Creator and results of manual search focusing on QCore/Gui/Applicaton(Private) methods and variables to prepare for splitting out some classes. Task-number: QTBUG-69478 Task-number: QTBUG-76497 Task-number: QTBUG-76493 Change-Id: Iaf468166793e0cabb514b51c827b30317bf45a2d Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* | | Merge remote-tracking branch 'origin/5.12' into devLiang Qi2019-06-251-48/+11
|\ \ \ | | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: .qmake.conf src/gui/painting/qdrawhelper.cpp src/gui/text/qdistancefield.cpp src/gui/text/qdistancefield_p.h src/network/ssl/qsslsocket_openssl.cpp src/plugins/platforms/android/qandroidinputcontext.cpp src/widgets/styles/qstylesheetstyle.cpp Done-With: Timur Pocheptsov <timur.pocheptsov@qt.io> Change-Id: Ia7daad21f077ea889898f17734ec46303e71fe6b
| * | QApplication: clarify and unify global static usageTor Arne Vestbø2019-06-211-11/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | Explain why there are two accessor functions for the global statics, and use the global statics directly inside qapplication.cpp for consistency. Change-Id: Ibf3952052c1d0e780a8aab220a72f05af0c070a5 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
| * | Remove duplicate call to QApplicationPrivate::setPalette_helperTor Arne Vestbø2019-06-211-1/+0
| | | | | | | | | | | | | | | | | | | | | initSystemPalette() already takes care of this. Change-Id: I6521763a74ec3ec629d9fcf05aa2a7cd71a7f26d Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
| * | Remove duplicate call to QApplicationPrivate::initializeWidgetPaletteHash()Tor Arne Vestbø2019-06-211-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | initSystemPalette() already calls this when there's a platform theme, which is the only case where initializeWidgetPaletteHash will have an effect. Change-Id: I814ea2bb17ef40aee769f2c36f8ef4296cfca020 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
| * | Squash un-needed qt_init function into callsiteTor Arne Vestbø2019-06-211-15/+4
| | | | | | | | | | | | | | | | | | | | | | | | Only uses a single place and avoids following the init logic through multiple layers when trying to debug it. Change-Id: I8fc119385edf407f69fb5431dc6584288022a7fe Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
| * | Remove dead code from QApplicationPrivate::setSystemPaletteTor Arne Vestbø2019-06-211-20/+2
| | | | | | | | | | | | | | | | | | | | | The code was added in 2005, ifdefed out already, and never used. Change-Id: Ic5d070dd031665a4429739278851b50646694bf9 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* | | Merge remote-tracking branch 'origin/5.13' into devLiang Qi2019-05-131-2/+2
|\ \ \ | | |/ | |/| | | | | | | | | | | | | Conflicts: src/corelib/tools/qstring.cpp Change-Id: I81dbf90fc936c9bf08197baefa071117bddb1c63
| * | Doc: replace even more null/0/nullptr with \nullptr macroChristian Ehrlicher2019-05-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | Try to replace all wordings like '.. to 0' with '.. to \nullptr'. Also checked for 'null pointer' and similar. Change-Id: I73341f59ba51e0798e816a8b1a532c7c7374b74a Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* | | Deprecate conversion functions between QList and QSetLars Knoll2019-05-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Users should use range constructors instead to do the conversion. Keep conversion methods between QList and QVector as these will turn into a no-op in Qt 6, whereas forcing people to use range constructors would lead to deep copies of the data. Change-Id: Id9fc9e4d007044e019826da523e8418857c91283 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* | | Merge remote-tracking branch 'origin/5.13' into devLiang Qi2019-05-071-10/+9
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/corelib/kernel/qobject.cpp src/corelib/kernel/qvariant.h src/corelib/tools/qlist.h Done-With: Milian Wolff <milian.wolff@kdab.com> Done-With: Allan Sandfeld Jensen <allan.jensen@qt.io> Change-Id: I6803f7239aa137a51a7467fab7cc7a01302a848d
| * | Merge remote-tracking branch 'origin/5.12' into 5.13Liang Qi2019-05-031-10/+9
| |\| | | | | | | | | | | | | | | | | | | Conflicts: src/3rdparty/pcre2/qt_attribution.json Change-Id: Ibae941cb12662f27bd6962ee02bc235971c59a15
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-20 03:46:21 +0000