summaryrefslogtreecommitdiffstats
path: root/src/plugins/platforms/cocoa/qnsview_mouse.mm
Commit message (Collapse)AuthorAgeFilesLines
* macOS: Propagate mouse enter/exit for windows embedded into foreign windowsTor Arne Vestbø2023-06-261-4/+26
| | | | | | | | | | | | | | | Similar to the isEmbedded() case, when the parent of a QWindow is a foreign window, created via QWindow::fromWinId(), we don't have a QNSView parent that will handle mouse enter/exit on our behalf. Longer term we probably want to fold this case into the isEmbedded() case, but as that function is used other places too this requires some more research, so for now let's fix hover events. Fixes: QTBUG-114605 Pick-to: 6.5 6.6 Change-Id: Ib61aefc84ed080417a6820a4a365555424b208be Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Remove outdated comment about macOS cusorUpdateTor Arne Vestbø2023-04-121-4/+0
| | | | | | Pick-to: 6.5 Change-Id: Ic270e9800b56e4fa1027245bebc4cd08a58abb3f Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* macOS: Send Qt::NonClientAreaMouseMove for NSEventTypeMouseMoved in title barTor Arne Vestbø2023-03-311-3/+2
| | | | | | | | | | We were missing the NSEventTypeMouseMoved in resolving the event type for handleFrameStrutMouseEvent, resulting in passing on QEvent::None as the event type to QWSI. Pick-to: 6.5 6.2 Change-Id: I144b6459c5d4fda2839d25cd52ddb441dc7c3a47 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QWSI: Remove handleFrameStrutMouseEvent in favor of handleMouseEvent+typeTor Arne Vestbø2023-03-311-1/+1
| | | | | | | | | | | | | | | 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>
* 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>
* macOS: Forward hover-events for embedded windowsStefan Wastl2022-05-061-4/+4
| | | | | | | | | | | | If a QWindow is embedded into a native view it's effectively the root window, similar to a top level QWindow, and we need to forward hover events on behalf of itself and all child windows. Fixes: QTBUG-103084 Pick-to: 6.3 Change-Id: I1e94b9447fb561c1b02db87738de235c5d12b3a4 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: <stefan.wastl@native-instruments.de>
* Plugins: use _L1 for for creating Latin-1 string literalsSona Kurazyan2022-05-041-2/+4
| | | | | | | | | As a drive-by, fix qsizetype -> int narrowing conversion warnings for the touched lines. Task-number: QTBUG-98434 Change-Id: I7fadd3cf27ad099028d70f05956303e3af62c0f5 Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* macOS: Handle momentum scroll NSEventPhaseBegan when scroll had endedTor Arne Vestbø2022-01-071-1/+5
| | | | | | | | | | | | | | | | We use nextEventMatchingMask to look for future momentum scroll events when the non-momentum scroll ends, to continue the scroll uninterrupted from the perspective of client code. But we're not guaranteed to find a future momentum scroll event, as observed on macOS 12.1, so if we then see a momentum NSEventPhaseBegan we need to treat it as a scroll begin from Qt's perspective. Fixes: QTBUG-97841 Pick-to: 6.3 6.2 5.15 Change-Id: I412abe0891660eda32a42a08d7dc7dee9eaa73aa Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* macOS: Sanitize scroll deltas for NSEventPhaseCancelledTor Arne Vestbø2021-12-231-0/+10
| | | | | | | | | | | | | | | | On macOS 12.1 the NSEventPhaseCancelled phase can in some situations report deltas, which causes the scroll to "jump". This happens for example when initiating a momentum-scroll, and then putting two fingers on the trackpad to cancel the momentum phase, which starts a new NSEventPhaseMayBegin phase. When then lifting the two fingers again, we get an NSEventPhaseCancelled event with deltas, but the deltas seem like uninitialized data (has a x-value, after doing a purely vertical scroll e.g.). Task-number: QTBUG-97841 Pick-to: 6.3 6.2 5.15 Change-Id: I14e765b6111e53e7d3d0da219d4ac7fefe5243d0 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* qnsview_mouse, scrollWheel: do not assume zero deltas on Ending phaseTimur Pocheptsov2021-11-031-4/+4
| | | | | | | | | | | | | | | | | | It's somewhat difficult to reproduce, but having a mac with a trackpad and a huge scrollview (meaning I have to scroll fast and a lot), I am able from time to time to trigger an assert on the line: Q_ASSERT(pixelDelta.isNull() && angleDelta.isNull()) In all such cases, I can see that deltas are not zero, but equal to the ones that the next event (momentumPhase == Begin) has. The code is based on Tor Arne's patch. Pick-to: 6.2 5.15 Fixes: QTBUG-97945 Change-Id: I874c776b265d3950cc2b6c1d8054363b3d0d1fde Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: Don't require marked text before passing mouse down to input contextTor Arne Vestbø2021-10-161-6/+9
| | | | | | | | | | | | | | | | | There are situations where the input context might want the event, even if there's no marked text, for example when long-pressing A with a US keyboard layout and getting the accent popup. In that case we want a press somewhere else in the input item to move the cursor, and commit the current preedit. This is the same approach as NSTextView has, always calling handleEvent, and in line with the recommendation from Apple: https://lists.apple.com/archives/cocoa-dev/2012/May/msg00539.html Pick-to: 6.2 Change-Id: Iff0861a4e604ab594d1ad4ccbb9367d8e0ffe4ef Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* macOS: Pass on mouse press if input context didn't handle itTor Arne Vestbø2021-10-161-11/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We follow the approach of [NSTextView mouseDown:] by bailing out if the input context handled the event, and otherwise passing it along to the input item. This allows moving the cursor with a single click in the input item, which will also commit the current preedit string as is, depending on the input context. For some reason 2-Set Korean input results in plain insertText calls for each step of the composition with an NSTextView, while we get marked text. The result is that when composing with 2-Set Korean, a native NSTextView will only require a single click to move the cursor, while for us it requires two, since the input context says it handled the event. We opt to follow the behavior of NSTextView to bail out if the input context handled the event, instead of trying to emulate the observed behavior for 2-Set Korean by always passing the mouse event on, as the former seems like a safer approach. This is also in line with the recommendations from Apple: https://lists.apple.com/archives/cocoa-dev/2012/May/msg00539.html Pick-to: 6.2 Change-Id: I372ac62ee3b8b20531cd7cfa2d412a5efea3eb68 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* macOS: Only send mouse press to input context if clicking input itemTor Arne Vestbø2021-10-161-2/+13
| | | | | | | | | | | | | | | Our QNSView can represent many controls, not just the current input item, so we need to ensure the click happens inside the input item before we ask the input context to handle the event. This allows clicking controls such as buttons and check boxes while composing complex text, without cancelling or otherwise affecting the composition. Fixes: QTBUG-57347 Pick-to: 6.2 Change-Id: I8449c8d74fd21b1ee1d5bd75f960751b64d7e078 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* cocoa: Fix typo in debug messagesJonas Kvinge2021-10-121-1/+1
| | | | | | Pick-to: 5.15 6.2 Change-Id: I0a4c344f2104241175a9bfce7cfc7128c3f7d3ed Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: Change NSTrackingArea to use NSTrackingActiveAlwaysRichard Moe Gustavsen2021-09-231-28/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current implementation configured NSTrackingArea to be active while the application was active (NSTrackingActiveInActiveApp). But because of a bug in AppKit, the tracking area would sometimes stop being updated, with the result that no mouse events was being sent from AppKit. One way to trigger this bug would be to deactivate the app using cmd+tab (fast enough so that the task switcher is not showing), and reactivate it again using a mouse click. To work around this issue, this patch will instead configure the tracking area to always listen for tracking events, even when the application is inactive (NSTrackingActiveAlways). By doing so, we bypass the apparently broken behavior in AppKit related to activation. The downside is that we then also get tracking events while the application is inactive, which is against how Qt should work. So we therefore need to now check if the application is active before we forward any tracking events to QWSI. With NSTrackingActiveAlways we no longer get enter/leave events from AppKit when the application is activated/deactivated and the mouse stays on top of the application, so we now also need to handle this explicitly from the application delegate. Since we already need to keep track of which QWindow is under the mouse to be able to send out enter/leave from mouse moves, we use the same variable (s_windowUnderMouse) for this purpose as well. Because of QTBUG-35109, there was already a code path in QCocoaWindow that sent out an enter event when a window became key. This is no longer needed now that we send out enter/leave when the application is activated/deactivated. It's also questionable if sending an enter event based on a window's key status is correct, since we in Qt should also send out enter events for inactive windows. So we remove this code path since it interferes with (both the old and) the new implementation. Fixes: QTBUG-36926 Task-number: QTBUG-94447 Change-Id: I5c1105bc3102925c9c65964b4a7d1e02efd01735 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: convert mask region to native geometryMorten Johan Sørvig2021-09-151-2/+2
| | | | | | | | | | | QWindow::mask() returns a region in device independent geometry which can’t be used directly by the platform plugin. Pick-to: 6.2 5.15 Task-number: QTBUG-94770 Change-Id: I76279bc74cfabe315178327938f485f4447568be Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: remove the popup stack from QCocoaIntegrationVolker Hilsheimer2021-09-151-32/+0
| | | | | | | | | Since popup handling is now done exclusively by Q(Gui)Application, we don't need to keep track of the popup stack in the Cocoa plugin anymore. Fixes: QTBUG-96450 Change-Id: I869f36f52bc2210b6c92efd9425502de4122c553 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: remove mouse and key grabbing logic from Cocoa pluginVolker Hilsheimer2021-09-151-9/+0
| | | | | | | | | | For QGuiApplication with QWindow, no other QPA plugins do so, and for QApplication with QWidgets, QApplication implements popup functionality consistently. Task-number: QTBUG-96450 Change-Id: I47489296e0e470d8948ca7858d0a2608c58b2975 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: Move handleMouseEvent: to MouseAPI categoryTor Arne Vestbø2021-09-141-53/+53
| | | | | | | Fixes warning of method definition not found. Change-Id: I87866785d1564e29fc356c033ae8cf972548ea7f Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* macOS: Don't close popups in Cocoa plugin for most mouse eventsVolker Hilsheimer2021-09-131-10/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | QWidget and QApplication handle popup closing for most events at the right time for the Qt-internal state logic. On other platforms popup QWindows are never closed automatically when clicking outside. So don't close any popups in the Cocoa plugin either, and let the Qt logic take care of it. This ensures that window activation is done at the right time, that Qt's modal popup stack is consistent, and that mouse replay for events closing a popup works. There are however two exceptions: mouse events in the window frame don't produce a QMouseEvent for Qt; and mouse events in a modally blocked (by Cocoa) window don't reach Qt at all. For those case, the logic in QWidget and QApplication is not enough. For the former, leave the change introduced in 70b94eea10d7af83cced092967 to explicitly close popups for LMB down in the frame. This still needs to happen before the event is delivered. For the latter case, deliver the event explicitly to Qt when we discover that the target window is modally blocked while a popup is active. The handleMouseEvent implementation then takes care of the redirect to the active popup, and Qt will further respect the modal stack in the QApplication::isWindowBlocked implementation. Change-Id: I578eb5e6aebc897a0ff1f69bc5c53bcaa05d138d Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: Move pointingDeviceFor helper to top of fileVolker Hilsheimer2021-09-081-30/+30
| | | | | | | | | It's confusing to have it in the middle of the code implementing the various interfaces. Make review of follow up patches easier by moving it out of the way. Change-Id: I10f6e8f7642ec0cb14ae31b14a023c6a9ef455d9 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* cocoa: use TouchPad deviceType for trackpadShawn Rutledge2021-09-031-0/+1
| | | | | | | | | | | WheelHandler { acceptedDevices: PointerDevice.TouchPad } doesn't react unless we use the right type. Amends 69c833dae91d004b48f815e0156d6caeb4cdb491 Pick-to: 6.2 Change-Id: I813de096b87f3af4dfcf5510abc0d0bd9c15b689 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: close popups on mousedown within the window frameVolker Hilsheimer2021-08-191-27/+34
| | | | | | | | | | | | | | | | On macOS, we close active popups when handling mouse-down events in the NSView, but not for such events in the window frame. This allows users to close a window that has a context menu open via the window's close button, which then leaves open popups behind. Factor the popup-closing code out into a dedicated method that we can call from within the NSWindow::sendEvent implementation for mouse down events. Fixes: QTBUG-30522 Pick-to: 6.2 6.1 5.15 Change-Id: I9c354efc449cfefff3ed84fa34b1cd8a0da3b4a7 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Register mouse devices on cocoaShawn Rutledge2021-08-011-2/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | It would have been nice to ensure that a device is registered already in mouseEnteredImpl(); but in that context, NSEvent.deviceID is always 0, and we can't find out anything else about the device. QWindowSystemInterface::handleEnterEvent() doesn't currently take a QPointingDevice either. In handleMouseEvent() and scrollWheel(), deviceID seems unique for each trackpad or Magic Mouse, but 0 for any plain USB mouse. There, the first mouse that the user interacts with becomes primaryPointingDevice(): its deviceID is assigned to systemID (except if deviceID == 0, we use 1 instead, to avoid the auto-incrementing device ID assignment in the QInputDevicePrivate ctor.) When scrolling occurs, we update the capabilities to have PixelScroll if theEvent.hasPreciseScrollingDeltas. So over time, QInputDevice::devices() should build up to a complete list, with capabilities() also distinguishing plain mice from those that have the PixelScroll capability. And in the common case that the user has only one Apple pointing device, it becomes primaryPointingDevice(). Pick-to: 6.2 Task-number: QTBUG-46412 Task-number: QTBUG-63363 Task-number: QTBUG-72167 Change-Id: Id9771b4dfd765e49023bd57d42a2aa4d0635a3b2 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* cocoa: be more careful about rejecting frame strut eventsRichard Moe Gustavsen2021-05-121-7/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The m_buttons property is meant to hold the currently pressed mouse buttons done on the contents part of a QNSView. But m_buttons can sometimes get out of sync with AppKit (NSEvent.pressedMouseButtons). One way this is shown to happen is if you do a mouse press on a native child widget (that is backed by it's own QNSView), and then convert the widget to a top-level window before the release. In that case, the underlying QNSView will be reparented from one NSWindow to another, which will result in the old NSWindow getting the mouseUp call instead of the new window. The result is that we don't update m_buttons for the reparented QNSView, which will instead be left as "pressed". As a result of m_buttons being stuck in a faulty state, we also refuse to send out QEvent::NonClientAreaMouseMove events to the top-level widget. This because QNSView thinks that it's already in a dragging state that started on the content part of the view (and not on the strut). As a result, it can sometimes be impossible to dock a QDockWidget back into a QMainWindow, since we basically don't send out any frame-drag events to Qt for the new dock window. We can reason that if you start a mouse press on the frame strut, you cannot at the same time have an active mouse press on the view contents. This patch will therefore remove the buttons that we know was pressed on the frame strut from m_buttons. This will at least (be one way to) clear the faulty pressed state, and will let us send mouse press/drag/release (and after that, move) frame strut events to Qt. Pick-to: 6.1 5.15 Task-number: QTBUG-70137 Change-Id: If51e1fe57d2531b659d39de85658893dae6391e3 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* iOS: Handle keyboard events when using an external keyboardAndy Shaw2021-01-201-2/+2
| | | | | | | | | | | | | | | | | | This enables the two possible approaches for handling external keyboard events. While support still exists for before 13.4 then both approaches are needed. This ensures that all external keyboard events are handled as key events and passed on accordingly. Additionally, this accounts for possible shortcuts too, therefore a new function is added to QShortcutMap to aid that. As a result, code has now moved from QCocoaKeyMapper to be part of the gui/platforms/darwin part to make it easier to reuse this code elsewhere. Fixes: QTBUG-85727 Change-Id: I349af43468b03fd8dcb16adba02669974affe154 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: Simplify Ctrl+LeftMouse->RightMouse handlingTor Arne Vestbø2020-07-101-2/+1
| | | | | Change-Id: I080bfaec273ea45809d72e513add16b7114c7bbb Reviewed-by: Timur Pocheptsov <timur.pocheptsov@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-2/+0
| | | | | | | Always returned true, also in the QWidgetWindowPrivate override. Change-Id: I01d11ae6f85882b52ce397125f994eea663ffcb5 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: Move Cocoa modifier mapping logic to QCocoaKeyMapperTor Arne Vestbø2020-07-021-3/+3
| | | | | | | Along with similar logic for Carbon. Change-Id: Ie32f8ffa336006387d50d3b9e8491816aba4ea04 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* macOS: Close popups on mouse down using synchronous QPA deliveryTor Arne Vestbø2020-06-261-2/+1
| | | | | Change-Id: I5ccb5ca4f9b9f7a480c575c5a2710ec20361cf88 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* macOS: Check that platform window is valid after delivering close eventTor Arne Vestbø2020-06-261-0/+2
| | | | | | | | Fixes: QTBUG-78814 Pick-to: 5.15 Change-Id: I551024c5d777999f7c79d21fd7b7de061c18f971 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* macOS: Simplify Objective-C namespacingTor Arne Vestbø2019-10-151-4/+4
| | | | | | | | | | | | | | | | We only need to use the QT_MANGLE_NAMESPACE macro when declaring the interface of the class. As long as we couple that with an alias declaration using QT_NAMESPACE_ALIAS_OBJC_CLASS, any further uses of the class name can be un-namespaced, including declaring categories on the class. The only snag with QT_NAMESPACE_ALIAS_OBJC_CLASS is that it can only be used once per class and translation unit, so forward declarations get hairy, but we can avoid that by just including the headers instead. Change-Id: I333bcd18fe1e18d81fbd560b0941c98b1c32460e Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* Merge remote-tracking branch 'origin/5.13' into 5.14Liang Qi2019-09-041-1/+3
|\ | | | | | | | | | | | | | | | | | | | | Conflicts: src/corelib/codecs/qicucodec.cpp src/dbus/qdbusserver.cpp src/gui/painting/qbezier.cpp src/plugins/platforms/eglfs/deviceintegration/eglfs_kms/qeglfskmsgbmscreen.cpp src/plugins/printsupport/cups/qppdprintdevice.cpp Change-Id: I2703128bb64baf5580fbc2c2061b55b0f0611d2a
| * macOS: Bail out early in case a popup is closed by a mouseDownTimur Pocheptsov2019-08-191-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | It can happen that AppKit calls -mouseDown: on a popup's view, but we consider the click to be outside of popup's area (happens on the 1-pixel edge of a 'geometry', QRect::contains() returns false). If we send close event to essentially 'self', m_platformWindow is becoming nullptr. So we bail out early, no further processing is needed. Fixes: QTBUG-77348 Change-Id: I224943e6bcf4ae052412ef7dc7b23a94f999aa19 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* | Merge remote-tracking branch 'origin/5.13' into devLiang Qi2019-06-141-4/+3
|\| | | | | | | | | | | | | | | | | | | Conflicts: qmake/generators/makefile.cpp qmake/generators/unix/unixmake2.cpp src/corelib/thread/qthread_unix.cpp tests/auto/corelib/tools/qsharedpointer/tst_qsharedpointer.cpp Change-Id: I1df0d4ba20685de7f9300bf07458c13376493408
| * macOS: Fix reported mouse event buttonsMikhail Svetkin2019-06-031-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | Use m_buttons instead of currentlyPressedMouseButtons. The latter returns the state of devices combined with synthesized events at the moment, independent of which events have been delivered via the event stream, so this method is not suitable for tracking. Task-number: QTBUG-74057 Task-number: QTBUG-74121 Change-Id: Iabf99ada6c3d25a995c9ddf895059b70833a9051 Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
* | Merge remote-tracking branch 'origin/5.13' into devLiang Qi2019-05-131-7/+35
|\| | | | | | | | | | | | | Conflicts: src/corelib/tools/qstring.cpp Change-Id: I81dbf90fc936c9bf08197baefa071117bddb1c63
| * macOS: Always respond to cursorUpdate by applying custom cursor if setTor Arne Vestbø2019-05-081-4/+7
| | | | | | | | | | | | | | | | | | | | Calling super will push the default arrow cursor, so we should only do that if our own cursor has been unset. Change-Id: I71d8934e7eab2b15e150730e2282e7063ada305a Fixes: QTBUG-75552 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
| * macOS: Move off deprecated handleFrameStrutMouseEvent APITor Arne Vestbø2019-05-071-3/+28
| | | | | | | | | | | | | | Change-Id: Id95c096700a8bfa733d8620064c2a37eb19cc3db Fixes: QTBUG-72741 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* | Implement support for WA_MacNoClickThroughAndy Shaw2019-04-011-0/+5
|/ | | | | | | | | | 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>
* macOS: Improve mouse loggingTor Arne Vestbø2019-03-051-6/+20
| | | | | Change-Id: Icc81f73e728d9b3669afc37b0c1ef73588f24749 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* macOS: Initialize QNSView mouse related members with other mouse logicTor Arne Vestbø2019-03-021-0/+13
| | | | | | Change-Id: I4ff67028823d62ed67bf4303a58bee127bd76501 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: Simplify mouse trackingTor Arne Vestbø2019-02-111-27/+23
| | | | | | | | | | We don't need to react to updateTrackingAreas, as we only have a single tracking area that we can add once and forget. By asking AppKit to track all events in the visible rect, we can also pass a zero-rect for the tracking area. Change-Id: I2545712adc49b51904d5adc11f1faca36901b49d Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: Explain QNSViewMouseMoveHelper for future generationsTor Arne Vestbø2019-02-111-0/+16
| | | | | Change-Id: I61f38ee38d5afb657cd8b76b2b9dba1dac7167b4 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* qnsview_key/qnsview_mouse make Ctrl+left click work againTimur Pocheptsov2018-09-241-3/+7
| | | | | | | | | A result of typo/incorrect keyboard modifiers extracted + wrong button sent via QWindowSystemInterface::handleMouseEvent. Task-number: QTBUG-70512 Change-Id: I809168e363496884312412051e8d435f5794b3be Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: Update all deprecated enums to their 10.12+ equivalentsTor Arne Vestbø2018-08-311-17/+12
| | | | | Change-Id: I3034258da95c9c70eb6758db92967f438617f6e9 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* macOS: Teach QWheelEvent to handle a new ScrollMomentum phaseTor Arne Vestbø2018-08-171-23/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We detect if there's an upcoming momentum phase using the same trick used by e.g. Mozilla in their event handling: https://tinyurl.com/yd8lcs4l, and as recommended by an Apple engineer: https://tinyurl.com/y8yytlgv The event is not guaranteed to be in the queue, but in practice it seems to be. If this assumption fails we can add a wait timeout to the event search instead of using [NSDate distantPast] as a timeout (which only looks at queued events). When the momentum phase is detected, QWheelEvent::phase will have the new ScrollMomentum value, and the phase transitions will be ScrollBegin -> ScrollUpdate -> ScrollMomentum -> ScrollEnd. We no longer send ScrollEnd to signify that the user's fingers have been lifted off the trackpad; rather, the first event with ScrollMomentum phase means that the fingers have been lifted and macOS is now sending simulated-momentum events. This means ScrollEnd is a reliable indicator that the entire scroll gesture (both the user interaction and the momentum) has ended. If the ScrollMomentum phase is skipped, it means the user's fingers came to rest before being lifted, so there is no momentum. In that case the transitions will be ScrollBegin -> ScrollUpdate -> ScrollEnd. Task-number: QTBUG-63026 Task-number: QTBUG-65160 Change-Id: I80191a472f6fa892387004c199166a6350124274 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* macOS: Add missing m_ prefix to QNSView currentWheelModifiers memberTor Arne Vestbø2018-07-081-4/+3
| | | | | Change-Id: I057db59797f1e18c3a8fc5386f7e1295fe352e02 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* macOS: minor refactoring in mouse handlers for nsview/systemtrayiconMikhail Svetkin2018-05-311-17/+14
| | | | | | | Use new helper functions for mouse events Change-Id: I01e83a228deb16cbdb1d7c8c628a92d48055ee2b Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-07 02:29:42 +0000