summaryrefslogtreecommitdiffstats
path: root/src/widgets/kernel
Commit message (Collapse)AuthorAgeFilesLines
* Track grab state in QPointingDevicePrivate::activePointsShawn Rutledge2020-09-163-52/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QQuickEventPoint instances were very long-lived and got reused from one event to the next. That was initially done because they were "heavy" QObjects; but it also became useful to store state in them between events. But this is in conflict with the ubiquitous event replay code that assumes it's OK to hold an event instance (especially a QMouseEvent) for any length of time, and then send it to some widget, item or window. Clearly QEventPoints must be stored in the QPointerEvent, if we are to avoid the need for workarounds to keep such old code working. And now they have d-pointers, so copying is cheap. But replay code will need to detach() their QEventPoints now. QEventPoint is useful as an object to hold state, but we now store the truly persistent state separately in an EventPointData struct, in QPointingDevicePrivate::activePoints. Incoming events merely update the persistent points, then we deliver those instead. Thus when event handler code modifies state, it will be remembered even when the delivery is done and the QPA event is destroyed. This gets us a step closer to supporting multiple simultaneous mice. Within pointer events, the points are moved up to QPointerEvent itself: QList<QEventPoint> m_points; This means pointCount(), point(int i) and points() can be non-virtual. However in any QSinglePointEvent, the list only contains one point. We hope that pessimization is worthwhile for the sake of removing virtual functions, simplifying code in event classes themselves, and enabling the use of the range-for loop over points() with any kind of QPointerEvent, not just QTouchEvent. points() is a nicer API for the sake of range-for looping; but point() is more suited to being non-const. In QML it's expected to be OK to emit a signal with a QPointerEvent by value: that will involve copying the event. But QEventPoint instances are explicitly shared, so calling setAccepted() modifies the instance in activePoints (EventPointData.eventPoint.d->accept); and the grabbers are stored separately and thus preserved between events. In code such as MouseArea { onPressed: mouse.accepted = false } we can either continue to emit the QQuickMouseEvent wrapper or perhaps QEvent::setAccepted() could become virtual and set the eventpoint's accepted flag instead, so that it will survive after the event copy that QML sees is discarded. The grabChanged() signal is useful to keep QQuickWindow informed when items or handlers change exclusive or passive grabbers. When a release happens at a different location than the last move event, Qt synthesizes an additional move. But it would be "boring" if QEventPoint::lastXPosition() accessors in any released eventpoint always returned the same as the current QEventPoint::xPosition()s just because of that; and it would mean that the velocity() must always be zero on release, which would make it hard to use the final velocity to drive an animation. So now we expect the lastPositions to be different than current positions in a released eventpoint. De-inline some functions whose implementations might be subject to change later on. Improve documentation. Since we have an accessor for pressTimestamp(), we might as well add one for timestamp() too. That way users get enough information to calculate instantaneous velocity, since the plan is for velocity() to be somewhat smoothed. Change-Id: I2733d847139a1b1bea33c00275459dcd2a145ffc Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Fix conversion warnings when setting alpha to QColorFriedemann Kleint2020-09-151-1/+1
| | | | | | | Adapt to 5bb4baae0379d5903f547f0399be9620f5ab06a0. Change-Id: Id65f87740f9de8e0d3624ff63c431dcad642f3a5 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* QLayout: Make contentsMargins a Q_PROPERTYFriedemann Kleint2020-09-151-0/+1
| | | | | | | | | | It replaces the deprecated int margins property, which was a Q_PROPERTY. This enables Qt for Python users to use property syntax for it. Task-number: PYSIDE-1019 Change-Id: I958d2ef7f8e2afcc2be490e29d4b11c070569fbd Reviewed-by: Christian Tismer <tismer@stackless.com> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Clean up the last of QT6_(NOT_)?VIRTUALEdward Welbourne2020-09-141-2/+2
| | | | | | | | | This follows up on commit d273076b4474bb473d90e996960c4c773745761a which left a comment asking for the clean-up this finishes. Task-number: QTBUG-85700 Change-Id: I1c6896a42a09b873302ad7ec8273879f2a4a4ce6 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Port from devicePixelRatioF() to devicePixelRatio()Morten Johan Sørvig2020-09-101-8/+8
| | | | | | | This ports all of QtBase. Change-Id: If6712da44d7749b97b74f4614a04fac360f69d9e Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Disable operator+ and operator- for QFlagsGiuseppe D'Angelo2020-09-091-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... and the associated enumeration. Using them is almost always a certain mistake. 1) op+ between two enumerators of the same enumeration yields int, not QFlags, so removing the type safety that QFlags is supposed to give and breaking the semantics of bitwise operations. 2) op+ between two enumerators of different enumerations is deprecated in C++20 (already flagged by GCC10), and again yields int. This is a code smell. Dedicated classes (holding a combination of unrelated enums) should be used instead. 3) op+ between an enumerator and its QFlags loses the semantic meaning of bitwise operations. If the real meaning was to use operator|, then use that instead; operator+ hides the intent, and can introduce bugs by creating a result not expressible via OR combinations of enumerators: enum E { A = 0x01, B = 0x02 }; QFlags<E> f = E::A; f + E::A; // ??? f + E::B; // ??? Identical reasoning applies for operator-. Technically the other arithmetic operators could be disabled as well, but I really don't expect any real-world usage for them. This has spotted bugs in Qt. [ChangeLog][Potentially Source-Incompatible Changes][QFlags] Using operator+ or operator- with a QFlags object or with an enumeration that has a corresponding QFlags object will now result in a compile-time error, because it's a generally unsafe operation. Use the proper bitwise operations instead (|, &, ~); or cast the enumeration to a integral type before attempting arithmetic manipulations on it. Change-Id: I5eabc5195dec3d3082bc9da10dbc8cf5dff3e1eb Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Refactor testlib touch functions into qtestsupport_gui and _widgetsShawn Rutledge2020-09-082-1/+96
| | | | | | | | | | | | | Because we removed public setters from QTouchEvent and QEventPoint in 4e400369c08db251cd489fec1229398c224d02b4 and now it's proposed to give QEventPoint a d-pointer again, the implementation of QTouchEventSequence needs to start using QMutableEventPoint: being a friend will no longer be enough, because the member variables won't be accessible in the future. But because we have separate test libs for Gui and Widgets, it needs to be further refactored into two classes. Change-Id: I0bfc0978fc4187348ac872e1330d95259d557b69 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Deliver Quit event when calling QCoreApplication::quit()Tor Arne Vestbø2020-09-071-9/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of QCoreApplication::quit() directly calling exit(0), which would leave QGuiApplication and client code out of the loop, we now send the Quit event, and let it pass through event delivery, before finally ending up in QCoreApplication::event(), where we call exit(0). This has the advantage that QGuiApplication can ensure all windows are closed before quitting, and if any of those windows ignore the close event the quit will be aborted. This aligns the behavior of synthetic quits via QCoreApplication::quit() with spontaneous quits from the platform via QGuiApplicationPrivate::processApplicationTermination. Clients who wish to exit the application without any event delivery or potential user interaction can call the lower level exit() function directly. [ChangeLog][QtGui] Application termination via qApp->quit() will now deliver Quit events to the application, which in turn will result in application windows being closed as part of the application quit, with an option to cancel the application quit by ignoring the close event. Clients who explicitly want to exit the application without any user interaction should call QCoreApplication::exit() explicitly. Task-number: QTBUG-45262 Task-number: QTBUG-33235 Task-number: QTBUG-72013 Task-number: QTBUG-59782 Change-Id: Id4b3907e329b9ecfd936fe9a5f8a70cb66b76bb7 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Use C++17 [[maybe_unused]]Allan Sandfeld Jensen2020-09-061-1/+1
| | | | | | | In some places needs to be ordered before const/constexpr though. Change-Id: I57a521ac0ad22b5a018761c4d52befbef69d64c0 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Get rid of hasPendingEvents() and flush()Lars Knoll2020-09-061-1/+0
| | | | | | | They are unused. Change-Id: I77383f2be45551401ed9c2f88285511134cc8b0d Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Change QWidget::enterEvent signature to take a QEnterEventVolker Hilsheimer2020-09-052-6/+5
| | | | | | | | | | | | | | | | | | | This is a source incompatible change for widget implementors. Leaving the old enterEvent as a virtual overload is problematic due to shadowing. Best to make a clean cut, widget reimplementors will get a compile time warning if they mark their override as such, or if they try to call the parent class implementation. Addresses ### Qt 6 comment. [ChangeLog][QtWidgets][QWidget] The virtual enterEvent handler now receives a QEnterEvent, which contains information about mouse position and button states, rather than a plain QEvent. Change-Id: I233f594fd79c0c090983b3db8532913d00132fde Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Long live QKeyCombination!Giuseppe D'Angelo2020-09-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | C++20 via P1120 is deprecating arithmetic operations between unrelated enumeration types, and GCC 10 is already complaining. Hence, these operations might become illegal in C++23 or C++26 at the latest. A case of this that affects Qt is in key combinations: a QKeySequence can be constructed by summing / ORing modifiers and a key, for instance: Qt::CTRL + Qt::Key_A Qt::SHIFT | Qt::CTRL | Qt::Key_G (recommended, see below) The problem is that the modifiers and the key belong to different enumerations (and there's 2 enumerations for the modifier, and one for the key). To solve this: add a dedicated class to represent a combination of keys, and operators between those enumerations to build instances of this class. I would've simply defined operator|, but again docs and pre-existing code use operator+ as well, so added both to at least tackle simple cases (modifier + key). Multiple modifiers create a problem: operator+ between them yields int, not the corresponding flags type (because operator+ is not overloaded for this use case): Qt::CTRL + Qt::SHIFT + Qt::Key_A \__________________/ / int / \______________/ int Not only this loses track of the datatypes involved, but it would also then "add" the key (with NO warnings, now its int + enum, so it's not mixing enums!) and yielding int again. I don't want to special-case this; the point of the class is that int is the wrong datatype. Everything works just fine when using operator| instead: Qt::CTRL | Qt::SHIFT | Qt::Key_A \__________________/ / Qt::Modifiers / \______________/ QKeyCombination So I'm defining operator+ so that the simple cases still work, but also deprecating it. Port some code around Qt to the new class. In certain cases, it's a huge win for clarity. In some others, I've just added the necessary casts to make it still compile without warnings, without attempting refactorings. [ChangeLog][QtCore][QKeyCombination] New class to represent a combination of a key and zero or more modifiers, to be used when defining shortcuts or similar. [ChangeLog][Potentially Source-Incompatible Changes] A keyboard modifier (such as Qt::CTRL, Qt::AltModifier, etc.) should be combined with a key (such as Qt::Key_A, Qt::Key_F1, etc.) by using operator|, not operator+. The result is now an object of type QKeyCombination, that stores the key and the modifiers. Change-Id: I657a3a328232f059023fff69c5031ee31cc91dd6 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Remove "fallback session management"Andreas Hartmetz2020-09-012-8/+0
| | | | | | | | | | | | | | With the Qt6 compatibility break, it can finally be removed. Closing windows (which might quit the application with quitOnLastWindowClosed() true, the default) acted contrary to the documentation of the commitDataRequest() signal, which could have been a hint. This removes the workaround API from the fix for QTBUG-49667 and also removes the problematic feature that it worked around. Change-Id: I672be58864ef062df7fb7f2a81658b92c4feedd2 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Display combobox popup on the correct screenMorten Johan Sørvig2020-08-301-7/+35
| | | | | | | | | | | Display QCompoBox popups on the correct screen, also when the parent window spans multiple screens. In this case, QWidget::screen() will return the main screen for the window, which will not necessarily be the screen at the combobox popup position. Change-Id: Ib8a8163a757f7b849883b833fbde27a1e01af49a Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Qt namespace: purge deprecated enum members and a typedefEdward Welbourne2020-08-281-1/+0
| | | | | | | | | | | | | | Since 5.0 - WFlags Since 5.6 - ItemIsTristate Since 5.14 - WA_NoBackground, WA_MacNoClickThrough, WA_MacBrushedMetal, WA_MacMetalStyle, WA_MSWindowsUseDirect3D WA_MacFrameworkScaled, ImMicroFocus Since 5.15 - MatchRegExp, MidButton (really since 5.7.0), WA_ContentsPropagated (really since 4.5.1, as are the following), WA_WState_DND, WA_ForceAcceptDrops. Change-Id: Ib1db3d85bf28823c704b5f3857546764b158e1ed Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch>
* Mark some Qt namespace enum members properly as deprecatedEdward Welbourne2020-08-271-2/+1
| | | | | | | | | | | | | | | | A comment is not good enough, Some of the enum members were even still in use, or mentioned in documentation. WA_ContentsPropagated, WA_WState_DND and WA_ForceAcceptDrops have been deprecated since 4.5.1; and at least the last has been an \omitvalue in the docs for even longer. (WA_ShowModal and WA_GroupLeader have been similarly marked, but are in use, see QTBUG-85816.) Push back to 5.15.1 in order to be able to remove these at Qt 6. Pick-to: 5.15.1 Change-Id: I6ea3839767e5f5158b0fed508f65798470191908 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QLayout::indexOf: redo implementationGiuseppe D'Angelo2020-08-261-12/+10
| | | | | | | | | | | | Stop relying on the "magic" of itemAt returning nullptr for out of bounds. Just use count(). Unfortunately, QMainWindowLayout breaks the API contract by NOT implementing count() properly. So, make its count() crash if called; and move the itemAt implementation there. Change-Id: I120686a834bab15dd537598a56bd93d6a5924aa5 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Introduce QWindow::paintEvent with QPA plumbingTor Arne Vestbø2020-08-261-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The explicit paint event on QtGui and QPA level allows us to untangle the expose event, which today has at least 3 different meanings. It also allows us to follow the platform more closely in its semantics of when painting can happen. On some platforms a paint can come in before a window is exposed, e.g. to prepare the first frame. On others a paint can come in after a window has been de-exposed, to save a snapshot of the window for use in an application switcher or similar. The expose keeps its semantics of being a barrier signaling that the application can now render at will, for example in a threaded render loop. There are two compatibility code paths in this patch: 1. For platform plugins that do not yet report the PaintEvents capability, QtGui will synthesize paint events on the platform's behalf, based on the existing expose events coming from the platform. 2. For applications that do not yet implement paintEvent, QtGui will send expose events instead, ensuring the same behavior as before. For now none of the platform plugins deliver paint events natively, so the first compatibility code path is always active. Task-numnber: QTBUG-82676 Change-Id: I0fbe0d4cf451d6a1f07f5eab8d376a6c8a53ce8c Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
* macOS: rename 'macintosh' style to 'macos'Richard Moe Gustavsen2020-08-261-1/+1
| | | | | | | | | | | | | | Change the name/key of the style to 'macos'. Besides the name 'macintosh' being archaic, we also need this change to avoid creating 'macintosh' style folders in QtQuickControls, now that we plan to use QPlatformTheme also there to resolve the style. [ChangeLog][Widgets][QStyle] The 'macintosh' style has been renamed to 'macos'. Change-Id: I14b8a8b4dbd369e7a7d16b94e4ad27e501e7e8d0 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Rename confusingly named QFont/QPalette::resolve overloadsVolker Hilsheimer2020-08-253-20/+20
| | | | | | | | | | | | | | | Having three methods with the same name doing different things is unnecessarily confusing, so follow the standard naming convention in Qt and call the getter of the resolve mask resolveMask, and the setter setResolveMask. These methods were all documented as internal. The publicly documented resolve() method that merges two fonts and palettes based on the respective masks remains as it is, even though 'merge' would perhaps be a better name. Change-Id: If90b1ad800834baccd1dbc38fc6b861540d6df6e Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Move QStateMachine from QtCore to QtScxmlKarsten Heimrich2020-08-244-14/+171
| | | | | | Task-number: QTBUG-80316 Change-Id: I2ee74110fd55e94d86321d3b3dc5bb8297424ed4 Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
* Add a metatype helper class for Qt CoreLars Knoll2020-08-241-3/+0
| | | | | | | | | This helps get better symmetry with the other modules, and to unify the code paths for both conversion and retrieving the interface for static types. Change-Id: Icbd20de2563f36e3de20d826323acd057734abfb Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Use QMetaTypeModuleHelper as the interface to do type conversionsLars Knoll2020-08-241-15/+0
| | | | | | | | | | | | | | Move the type conversions from QVariant::Helper to QMetaType. Only do this for Qt Gui in a first step. This makes it possible to completely remove the Handler struct in QVariant, and now allows QMetaType to also convert Gui types. Moving the conversion of Core types into QMetaType will require further work. Change-Id: I061f789deca1b595d92bb29227eb54b8e71a3ee3 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Remove some dead codeLars Knoll2020-08-241-15/+0
| | | | | | | | This code is now unused, as streaming operators are registered automatically. Change-Id: I0e48944c33a92cf1f2f158fb2dc0ca49256d7938 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Get rid of the custom debug stream handling in QVariantLars Knoll2020-08-241-20/+1
| | | | | | | | Use the builtin support in QMetaType instead. Change-Id: Ifc0e88719a384aa7fb525652bada22b6f7ee1c45 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QWidget: drop an unncessary const_castGiuseppe D'Angelo2020-08-241-1/+1
| | | | | | | Thanks to the newly introduced indexOf overload. Change-Id: I00377591dba4104f1dfd34816cc74efcf5220a4d Reviewed-by: David Faure <david.faure@kdab.com>
* QSizePolicy: Fix warning about mixing different enumsMarcel Krems2020-08-231-2/+2
| | | | | | | | warning: C5054: operator '&': deprecated between enumerations of different types Pick-to: 5.15 Change-Id: I4e48a44f089d3eaca5d3f876da01335051192b28 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QLayout: make its indexOf functions take pointer-to-constGiuseppe D'Angelo2020-08-232-5/+5
| | | | | | | | | | | | | | | | | | | | | Try to fix an API mistake there: there is no reason why these functions should take pointers to non-const widgets, as that actually preventing reasonable code (e.g. finding out the index of "this" inside a const method of a QWidget subclass). Unfortunately, indexOf(QWidget*) is also virtual, meaning that changing its signature is an API break. Hopefully, there are only few users that override this method (Woboq says 0). [ChangeLog][Potentially Source-Incompatible Changes] The QLayout::indexOf(QWidget *) virtual function has changed signature, becoming QLayout::indexOf(const QWidget *). This is source incompatible, although the fix (for the few users that do override indexOf() in their layouts) is straightforward. Change-Id: Id2183f5ecd9dc7e2a37c7355266e8494ef7929f2 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* QGuiApplication: fix handling of spontaneous events' modifiersNicolas Guichard2020-08-201-53/+1
| | | | | | | | | | | | | | | | | | | | | | | | | QtQuickTest synthetized events can have modifiers, but those modifiers were not accessible globally, from QGuiApplication::keyboardModifiers for instance. eg. calling QML's TestCase::mouseClick with modifiers triggering a call to QGuiApplication::keyboardModifiers did not give the expected result. QtTest synthesised events can also have modifiers and those were correctly handled by QApplication to set modifiers globally. This fix moves the handling code from QApplication::notify to QGuiApplicationPrivate::maybeSimulateModifiers and calls this function from QGuiApplication::notify too. The definite fix would be to do as suggested in the comment attached to the moved code: > Qt Test should not call qapp->notify(), but rather route the events > through the proper QPA interface. This is required to properly > generate all other events such as enter/leave etc. Pick-to: 5.15 5.12 Change-Id: I734e5bbc82232b13828b1a1f82e06ee8eb695417 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Fix a number of qdoc warningsFriedemann Kleint2020-08-201-2/+2
| | | | | | | | | | | - Remove obsolete functions and enumeration values - Remove QObject * parameter from QMetaProperty accessors - Fix renamed enumerations in QSsl - Fix list items to be \li - Fix function signatures and variable names Change-Id: I37c7e6bf2c8ff92bc7b82620bae0a27796f866ab Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Use [[nodiscard]] with clang in C++17 modeAllan Sandfeld Jensen2020-08-182-4/+4
| | | | | | | | | | It is only broken in C++11/c++14 mode. We do need to fix the order of visibility-attributes and this C++ attribute. Change-Id: I41e4367f1aaa9241fec4e336c39e58b798336b2c Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Move QDesktopWidget API used by QApplication into QDesktopWidgetVolker Hilsheimer2020-08-173-10/+15
| | | | | | | | | | | QDesktopWidget is not a public class anymore and only exists for compatibility reasons. So we might just as well move the only method used by other classes out of QDesktopWidgetPrivate, and get rid of the friend declarations and the access-to-private code in QApplication. Change-Id: I74ff14233e59912e0930f98995f8af60dbadfdb6 Task-number: QTBUG-62094 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Introduce QWidget::setScreenVolker Hilsheimer2020-08-174-58/+33
| | | | | | | | | | | | | | | | | | Follows the QWindow semantics, and is a replacement for creating a QWidget with a QDesktopScreenWidget as the parent. We can now remove much of the special handling of QDesktopWidget and the Qt::Desktop window type, and get rid of QDesktopScreenWidget. Add a manual test that allows local testing. Our CI environments only have a single screen, and no multi-head display server setup which is the primary case where QWidget::setScreen is interesting. For the more common case of a virtual desktop, QWidget::setScreen has no real impact (just as QWindow::setScreen doesn't). Change-Id: Id0099e069d316741bacd8c795c396ccad37be297 Fixes: QTBUG-85483 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Remove QVariant(int type, void *data, ...) constructorLars Knoll2020-08-151-1/+1
| | | | | | | | It was marked internal anyway. Use the constructor taking a QMetaType instead. Change-Id: I15b9cd0911aac063a0f0fe0352fa2c84b7f7c691 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Replace Qt CONSTEXPR defines with constexprAllan Sandfeld Jensen2020-08-141-59/+25
| | | | | | | | Both normal and relaxed constexpr are required by our new minimum of C++17. Change-Id: Ic028b88a2e7a6cb7d5925f3133b9d54859a81744 Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
* Doc: Change QPixmap::grabWindow with QScreen::grabWindowAndy Shaw2020-08-141-1/+1
| | | | | | Change-Id: I68df86314cb8c3602d7ddbcf1e4527cf247d5fa1 Pick-to: 5.15 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Restrict QVariant::isNull() behaviorLars Knoll2020-08-131-6/+0
| | | | | | | | | | | | | | | | | | | | | isNull() would forward to the contained type and check that type's isNull() method for some of the builtin types. Remove that behavior and only return true in isNull(), if the variant is invalid, doesn't contain data or contains a null pointer. In addition, implement more consistent behavior when constructing a QVariant using the internal API taking a copy from a void *. isNull() should return true in both cases. This mainly changes behavior for some corner cases and when using our internal API. [ChangeLog][Important Behavior Changes] QVariant::isNull() no longer returns true when the variant contains an object of some type with an isNull() method, that returns true for the object; QVariant::isNull() now only returns true when the variant contains no object or a null pointer. Change-Id: I3125041c4f8f8618a04aa375aa0a56b19c02dcf5 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Use the new support for comparisons in QMetaType for QVariantLars Knoll2020-08-131-13/+0
| | | | | | | | | | | | | | Remove the compare method in the QVariant::Handler struct. Rely on the generic support provided by QMetaType instead. [ChangeLog][Important Behavior Changes][QVariant] QVariant will now use builtin support in QMetaType to compare its content. This implies a behavioral change for some graphical types like QPixmap, QImage and QIcon that will never compare equal in Qt 6 (as they do not have a comparison operator). Change-Id: I30a6e7116c89124d11ed9052537cecc23f78116e Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* QLayout: minor tidy in the docsGiuseppe D'Angelo2020-08-101-1/+1
| | | | | Change-Id: Ifc2aa62a9c9480c85cc36f60941411e920066db8 Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
* Long Live QMap as a refcounted std::map!Giuseppe D'Angelo2020-08-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... and QMultiMap as std::multimap. Just use the implementation from the STL; we can't really claim that our code is much better than STL's, or does things any differently (de facto they're both red-black trees). Decouple QMultiMap from QMap, by making it NOT inherit from QMap any longer. This completes the deprecation started in 5.15: QMap now does not store duplicated keys any more. Something to establish is where to put the QExplictlySharedDataPointer replcement that is in there as an ad-hoc solution. There's a number of patches in-flight by Marc that try to introduce the same (or very similar) functionality. Miscellanea changes to the Q(Multi)Map code itself: * consistently use size_type instead of int; * pass iterators by value; * drop QT_STRICT_ITERATORS; * iterators implictly convert to const_iterators, and APIs take const_iterators; * iterators are just bidirectional and not random access; * added noexcept where it makes sense; * "inline" dropped (churn); * qMapLessThanKey dropped (undocumented, 0 hits in Qt, 1 hit in KDE); * operator== on Q(Multi)Map requires operator== on the key type (we're checking for equality, not equivalence!). Very few breakages occur in qtbase. [ChangeLog][Potentially Source-Incompatible Changes] QMap does not support multiple equivalent keys any more. Any related functionality has been removed from QMap, following the deprecation that happened in Qt 5.15. Use QMultiMap for this use case. [ChangeLog][Potentially Source-Incompatible Changes] QMap and QMultiMap iterators random-access API have been removed. Note that the iterators have always been just bidirectional; moving an iterator by N positions can still be achieved using std::next or std::advance, at the same cost as before (O(N)). [ChangeLog][Potentially Source-Incompatible Changes] QMultiMap does not inherit from QMap any more. Amongst other things, this means that iterators on a QMultiMap now belong to the QMultiMap class (and not to the QMap class); new Java iterators have been added. Change-Id: I5a0fe9b020f92c21b37065a1defff783b5d2b7a9 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Remove last remaining bits of QtPlatformHeadersTor Arne Vestbø2020-08-041-2/+0
| | | | | | Task-number: QTBUG-84220 Change-Id: I951e04bfe9358a99951d1d61ff47b675584b7f81 Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* Ensure styles always get to polish the application paletteTor Arne Vestbø2020-07-211-17/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Before 0a93db4d82c051164923a10e4382b12de9049b45 we would polish the application palette even when it was the default palette, as we always recreated the system palette each time a style was set. After the change we skipped polishing the palette unless it was set by the user, under the assumption that the style would set its own default palette if it wanted to override the system palette. This turned out to break the style's ability to slightly tweak the palette via polish (versus the more full on standardPalette approach). We now polish both the default palette and user palettes, and we do so as part of the normal palette update logic. This ensures that the style also gets a chance to polish the palette when the platform theme changes. The polish will not have an effect on the resolve mask of the palette, as the polish is conceptually the same as a base palette, and should not affect e.g. Qt::AA_SetPalette. Fixes: QTBUG-85469 Fixes: QTBUG-85188 Pick-to: 5.15 Change-Id: I869e9c442b177de4f1dc49eb75220709306f4d12 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Add QXcbWindow platform interfaceTor Arne Vestbø2020-07-201-24/+46
| | | | | | Task-number: QTBUG-84220 Change-Id: I8bb4288f1ac06d77fb4f43ae091fa1712f694eeb Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* QtGui: Rename all QEvent members according to the m_ conventionFriedemann Kleint2020-07-161-4/+6
| | | | | | | | | | | As they are protected, they need to be excluded from the Python bindings, which is best done by a pattern. Task-number: PYSIDE-1339 Task-number: PYSIDE-904 Change-Id: I667aa3b8e229e11b3b46635adfddbd62ce4747c1 Reviewed-by: Cristian Maureira-Fredes <cristian.maureira-fredes@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Allow Windows accessibility backend to receive focus updatesAndre de la Rocha2020-07-151-5/+0
| | | | | | | | | | | | | | | | The removed code no longer applies to the current Windows accessibility backend, and was causing it to miss focus change events when the application UI contained one or more widgets associated with native window handles, or when the Qt::AA_NativeWindows application attribute was set. This caused accessibility tools like Narrator to miss changes in the focused widget. Fixes: QTBUG-81862 Pick-to: 5.15 Change-Id: I6e42d09c54e9e1338fc4b103eba8a0b2c4309e7f Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* Remove wrapper APIs from QDesktopWidgetPrivateVolker Hilsheimer2020-07-141-45/+0
| | | | | Change-Id: I99e7d82a9e369fee23bcc565553ad9783fa862f9 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Change QWindow/QWidget::map(To/From)(Global/Parent) to operate in floatFriedemann Kleint2020-07-144-23/+78
| | | | | | | | | | | | | | | Change the functions to operate in float and add the QPoint versions as overload calling them. This is more in-line with the event accessors using float and allows for removing some workarounds using a delta when converting touch points. Leave QPlatformWindow::map(To/From)Global() as is for now and add helpers for float. Change-Id: I2d46b8dbda8adff26539e358074b55073dc80b6f Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Remove support for users to create their own Qt::Desktop type widgetsVolker Hilsheimer2020-07-131-20/+15
| | | | | | | | | | [ChangeLog][QtWidgets][QWidget] Creating QWidget instances with the Qt::Desktop window type set is no longer supported. Change-Id: I712861d7104c4ae5cbdd5d54cd0134bf69eb144e Task-number: QTBUG-62094 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Refactor pointer event hierarchyShawn Rutledge2020-07-104-65/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some goals that have hopefully been achieved are: - make QPointerEvent and QEventPoint resemble their Qt Quick counterparts to such an extent that we can remove those wrappers and go back to delivering the original events in Qt Quick - make QEventPoint much smaller than QTouchEvent::TouchPoint, with no pimpl - remove most public setters - reduce the usage of complex constructors that take many arguments - don't repeat ourselves: move accessors and storage upwards rather than having redundant ones in subclasses - standardize the set of accessors in QPointerEvent - maintain source compatibility as much as possible: do not require modifying event-handling code in any QWidget subclass To avoid public setters we now introduce a few QMutable* subclasses. This is a bit like the Builder pattern except that it doesn't involve constructing a separate disposable object: the main event type can be cast to the mutable type at any time to enable modifications, iff the code is linked with gui-private. Therefore event classes can have less-"complete" constructors, because internal Qt code can use setters the same way it could use the ones in QTouchEvent before; and the event classes don't need many friends. Even some read-accessors can be kept private unless we are sure we want to expose them. Task-number: QTBUG-46266 Fixes: QTBUG-72173 Change-Id: I740e4e40165b7bc41223d38b200bbc2b403e07b6 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Rename local variables masking parametersDimitrios Apostolou2020-07-101-6/+6
| | | | | | | As found by LGTM.com. Change-Id: I9a237899dc50009da5643c49c590f3b15bb817bf Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-04 09:55:10 +0000