summaryrefslogtreecommitdiffstats
path: root/src/gui/platform/darwin
Commit message (Collapse)AuthorAgeFilesLines
* macOS: Improve QAppleKeyMapper loggingTor Arne Vestbø2021-09-131-1/+14
| | | | | | Pick-to: 6.2 Change-Id: If0018f2a1c8809e66b695949e8dc7b463c4612a6 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* macOS: Clarify QAppleKeyMapperTor Arne Vestbø2021-08-201-7/+29
| | | | | | Pick-to: 6.2 Change-Id: I6a6fb4a8ee6e9457b3a09b0ef51e71028df3356d Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* macOS: Map dead keys directly to their terminator when building key mapTor Arne Vestbø2021-08-162-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a key press comes in we may end up in QAppleKeyMapper::possibleKeys() as part of checking whether the key press should trigger a QShortcut. The function builds on QAppleKeyMapper::keyMapForKey(), which provides a map from the given virtual key to all the possible Qt::Keys that can be produced by applying different modifier key combinations. The map is built using the Carbon function UCKeyTranslate, that takes the current keyboard layout, virtual key, and modifiers, and produces the resulting characters. The function also maintains a running dead key state via one of the arguments. When mapping a dead key, the state variable will be updated to the current dead key state, which then affects the next call to the function (for the next key press). The problem is that we're not calling UCKeyTranslate for each key press. We are calling it in a loop, for a single key press, to build up a map of all the possible characters produced by varying the modifier keys. And in doing so, we are passing on the dead key state from one call to the next, even if these are for different modifiers. The result is that the first call, for the dead key, results in mapping to \0, as UCKeyTranslate produces no output, it only modifies the dead key state. And then the next call, for the next modifier key combination, results in mapping to a character that incorrectly incorporates the dead key state (resetting it in the process). What we really want is to directly map the initial modifier combination to the dead key terminator character, if one is defined. This is the character produced if the dead key state is cancelled, for example by pressing a key that's not defined in the dead key state. To achieve this we pass kUCKeyTranslateNoDeadKeysMask as the translate options to UCKeyTranslate, and always reset the dead key state before every call. Another common way to achieve the same result would be to call UCKeyTranslate a second time when detecting that the first call produced a dead key state, for example with a synthetic space key, to trigger the terminator output. But this can potentially fail if the space key actually has a defined output in the dead key state. Fixes: QTBUG-95471 Pick-to: 6.2 6.1 Change-Id: Icdae7639fd9a641a86c9d6615679bd93d380ff5c Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* macOS: Don't treat null-key as potential shortcut keyTor Arne Vestbø2021-08-161-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When mapping virtual keys and modifiers to their corresponding characters via a keyboard layout we may hit combinations that do not produce any characters. This can happen if there's no <key> element defined for the virtual key, or if the output attribute of the element is empty (despite the spec saying there should always be one UTF-16 code point in the output). https://developer.apple.com/library/archive/technotes/tn2056/_index.html When that happens QAppleKeyMapper::keyMapForKey() will map the combination to a null-QChar, resulting in the "key" being 0. We do not want to propagate this back to the QShortcutMap machinery, as QShortcutMap does not validate the keys coming out of QKeyMapper::possibleKeys(). In particular, it doesn't check the isEmpty() or count() of the QKeySequences it creates. And even if it did, QKeySequence itself seems to treat Qt::Key(0) + Qt::SomeModifier as a non-empty sequence, so passing on 0-keys would still give weird bugs. The user-visible result of passing back 0-keys is that QShortcutMap will treat it as a partial match for any incoming key combination (as long as some modifier is pressed that triggers the QShortcutMap machinery), which resulting in eating the key press. This compounded the issue in QTBUG-95471. Regression after fab3dfff7d53d496a31c5d2df972ddacfe861a4d. Task-number: QTBUG-95471 Pick-to: 6.1 6.2 Change-Id: I2e51ec86f4df2a708e1757be827ab74859be3c8b Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* iOS: Pass the text to handleExtendedKeyEvent when knownAndy Shaw2021-02-232-2/+6
| | | | | | | | | This will ensure that the QKeyEvent also has this information passed on as appropriate. Pick-to: 6.1 Change-Id: I52436404115b453664b9b3414f8ec4e715dd6a28 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: Don't assume NSEvent charactersByApplyingModifiers: produces characterTor Arne Vestbø2021-02-051-2/+5
| | | | | | | | | | In cases where the keyboard layout doesn't have a mapping for a given event and modifier combination the result will be an empty string. Fixes: QTBUG-90683 Pick-to: 6.0 Change-Id: Ice06241f0ae71a19cde041410818decc312bc630 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* macOS: Don't wrap key event keys in QCharTor Arne Vestbø2021-02-052-13/+17
| | | | | | | | | | | | | | | | | | | | | | | Key events have a wider range of possible values than the unicode range, as they also include all the special keys as defined in Qt::Keys. Instead of turning the argument to keyMapForKey into an integer, we can remove the argument completely, as it was only used as a fallback in the cases where UCKeyTranslate (or in the future, charactersByApplyingModifiers:), failed to map the virtual key and modifiers to a character. But in those cases we should not fall back to the Qt key from the key event, as that doesn't match what the keyboard layout defines. Most keyboard layouts explicitly define the base key as the key for these "undefined" mappings, but if the keyboard layout does not, we should not produce any input in the application, to match what AppKit does in this case. Fixes: QTBUG-90315 Pick-to: 6.0 Change-Id: Ib9ffd9521049ee8e4b103597c1d34cbe3d23dbdf Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* Add "we mean it" warning to private headerVolker Hilsheimer2021-02-031-0/+11
| | | | | | | Fix warning from configure. Change-Id: I12def11a4effb7298ec0501cfac4ffd37b777ff6 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* iOS: Handle keyboard events when using an external keyboardAndy Shaw2021-01-202-0/+756
| | | | | | | | | | | | | | | | | | 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>
* Remove the qmake project filesJoerg Bornemann2021-01-071-4/+0
| | | | | | | | | | | | | | | | Remove the qmake project files for most of Qt. Leave the qmake project files for examples, because we still test those in the CI to ensure qmake does not regress. Also leave the qmake project files for utils and other minor parts that lack CMake project files. Task-number: QTBUG-88742 Change-Id: I6cdf059e6204816f617f9624f3ea9822703f73cc Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* Doc: Fix documentation warnings for Qt GUITopi Reinio2020-08-281-14/+16
| | | | | | | | | | | | * Drop deprecation warnings for now-dropped items * Use the 'qt6' define and a new \nothing doc macro to conditionally document items on Qt 6 * Add a custom module header for docs that pulls in also Vulkan headers * Add \internal command for internal classes/functions * Move QtGUI-related code snippets from widgets to gui docs Change-Id: Ieb386b96631a49568d09059906d307c45c01d93a Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Only add file url if it references a local fileMichael Brüning2020-06-201-1/+2
| | | | | | | | | | | | Remote URLs were converted to local file urls and converted to relative paths, which led to bugs when copying URLs from e.g. the web sites and pasting them into the command line. Original patch by Allan Sandfeld Jensen. Task-number: QTBUG-80243 Change-Id: I2cd41635b34b2ead424441719795705ef19d37f2 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Doc: Fix qdoc warningsPaul Wicking2020-06-031-10/+10
| | | | | | | Use \li for list items. Change-Id: I5ab253e22077cd7132f28c8690aa2a9a4b8b489c Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Move QMacInternalPasteboardMime to QtGuiTor Arne Vestbø2020-05-213-0/+1148
Task-number: QTBUG-83255 Change-Id: I00fda24479ad2c04781c5fefaa15fac1118033a8 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>