summaryrefslogtreecommitdiffstats
path: root/src/widgets/kernel/qwidgetwindow.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Windows: Fix dialog moving up after closing/reshowingFriedemann Kleint2021-01-151-1/+5
| | | | | | | | | | | | A resize event delivered after closing the platform window was causing the stored frame margins to be cleared. Bail out of QWidgetWindow::updateMargins() if the platform window is null. Pick-to: 5.15 Fixes: QTBUG-79147 Change-Id: Iebbc90c3cccafa209cd720baedf45affb3f3c2b8 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* QWidget: mark obsolete function isTopLevel() as deprecatedChristian Ehrlicher2020-12-091-1/+1
| | | | | | | | QWidget::isTopLevel() is deprecated and can be replaced 1:1 with isWindow(). Sadly it's was not marked with Q_DECL_DEPRECATED in 5.15 Change-Id: I4508fbde41927f3b82e47a75011179548325029d Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* QtWidgets: Propagate event device when translating mouse eventsFriedemann Kleint2020-11-271-2/+4
| | | | | | | | | | | There are a few places left over, for example the QTextEdit creating mouse events in a timer and notably QGraphicsView. Task-number: QTBUG-88678 Task-number: QTBUG-46412 Pick-to: 6.0 Change-Id: I7ed23911be3b86b4b39fb478b947ec3b7a60761f Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* Adjust code format, add space after 'if'Zhang Sheng2020-11-161-1/+1
| | | | | | Change-Id: Ice081c891ff7f4b766f49dd4bd5cf18c30237acf Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io> Reviewed-by: hjk <hjk@qt.io>
* Track grab state in QPointingDevicePrivate::activePointsShawn Rutledge2020-09-161-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* 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>
* Change QWindow/QWidget::map(To/From)(Global/Parent) to operate in floatFriedemann Kleint2020-07-141-5/+5
| | | | | | | | | | | | | | | 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>
* Refactor pointer event hierarchyShawn Rutledge2020-07-101-6/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Add ; to Q_UNUSEDLars Schmertmann2020-07-071-2/+2
| | | | | | | | This is required to remove the ; from the macro with Qt 6. Task-number: QTBUG-82978 Change-Id: I3f0b6717956ca8fa486bed9817b89dfa19f5e0e1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Remove unused virtual method QWindowPrivate::allowClickThroughVolker Hilsheimer2020-07-071-6/+0
| | | | | | | Always returned true, also in the QWidgetWindowPrivate override. Change-Id: I01d11ae6f85882b52ce397125f994eea663ffcb5 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Fix delivery of MouseMove events to newly opened popup windowsVolker Hilsheimer2020-07-011-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | Amend d934fd7f54eae24ea3f719890e2c4dbbc445049d, which was too naive in assuming that any change to the popup stack while a popup had been pressed into should result in mouse move events to be delivered without buttons. Instead, add a new flag that is set explicitly when the qt_popup_down widget is closed, and remove buttons from the move move events only when that flag is set. Add the sorely missing test case as well, even if we have to accept that not all behavior can be tested reliably. Ie. on macOS, the simulated mouse event differs from the event we do get from the QPA plugin or the system; on Xcb, some of the behavior depends on the window manager. This is something we could try to clean up for Qt 6. Change-Id: Ibf0a0a6fb7d401915057365788947e5a35aa20c3 Fixes: QTBUG-84926 Task-number: QTBUG-82538 Pick-to: 5.15 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Liang Qi <liang.qi@qt.io>
* Introduce QInputDevice hierarchy; replace QTouchDeviceShawn Rutledge2020-06-161-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have seen during the Qt 5 series that QMouseEvent::source() does not provide enough information: if it is synthesized, it could have come from any device for which mouse events are synthesized, not only from a touchscreen. By providing in every QInputEvent as complete information about the actual source device as possible, we will enable very fine-tuned behavior in the object that handles each event. Further, we would like to support multiple keyboards, pointing devices, and named groups of devices that are known as "seats" in Wayland. In Qt 5, QPA plugins registered each touchscreen as it was discovered. Now we extend this pattern to all input devices. This new requirement can be implemented gradually; for now, if a QTWSI input event is received wtihout a device pointer, a default "core" device will be created on-the-fly, and a warning emitted. In Qt 5, QTouchEvent::TouchPoint::id() was forced to be unique even when multiple devices were in use simultaneously. Now that each event identifies the device it came from, this hack is no longer needed. A stub of the new QPointerEvent is added; it will be developed further in subsequent patches. [ChangeLog][QtGui][QInputEvent] Every QInputEvent now carries a pointer to an instance of QInputDevice, or the subclass QPointingDevice in case of mouse, touch and tablet events. Each platform plugin is expected to create the device instances, register them, and provide valid pointers with all input events. If this is not done, warnings are emitted and default devices are created as necessary. When the device has accurate information, it provides the opportunity to fine-tune behavior depending on device type and capabilities: for example if a QMouseEvent is synthesized from a touchscreen, the recipient can see which touchscreen it came from. Each device also has a seatName to distinguish users on multi-user windowing systems. Touchpoint IDs are no longer unique on their own, but the combination of ID and device is. Fixes: QTBUG-46412 Fixes: QTBUG-72167 Task-number: QTBUG-69433 Task-number: QTBUG-52430 Change-Id: I933fb2b86182efa722037b7a33e404c5daf5292a Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Replace calls to deprecated QEvent accessor functionsShawn Rutledge2020-06-081-33/+33
| | | | | | | Many of these were generated by clazy using the new qevent-accessors check. Change-Id: Ie17af17f50fdc9f47d7859d267c14568cc350fd0 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Fix to crash in QWindow::event when delete this called on closeEventMiika Pernu2020-06-041-2/+6
| | | | | | | | | | | | | Starting from Qt 5.11 QWindow::event is called after QDialog::closeEvent which would cause a crash if "delete this" was called on closeEvent. The commit that changed this was e0b5ff4ad583befbecbcbe462998e3ed80899531. Added a check before QWindow::event call utilizing QPointer to prevent the function call in case object is destroyed by a user in close event handler. Change-Id: I64a4a0f3271714e55bf7e806177f0d8b39b67fa3 Fixes: QTBUG-84222 Pick-to: 5.15 5.12 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Remove obsolete storage, constructors and accessors in QEvent subclassesShawn Rutledge2020-05-121-4/+0
| | | | | Change-Id: I5c51244031ff40f1972106ad4fe27010c8be1193 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Remove dead code from src/widgetsVolker Hilsheimer2020-05-111-4/+0
| | | | | | | | Code that's removed via QT_VERSION(6, 0, 0) check is already no longer compiled. Change-Id: I70865f330a6260ac2e9cf2770d599a5b6f7bb7d4 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* macOS: Remove all use of deprecated Q_OS_OSX defineTor Arne Vestbø2020-04-031-2/+2
| | | | | Change-Id: I49c285604694c93d37c9d1c7cd6d3b1509858319 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Merge remote-tracking branch 'origin/5.14' into 5.15Liang Qi2020-03-311-3/+5
|\ | | | | | | | | | | | | Conflicts: tests/auto/widgets/itemviews/qabstractitemview/tst_qabstractitemview.cpp Change-Id: Ifaa56153f5f0d687a6b4d94f84fcfa1e1751afd2
| * Send MouseMove events without buttons if the press closed the popupVolker Hilsheimer2020-03-301-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | widgets: Sync client rect of paint-on-screen widgets during resizeTor Arne Vestbø2020-03-271-4/+4
| | | | | | | | | | | | | | | | | | | | | | 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>
* | widgets: Remove unused member QTLWExtra::inTopLevelResizeTor Arne Vestbø2020-03-191-1/+1
| | | | | | | | | | | | | | | | | | 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>
* | Avoid using deprecated QTabletEvent::device() methodAllan Sandfeld Jensen2020-02-281-1/+1
| | | | | | | | | | | | | | | | It was renamed to QTabletEvent::deviceType() in 882f340f62b8dc34633f5f296be12243b6e8999d. Change-Id: I070404bfc9a04144ae3565bfa3cc3a016040a07d Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | widgets: Translate QWindow move events into widget relative positionTor Arne Vestbø2020-02-191-15/+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>
* | Tidy nullptr usageAllan Sandfeld Jensen2019-12-061-17/+17
|/ | | | | | | | | | | 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.13' into 5.14Qt Forward Merge Bot2019-11-061-2/+10
|\ | | | | | | | | | | | | | | | | | | | | Conflicts: .qmake.conf mkspecs/features/mac/default_post.prf src/corelib/tools/qsimd_p.h src/platformsupport/fontdatabases/mac/qcoretextfontdatabase.mm util/qfloat16-tables/gen_qfloat16_tables.cpp Change-Id: If48fa8a3bc3c983706b609a6d3822cb67c1352a4
| * Ensure that child windows are visible again when showing their parentAndy Shaw2019-10-291-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When a window is closed, then it will cause the child windows to be closed as well as a result. Therefore in order to ensure that they are shown again as a result, we need to remove the WA_WState_ExplicitShowHide attribute if the widget was not already hidden before. This enables us to test for this attribute when calling showChildren(), so that if the window has a windowHandle then we can make sure that this widget is shown again. Fixes: QTBUG-73021 Change-Id: I1186242b889899dfcd38d782a67567348e2055ee Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* | Merge remote-tracking branch 'origin/5.13' into 5.14Qt Forward Merge Bot2019-10-241-9/+13
|\| | | | | | | | | | | | | | | | | Conflicts: src/corelib/io/qstandardpaths_unix.cpp src/corelib/tools/qsharedpointer_impl.h tests/auto/corelib/tools/qsharedpointer/tst_qsharedpointer.cpp Change-Id: Iae95c5778dc091058f16f6db76f04a0178a9e809
| * Drag'n'Drop: fix crash when widgets are destroyed during event handlingVolker Hilsheimer2019-10-101-9/+13
| | | | | | | | | | | | | | | | | | | | | | | | Widgets might be destroyed when handling a dragMoveEvent, in which case the following code will operate on dangling pointers or null pointers. Use a QPointer to watch for the original event receiver to disappear, and add the necessary checks for the objects we deliver events to being null. Change-Id: I4ca2f182540ae21113f4bea4e5c569e983cc58bf Fixes: QTBUG-78907 Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
* | widgets: Rename QWidgetPrivate::repaint_sys to paintOnScreenTor Arne Vestbø2019-08-251-1/+1
| | | | | | | | | | Change-Id: Ic853e42cbed9b770bef0e1d7c7376c861bceb891 Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
* | Rename QWidgetBackingStore to QWidgetRepaintManagerTor Arne Vestbø2019-08-201-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Quoting a blog from 2009, "this class is responsible for figuring out which parts of the window surface needs to be updated prior to showing it to screen, so it's really a repaint manager." https://blog.qt.io/blog/2009/12/16/qt-graphics-and-performance-an-overview/ What better time to do the rename than 10 years later! Change-Id: Ibf3c3bc8c7df64ac03d72e1f71d296b62d832fee Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* | Get rid of QWidgetBackingStoreTrackerTor Arne Vestbø2019-08-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | It was added for Symbian almost 10 years ago (d7057e7c1f1a), for a somewhat dubious use-case. The Symbian code is since long gone (ae30d7141), so the remaining pieces are just adding complexity to the already intricate workings of the QtWidgets backingstore/painting logic. Task-number: QTBUG-8697 Change-Id: I82af610a8ac26719c588ac63f06b4501f59b400d Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io> (cherry picked from commit 2e0b0be2ce30394269559590b42c81de27301ee6) Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* | Finish deprecating obsolete members of QWheelEventShawn Rutledge2019-07-121-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | QtWidgets: Fix static method invocationsFriedemann Kleint2019-06-281-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Add accessors for QWindow and QScreen to QWidgetPrivateFriedemann Kleint2019-06-181-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rewrite the existing accessor QWidgetPrivate::windowHandle() to accept a mode enumeration that has an "Any" convenience. Based on that, add QWidgetPrivate::associatedScreen(), which is seful in many places where scaling is performed. Prototypically simplify the code. Task-number: QTBUG-62094 Task-number: QTBUG-73231 Change-Id: I516288363d329bce9bc94e4951106f9357bc6cde Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* | QtCore: mark obsolete enumerations as deprecatedChristian Ehrlicher2019-05-171-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following enumerations were obsolete for a log time but not marked as deprecated: - WA_NoBackground - WA_MacNoClickThrough - WA_MacBrushedMetal - WA_MacMetalStyle - WA_MSWindowsUseDirect3D - WA_MacFrameworkScaled - AA_MSWindowsUseDirect3DByDefault - AA_X11InitThreads - ImMicroFocus mark them as deprecated and remove the usage inside QtBase so they can be removed with Qt6 Change-Id: Ia087a7e1d0ff1945286895be6425a6cceaa483fb Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* | Merge remote-tracking branch 'origin/5.13' into devLiang Qi2019-04-101-2/+0
|\| | | | | | | | | | | | | | | Conflicts: mkspecs/win32-clang-msvc/qmake.conf src/gui/image/qpnghandler.cpp Change-Id: Ied79d02912ffb3a307a99483df7db08c7f9d0cd8
| * Drag'n'Drop: fix dnd regressionGatis Paeglis2019-03-261-2/+0
| | | | | | | | | | | | | | | | | | | | DragEnter events always should start with the default state, which is accepted = false. This was a copy-and-paste error introduced by f8944a7f07112c85dc4f66848cabb490514cd28e. Fixes: QTBUG-73977 Change-Id: I34b3ea97c9b4f4fc040a9e6f1befd6124533361d Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* | Implement support for WA_MacNoClickThroughAndy Shaw2019-04-011-0/+7
| | | | | | | | | | | | | | | | | | | | This is done by adding a QWindowPrivate::allowsClickThrough() function, so this could easily be adapted later on if desired for other platforms. Fixes: QTBUG-41126 Change-Id: I1157e5e7e7667ff11d1a5d21b3ce8c4b13202272 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* | Widen out parameter "result" of the native event filters for Qt 6Friedemann Kleint2019-03-221-0/+4
|/ | | | | | | | | LRESULT on Windows 64 is a 64bit type, adapt filter functions of QAbstractNativeEventFilter and QAbstractEventDispatcher accordingly. Fixes: QTBUG-72968 Change-Id: Ie53193e355f0b8e9bd59fa377f43e2b4664a2ded Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Widgets: Only set WA_WState_ExplicitShowHide via public APITor Arne Vestbø2019-02-121-1/+1
| | | | | | | | | | | Calling QWindow::setVisible doesn't have the same semantics, so we split off QWidget::setVisible into QWidgetPrivate::setVisible and call that instead from QWidgetWindow. Task-number QTBUG-67504 Change-Id: Ie50938d4a1d33ad4b59c742e75e3ca30f1b19399 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Drag'n'Drop: fix dnd when dragMoveEvent() is not implementedChristian Ehrlicher2019-01-071-2/+5
| | | | | | | | | | | | | | | | The refactoring of dnd with f8944a7f07112c85dc4f66848cabb490514cd28e added a regression which results in a need to reimplement dragMoveEvent() on the drop side. Before this change it was possible to accept the dnd in dragEnterEvent() without again accepting it in dragMoveEvent(). Fix it in a similar way it's done in QGuiApplicationPrivate::processDrag() by prefilling the first simulated QDragMoveEvent with the values from the previous QDragEnterEvent before it is sent to the drop receiver. Fixes: QTBUG-72844 Change-Id: I1300dd02b7f1d9dcd44ecefa8335f92ad6c6cafa Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
* Make sure mouse release events are delivered to correct widgetPaul Olav Tvete2018-11-121-1/+2
| | | | | | | | | | | | | The initial mouse press should create an implicit mouse grab so that all subsequent mouse events are delivered to the widget that was pressed first. After commit a4f7bb8733e0, every mouse press would reset the implicit grab. This change checks the previous button state, and does not reset the mouse grab if other buttons are already pressed. Fixes: QTBUG-70816 Change-Id: Icdd215c2f4aaee3c3f34607d68c1d8878155ec17 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QWidgetWindow: check if receiver is deleted after event deliveryRichard Moe Gustavsen2018-11-071-1/+1
| | | | | | | | | | | | | | | | | | When a popup is active, we set the receiver of mouse events to be the active popup widget. But when we send a mouse event to the popup, the receiver might start a new QEventLoop (e.g by executing a new dialog). And in the meantime, the popup will be destroyed. This will cause a crash in the line after the event delivery (where we sat "qt_last_mouse_receiver = receiver"), since at that point, "receiver" would be a dangling pointer. This patch will use a QPointer instead of a raw pointer to store "receiver", to ensure that it's set to null for such cases. Fixes: QTBUG-71062 Change-Id: Ie017cfa97370513ecfdd62c056fcb0e6c991f9f6 Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
* Ensure that QTabletEvent is not pre-accepted before sendingShawn Rutledge2018-09-251-0/+1
| | | | | | | | | | | | | | | | | | | | | In QWidget-world it's normal for input events to have the accepted flag false by default, so that it's obvious after visiting a widget subclass that does not override a particular handler function that it did not handle that event type at all. For tablet events in particular, the contract (to which we've been paying more attention to ensure that QTBUG-47007 remains properly fixed) is that if a QTabletEvent is not accepted, a mouse event will follow. Tablet-unaware applications need to get the same mouse events from a Wacom stylus as they would receive from an actual mouse. In this case the issue was missing hover events (mouse movements in which no mouse button is pressed). Without those, the enterEvent and exitEvent virtuals are also not invoked properly. Task-number: QTBUG-47007 Task-number: QTBUG-65199 Change-Id: I957005aad9d2bf85a3a41bbdebe3e046e34dee4d Reviewed-by: Andy Shaw <andy.shaw@qt.io>
* QWidgetWindow: Ensure Qt::WA_Mapped is set on obscured parent widgetsFriedemann Kleint2018-08-211-0/+3
| | | | | | | | | | | | Frameless obscured windows do not receive WM_PAINT/expose events on Windows. Qt::WA_Mapped needs to be set on them to ensure updating works. Task-number: QTBUG-39220 Task-number: QTBUG-52039 Task-number: QTBUG-58575 Task-number: QTBUG-63927 Change-Id: Ic6c11f2be96378b6a6b61296f1f3e13cd49b50a6 Reviewed-by: Andy Shaw <andy.shaw@qt.io>
* widgetwindow: send DragMove for every DragEnterGatis Paeglis2018-06-251-46/+65
| | | | | | | | | | ... as specified in the documentation. This was a regression from Qt4 and can cause mouse cursor flickering durig dragging on e.g. custom widget where some areas of the widget do not accept drag-and-drop. Task-number: QTBUG-67155 Change-Id: Iaa6f9407181931ed8e3d6a8fec13fd59d3c8625d Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Merge remote-tracking branch 'origin/5.11' into devLiang Qi2018-06-071-3/+3
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: .qmake.conf src/corelib/kernel/qeventdispatcher_cf.mm src/gui/kernel/qguiapplication_p.h src/gui/kernel/qwindowsysteminterface.cpp src/gui/kernel/qwindowsysteminterface.h src/plugins/platforms/cocoa/qcocoawindow.mm src/plugins/platforms/cocoa/qnswindowdelegate.mm src/plugins/platforms/ios/qioseventdispatcher.mm src/plugins/platforms/windows/qwindowsdrag.h src/plugins/platforms/windows/qwindowsinternalmimedata.h src/plugins/platforms/windows/qwindowsmime.cpp src/plugins/platforms/winrt/qwinrtscreen.cpp Change-Id: Ic817f265c2386e83839d2bb9ef7419cb29705246
| * Make sure we can build with -no-feature-draganddropJoerg Bornemann2018-05-291-3/+3
| | | | | | | | | | | | | | | | | | We move QInternalMimeData to a separate file, because this class is used, even if draganddrop is disabled. From now on, include qinternalmimedata_p.h instead of qdnd_p.h for QInternalMimeData. Change-Id: I594e08e2e90d574dc445119091686b4b69e4731b Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
* | Merge remote-tracking branch 'origin/5.11' into devQt Forward Merge Bot2018-05-021-0/+1
|\| | | | | | | Change-Id: Ia082e20e2eb4b76afd4c1a1584ff4e5514655d7a
| * QWidgetWindow: Immediately forward close events to QWindowUlf Hermann2018-04-271-0/+1
| | | | | | | | | | | | | | | | | | This way the platform window is destroyed in a timely manner, preventing redundant close events from the window system. Task-number: QTBUG-43344 Change-Id: Ifdfca59ceacef54405f1c227c493dc514a1b27ea Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-17 22:45:07 +0000