summaryrefslogtreecommitdiffstats
path: root/src/gui/kernel/qwindowsysteminterface.h
Commit message (Collapse)AuthorAgeFilesLines
* Rename QWSI::handleWindowActivated to QWSI::handleFocusWindowChangedTor Arne Vestbø2023-11-231-1/+2
| | | | | | | | | | | | | | | | | | | A single QWindow is QGuiApplication::focusWindow() at a time, and this window is typically also QWindow::isActive(), but other windows may also be QWindow::isActive(). For example, we treat any sibling or ancestor of the focusWindow as being QWindow::isActive() as well. In addition, in the case of non-QWindow child windows, we may have to query the platform for the activation state, which means we also need a way for the platform to reflect changes in this state through QWSI. The current API for this, QWSI::handleWindowActivated, is in practice a focus window change API, so as a first step let's rename it to better reflect what it's doing. Task-number: QTBUG-119287 Change-Id: I381baf8505dd13a4a829c961095a8d2ed120092b Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* xcb: Use QWSI::handleTabletEnterLeaveProximityEvent(.. QPointingDev* ..)Shawn Rutledge2023-06-201-0/+2
| | | | | | | | | | | | | | | | | | | We want to pass the QPointingDevice* because we've already identified it by its "system ID" (xinput device number). The other versions of handleTabletEnterProximityEvent and handleTabletLeaveProximityEvent try to identify the stylus by only its deviceType, pointerType and unique ID, which can go wrong if there are multiple tablet devices and the unique ID is not provided (as with N-trig and Wacom tablets being used at the same time). Anyway this fixes a TODO comment from 6589f2ed0cf78c9b8a5bdffcdc458dc40a974c60 Leave a "deprecated" comment by the QWSI functions that should not be used. Pick-to: 6.6 6.5 Task-number: QTBUG-104878 Change-Id: Id9f19c60b54b7900b02d5f87b5d12f9a9189721d Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QWSI: Remove handleFrameStrutMouseEvent in favor of handleMouseEvent+typeTor Arne Vestbø2023-03-311-25/+0
| | | | | | | | | | | | | | | The handleMouseEvent function already takes a QEvent::Type, where clients pass in the corresponding mouse press/release/move type. The same applies to the handleFrameStrutMouseEvent. To avoid the chance that clients call these functions with a conflicting event type (handleFrameStrutMouseEvent with MouseButtonPress instead of NonClientAreaMouseButtonPress e.g.), we remove handleFrameStrutMouseEvent altogether and just let clients use the handleMouseEvent function directly with the correct event type. Change-Id: I4a0241c39aedac0d2d8d5163ba05cde72605959c Reviewed-by: Lars Knoll <lars@knoll.priv.no>
* Introduce events for Window device pixel ratio changesDavid Edmundson2023-02-131-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | There is a mix between screen device pixel ratio. Currently we store the property on a per-window basis, but the change notifications are still on a per screen basis which can fall apart on edge cases. On wayland we are getting per window DPR changes without as useful screen change events so it's important to fix. It also has potential to clean up the Windows backend in the future where the backend is currently papering over the two concepts. This patch introduces two new events: A QWindowSystemInterface to trigger a window DPR change independently of a screen change. An event to notify windows the new DPR rather than needing to track signals on the screen. This happens either when the window dpr changes or implicitly through a screen change. This can deprecate an existing event ScreenChangeInternal so the value is reused and renamed for clarity. Change-Id: I637a07fd4520ba3184ccc2c987c29d8d23a65ad3 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QWSI: Remove dead code for macOS-specific shortcut-override handlingTor Arne Vestbø2022-09-151-3/+3
| | | | | | | | | | | | | | | | | | | | | | The macOS platform plugin exclusively uses handleExtendedKeyEvent() these days, never the simpler handleKeyEvent(), and always passes false for the tryShortcutOverride argument, so the special-cased code was never executed. No other platform passes the optional tryShortcutOverride argument, so it can be removed completely. If we ever need to bring back this kind of logic it should live in the macOS platform plugin, not in the QWSI layer. We have to keep the existing logic for qt_handleKeyEvent() though, as that's exercised through QTest::simulateEvent(). The next step would be to remove the QWindowSystemInterface::handleShortcutEvent() call in QGuiApplicationPrivate::processKeyEvent() and teach existing platform plugins, as well as the QTest machinery, to handle shortcuts explicitly before sending raw key events. Change-Id: I6eb3fd18c64d1619e33e79f076e25efd299a9ba7 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* Use SPDX license identifiersLucie Gérard2022-05-161-38/+2
| | | | | | | | | | | | | Replace the current license disclaimer in files by a SPDX-License-Identifier. Files that have to be modified by hand are modified. License files are organized under LICENSES directory. Task-number: QTBUG-67283 Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Send ThemeChange event to all windows when system theme changesTor Arne Vestbø2022-04-221-1/+1
| | | | | | | | | | | | | | | | | | | The QWSI event for theme change has an optional window parameter to specify the window affected, but most platform react to global theme changes, and end up passing nullptr into the event. The reasonable thing to do in QGuiApplication in that case is send a theme change event to every QWindow, so that they are all notified about the situation. This approach is what the Windows platform plugin was doing already, but did so by iterating manually over the windows, resulting in multiple calls to QGuiApplicationPrivate::handleThemeChanged -- one for each QWSI event. Change-Id: Ifb27b6c31231377c0df389a592cafd0075d3d8bb Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Rename QNativeGestureEvent::deltas() to delta(); clarify docsShawn Rutledge2021-07-141-2/+2
| | | | | | | | | | | | | | | | | In QPanGesture this is called delta(). OTOH we have QWheelEvent::pixelDeltas(). Delta is a vector, and there's only one (with two components). Native gestures hold incremental values: e.g. the pinch gesture event provides an incremental amount of either zooming or rotation (so most events have QNativeGestureEvent::value() very close to 0). It's the same with the pan gesture's delta(). Add better docs for swipe and pan gestures. Change-Id: Ia147c7c9a22e084c3700b1620dec46427d792bd1 Reviewed-by: Povilas Kanapickas <povilas@radix.lt> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Change QNativeGestureEvent::deltas() to QPointFShawn Rutledge2021-07-141-1/+1
| | | | | | | | | | | | | It came up during 6.2 API review that we prefer all floating-point API to be double-precision on 64-bit platforms, despite the awkwardness of representing a displacement vector with something called a "point". The docs for QPointF explicitly state "A QPointF object can also be used as a vector: Addition and subtraction are defined..." Amends 31f90e99b8f04d9a228c5a0b01319b3f112c1490 Change-Id: I01029661f2586640cbf846f49df164c176d17f7a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Remove Qt6 switches from QtGuiAllan Sandfeld Jensen2021-05-051-4/+0
| | | | | | | Removing now dead code Change-Id: I021539da6517fdb8443f8ae9431fc172b7910cfc Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Add storage for (pixel) deltas and fingerCount to QNativeGestureEventShawn Rutledge2021-04-271-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | It's not clear now whether trackpad gestures on Windows will need to be so different than on macOS; however, any reasonable int value can be stored in a qreal, and in Qt Quick we like to use floating-point numbers for all "real" values and measurements. So since we need to add more storage, and quint64 m_intValue has never been used, we now replace it with a QVector2D, which should have the same size. The intended use is that PanNativeGesture will include a displacement, probably in pixels, by which the viewport or some target item should be panned or moved. The naming of deltas() is flexible enough to support any gesture with some incremental 2D valuators, though, just as value() has gesture-dependent semantics. fingerCount() will be useful for Qt Quick pointer handlers to filter out events that have the wrong number of fingers, e.g. to require that either a 3-finger pan gesture or 3 individual touchpoints are required to activate DragHandler { minimumPointCount: 3 } (assuming we implement pan gesture support in DragHandler). Fixes: QTBUG-92179 Task-number: QTBUG-92098 Change-Id: I5462aea9047beed6e99075294a62011edd8a59f5 Reviewed-by: Povilas Kanapickas <povilas@radix.lt> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Remove QWindowSystemInterface::handleGestureEventWithSequenceIdAndValue()Shawn Rutledge2021-03-231-2/+0
| | | | | | | | | This was added in fbfc8ffbf39e2e7a540d4d576ec61bea7db63416 but left unused in Qt 5; and we don't anticipate needing it now either. Change-Id: I3d1f1301c8896df04255ebef5bacb5c5027dc7ae Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Povilas Kanapickas <povilas@radix.lt>
* Windows QPA: Pass device for synthesized touch/tablet eventsFriedemann Kleint2020-11-271-0/+13
| | | | | | | | | | | Add the overloads for mouse events with device/without timestamp and pass the active tablet or touch device. Task-number: QTBUG-88678 Task-number: QTBUG-46412 Pick-to: 6.0 Change-Id: I8695b493540d0cbf50e9c72afe870a7633de3ab9 Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* QWindowSystemInterface: Add tablet event overloads without timestampsFriedemann Kleint2020-10-171-0/+9
| | | | | | | | On some platforms, tablet events do not have a time stamp. Task-number: QTBUG-46412 Change-Id: I3cc820b1edaaf55511c000fefb805f5a3a7872a6 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Track grab state in QPointingDevicePrivate::activePointsShawn Rutledge2020-09-161-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+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>
* qwsi: revert parts of 00ae1e6b7bf6efa5f5e57d37844e44d521604fb6Gatis Paeglis2020-08-231-1/+0
| | | | | | | | | | | | | | We actually do not need this "mode" in qwsi API. I think while writing the patch from 00ae1e6b7b I got confused by focusing on my test application. We can't know what the native event filter will filter out, therefore it makes sense that we unconditionally do filtering at qwsi level as well for user input vs other events in QWindowSystemInterface::sendWindowSystemEvents(). Pick-to: 5.15 Pick-to: 5.12 Change-Id: Idb23152a24bf3ba3b91804427a6e78f991969c29 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Refactor pointer event hierarchyShawn Rutledge2020-07-101-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Use QList instead of QVector in guiJarek Kobus2020-06-291-1/+1
| | | | | | | | Applied to headers only. Source file to be changed separately. Task-number: QTBUG-84469 Change-Id: Ic08a899321eaffc46b8461aaee3dbaa4d2c727a9 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Add QPointingDevice argument to every QWSI input event handler functionShawn Rutledge2020-06-181-10/+43
| | | | | | | | | | | | | | | | | | | | | | We want every QInputEvent to carry a valid device pointer. It may be some time until all QPA plugins are sending it, but it's necessary to provide the functions for them to start doing that. We now try to maintain the same order of arguments to all the functions. handleTouchEvent(window, timestamp, device, the rest) was already there (except "device" has changed type now), and is used in a lot of platform plugins; so it seems easiest to let that set the precedent, and modify the rest to match. We do that by adding new functions; we can deprecate the older functions after it becomes clear that the new ones work well. However the handleGestureEvent functions have only ever been used in the cocoa plugin, so it's easy to change their argument order right now. Modify tst_qwindow::tabletEvents() to test new tablet event API. Task-number: QTBUG-46412 Change-Id: I1828b61183cf51f3a08774936156c6a91cfc9a12 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Introduce QInputDevice hierarchy; replace QTouchDeviceShawn Rutledge2020-06-161-11/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Remove obsolete storage, constructors and accessors in QEvent subclassesShawn Rutledge2020-05-121-39/+1
| | | | | Change-Id: I5c51244031ff40f1972106ad4fe27010c8be1193 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* qpa: Return accepted state from mouse, touch and wheel handlersLorn Potter2020-03-131-23/+23
| | | | | | | | Return the value from handleWindowSystemEvent so platform plugins can detect whether it was accepted or not. Change-Id: I53ffb713afc8e0ec1789107c912433133cfaa11a Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: Deliver theme changes synchronouslyTor Arne Vestbø2019-12-191-0/+1
| | | | | | | | | Otherwise the expose event that AppKit triggers will be delivered before we've propagated the theme change, and we fail to draw the UI using the new theme. Change-Id: I502122a2bf02a866d136106d831f0c2a0dfe26f2 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* Propagate application termination requests through QPATor Arne Vestbø2019-10-191-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Modernize QWindowSystemInterface::handleCloseEventTor Arne Vestbø2019-10-041-1/+1
| | | | | | | The base WindowSystemEvent has had an eventAccepted flag since 2014. Change-Id: Ia0aa795083cd98ece83a4c1cc010d3a25e2489fd Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* Merge remote-tracking branch 'origin/5.13' into devFriedemann Kleint2019-03-261-0/+4
|\ | | | | | | Change-Id: I38389a69411f4549fed432f1181dbe23398b34a2
| * Move screen maintenance functions from QPlatformIntegration to QWSITor Arne Vestbø2019-03-191-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QWindowSystemInterface is the de facto API for any plumbing going from the platform plugin to QtGui. Having the functions as protected members of QPlatformIntegration was idiosyncratic, and resulted in awkward workarounds to be able to call the functions from outside of the QPlatformIntegration subclass. The functions in QPlatformIntegration have been left in, but deprecated so that platform plugins outside of qtbase have a chance to move over to the new QWSI API before they are removed. Change-Id: I327fec460db6b0faaf0ae2a151c20aa30dbe7182 Reviewed-by: Gatis Paeglis <gatis.paeglis@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>
* xcb: respect QEventLoop::ExcludeUserInputEvents in native event handlersGatis Paeglis2018-10-161-0/+1
| | | | | | | | | | | | | | | | | This was a regression from Qt 4. Before this patch, we supported filtering events only at QWindowSystemInterface level, but to properly support filtering in QAbstractEventDispatcher::filterNativeEvent, we have to filter the events earlier. Now it is possible to enable/disable this feature for platforms that support native event filtering. The mapping of which events are user input events were taken from QWindowSystemInterfacePrivate::EventType. Task-number: QTBUG-69687 Change-Id: I9a5fb9f999451c47abcdc83fdcc129b5eeb55447 Reviewed-by: Paul Wicking <paul.wicking@qt.io> Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* Merge remote-tracking branch 'origin/5.11' into devLiang Qi2018-06-071-2/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+1
| | | | | | | | | | | | | | | | | | 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 devLiang Qi2018-05-081-0/+1
|\| | | | | | | | | | | | | | | Conflicts: src/plugins/sqldrivers/sqlite/qsql_sqlite.cpp tests/auto/corelib/io/qresourceengine/qresourceengine_test.pro Change-Id: I3169f709cc2a1b75007cb23c02c4c79b74feeb04
| * QtGui: Enable synchronous delivery for QWSysIf:::WindowScreenChangedEventFriedemann Kleint2018-05-081-0/+1
| | | | | | | | | | | | | | Task-number: QTBUG-67777 Change-Id: I6d52b650fb33283010ef06259da83cdb2fd3483f Reviewed-by: Oliver Wolff <oliver.wolff@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* | qpa: improve API to support DnDs from other processesGatis Paeglis2018-05-041-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... instead of using a hack of directly accessing QGuiApplication members. The current QPA API was bad for two reasons: 1) It expects platform plugin authors to know about internals of Qt Gui, particularly that QGuiApplication uses QGuiApplication::{mouseButtons,keyboardModifiers} to construct QDragMoveEvent and QDropEvent events. Which results in the second reason why this is bad. 2) Platform plugins should not directly access member variables of QGuiApplication, just to make sure that QDragMoveEvent and QDropEvent events contain correct state. Platform plugins should instead use QWindowSystemInterface to communicate with Qt Gui (which is also the solution here). The solution is to extend QWindowSystemInterface::handle{Drag,Drop} to require mouse/keyboard state. We already do this for some of the other methods, so it is nothing extraordinary. This type of interface is also _required_ to support drag-n-drops from other processes. We can't use QGuiApplication::{mouseButtons,keyboardModifiers} when the drag originates from another process, instead we need to query mouse/keyboard state from the system. This patch fixes drag-n-drops from others processes on XCB platform plugin. Task-number: QTBUG-57168 Change-Id: I3f8b0d2f76e9a32ae157622fef801829d629921d Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* | Support synchronous handleCloseEvent()Morten Johan Sørvig2018-02-211-0/+1
|/ | | | | | | | Use QT_DEFINE_QPA_EVENT_HANDLER to define QWindowSystemInterface::handleCloseEvent(). Change-Id: I4f1105f7aa78bdebddfe9062b388eb616e325e31 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Merge remote-tracking branch 'origin/5.10' into devLars Knoll2018-01-021-0/+3
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: .qmake.conf sc/corelib/io/qfsfileengine_p.h src/corelib/io/qstorageinfo_unix.cpp src/platformsupport/eglconvenience/qeglpbuffer_p.h src/platformsupport/input/libinput/qlibinputkeyboard.cpp src/platformsupport/input/libinput/qlibinputpointer.cpp src/plugins/platforms/cocoa/qcocoamenu.mm src/plugins/platforms/ios/qiosscreen.h src/plugins/platforms/ios/qioswindow.h src/plugins/platforms/ios/quiview.mm src/printsupport/dialogs/qpagesetupdialog_unix_p.h src/printsupport/dialogs/qprintpreviewdialog.cpp src/printsupport/widgets/qcupsjobwidget_p.h src/widgets/widgets/qmenu.cpp tests/auto/corelib/tools/qdatetime/tst_qdatetime.cpp tests/auto/widgets/itemviews/qtreeview/tst_qtreeview.cpp Change-Id: Iecb4883122efe97ef0ed850271e6c51bab568e9c
| * Merge remote-tracking branch 'origin/5.9' into 5.10Lars Knoll2017-12-301-0/+3
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: .qmake.conf mkspecs/win32-g++/qmake.conf src/corelib/global/qglobal_p.h src/corelib/global/qoperatingsystemversion_p.h src/corelib/io/qfilesystemengine_win.cpp src/network/bearer/qbearerengine.cpp src/platformsupport/input/libinput/qlibinputpointer.cpp src/sql/doc/snippets/code/doc_src_sql-driver.cpp src/widgets/kernel/qwidget_p.h src/widgets/kernel/qwidgetwindow.cpp src/widgets/styles/qfusionstyle.cpp tests/auto/corelib/io/qfileinfo/tst_qfileinfo.cpp Change-Id: I80e2722f481b12fff5d967c28f89208c0e9a1dd8
| | * Teach QPlatformWindow about safe area margins and implement for iOSTor Arne Vestbø2017-12-131-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The safe area margins of a window represent the area that is safe to place content within, without intersecting areas of the screen where system UI is placed, or where a screen bezel may cover the content. QWidget will incorporate the safe area margins into its contents margins, so that they are are never smaller than the safe area margins. This can be disabled by unsetting the Qt::WA_ContentsMarginsRespectsSafeArea widget attribute, which is set by default. QLayouts will automatically use the contents area of a widget for their layout, unless the Qt::WA_LayoutOnEntireRect attribute has been set. This can be used, along with a contents margin of 0 on the actual layout, to allow e.g. a background image to underlay the status bar and other system areas on an iOS device, while still allowing child widgets of that background to be inset based on the safe area. [ChangeLog][iOS/tvOS] Qt will now take the safe area margins of the device into account when computing layouts for QtWidgets. Change-Id: Ife3827ab663f0625c1451e75b14fb8eeffb00754 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* | | Merge remote-tracking branch 'origin/5.10' into devLiang Qi2017-11-301-0/+1
|\| | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/corelib/thread/qsemaphore.cpp tests/auto/network/access/qnetworkreply/tst_qnetworkreply.cpp tests/auto/widgets/itemviews/qtreeview/tst_qtreeview.cpp Change-Id: Id35b535e88df63fdfe4007ea92ed4a39c4b6d707
| * | Merge remote-tracking branch 'origin/5.9' into 5.10Liang Qi2017-11-231-0/+1
| |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/corelib/io/qstandardpaths_win.cpp src/plugins/platforms/ios/qioswindow.mm src/plugins/platforms/ios/quiview.mm tests/auto/widgets/itemviews/qtreeview/tst_qtreeview.cpp Change-Id: I5deb0a0176a454a9c566e924d074ba60ce04f0bc
| | * qpa: Teach handleApplicationStateChanged about sync/async deliveryTor Arne Vestbø2017-11-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using QWindowSystemInterface::SynchronousDelivery reduces the chance that we are flushing other events before delivering the application state change. Those other events may conclude that the application is still active, while in reality it is not, and do bad things. Change-Id: I738c162fac22d2cd18de1e080bcd2cda78ec3f77 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* | | qpa: enhance mouse event with type and button dataGatis Paeglis2017-10-101-4/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... and deprecate QWSI APIs that accepts mouse event without mouse button/ type data. In the early days of Qt5 it was decided to centralize mouse button/type handling in QGuiApplication (because of limitation of some now unknown platform). This has proven to be problematic as mouse handling details differ across platforms (e.g on X11 we do not receive mouse release event when closing popup windows or ordinary windows that are closed from the mouse press event). Instead of hacking around platform specific behaviors in Qt Gui, we should move this task back to platform plugins (similar to how this was done in Qt4 with native APIs sending mouse details directly to QApplication). There are even cases where it simply is not possible to deduce (from QGuiApplication) which button caused the event (e.g. when more than one button is involved and some event goes missing). Besisdes, throwing away information which is already available at QPA level (for free) and trying to deduce it again at Qt Gui level seems impractical, fagile (as probably noticed by people fixing all the unexpected issues) and adds unnecessary complexity. Note: Removing the deprecated QWSI APIs from offscreen plugin depends on fixing autotests that rely on QOffscreenCursor::setPos() logic. For the convenience of testing use QT_QPA_DISABLE_ENHANCED_MOUSE to restore to the old code path where QGuiApplication does the mouse state deducing. Other platforms have similar issues. I do not have all supported platform available on my desk, so other platform maintainers will need to take care of porting those platforms to the new APIs. And mainly, I don't want to deal with all the hacks that other platforms have added to workaround this broken mouse logic. In Qt6 we need to remove deprecated code path from QGuiApplication. This patch: - Extends QWindowSystemInterfacePrivate::MouseEvent ctor with QEvent::Type and Qt::MouseButton. We use this extra data when processing mouse events in QGuiApplication. This actually is similar to KeyEvent, where we do pass the type (press or release) to QtGui. - Refactors QGuiApplicationPrivate::processMouseEvent and qtestlib to use the new APIs. Task-number: QTBUG-59277 Task-number: QTBUG-62329 Task-number: QTBUG-63467 Change-Id: If94fd46a7cccfea8264dcb1368804c73334558b8 Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
* | | Merge remote-tracking branch 'origin/5.10' into devLiang Qi2017-09-261-3/+3
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/gui/kernel/qguiapplication.cpp src/platformsupport/input/libinput/qlibinputpointer.cpp src/plugins/platforminputcontexts/ibus/qibusplatforminputcontext.h src/plugins/platforms/cocoa/qcocoawindow.h src/testlib/qtestsystem.h Change-Id: I5975ffb3261c2dd82fe02ec4e57df7c0950226c5
| * | make the QTouchDevice available in each QNativeGestureEventShawn Rutledge2017-09-211-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QtQuick is beginning to have a use for this, to distinguish native gestures which come from actual trackpad rather than from the "core pointer". It might as well use a real device ID instead of making one up, as it has to do for the core pointer. So far on macOS, the device ID isn't a real one; but that can be fixed, as the qCDebug lines demonstrate (different trackpads have different IDs). Change-Id: I5841deb1c4cc0b77a3b1df70904f70b3d2d71853 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | | Replace Q_NULLPTR with nullptr where possibleKevin Funk2017-09-191-1/+1
|/ / | | | | | | | | | | | | | | | | | | | | | | | | Remaining uses of Q_NULLPTR are in: src/corelib/global/qcompilerdetection.h (definition and documentation of Q_NULLPTR) tests/manual/qcursor/qcursorhighdpi/main.cpp (a test executable compilable both under Qt4 and Qt5) Change-Id: If6b074d91486e9b784138f4514f5c6d072acda9a Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
* | Ensure all platforms send geometry events if request was not fulfilledTor Arne Vestbø2017-07-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The logic of deciding whether or not to send resize and move events has been centralized in QGuiApplication. This ensures that if a window with geometry 100,100+200x200 is moved and resized to e.g. 0,0+100x100, but the window manager denies the request (because the window would e.g. overlap with system UI), and issues a geometry update with the original geometry, 100,100+200x200, we will still treat that as warrant of a move/resize event to the application, so the application knows that its position and size is as before. [ChangeLog][Qt Gui][QPA] QWindowSystemInterfacePrivate::handleGeometryChange no longer takes the old geometry as an argument. Task-number: QTBUG-57608 Change-Id: I1d471cc7a257fef958bdb1e56184fa95489403a3 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* | Merge remote-tracking branch 'origin/5.9' into devLiang Qi2017-07-041-1/+1
|\| | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/corelib/io/qprocess_unix.cpp src/plugins/platforms/xcb/qxcbconnection.cpp src/plugins/platforms/xcb/qxcbwindow.cpp src/widgets/util/util.pri tests/auto/corelib/thread/qthread/qthread.pro tests/auto/corelib/thread/qthread/tst_qthread.cpp Change-Id: I5c45ab54d46d3c75a5c6c116777ebf5bc47a871b
| * Convert features.whatsthis to QT_[REQUIRE_]CONFIGStephan Binner2017-06-291-1/+1
| | | | | | | | | | | | | | Move feature definition to gui/configure.json Change-Id: I00b35c0e259d0a695d84a9bf6803eba74d41465a Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
* | qpa: start using QT_DEPRECATED_SINCE to increase visibilityGatis Paeglis2017-06-021-11/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | ... when platform plugins are using compatibility APIs. Even though QPA is not a public API and does not promise source/binary compatibility, we still try to not break things when possible. Eventually deprectated APIs will be dropped (e.g between major Qt versions). Having deprecation warnings here would help maintainers to notice API changes even before their code stops compiling due to removed QPA APIs. This will also ensure that we won't forget to remove compatibility APIs. Change-Id: If13786eb7d42a595708ace00b2ddea5209df18db Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-14 16:11:53 +0000