summaryrefslogtreecommitdiffstats
path: root/src/plugins/platforms/cocoa/qnsview_keys.mm
Commit message (Collapse)AuthorAgeFilesLines
* macOS: Remove shadowed variable in handleKeyEventTor Arne Vestbø2022-12-051-1/+0
| | | | | Change-Id: Icf9f9ecf673a10a15a2d0156bcd5c1da3688b591 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* macOS: Don't pass on key event text for function keys when IM is disabledTor Arne Vestbø2022-12-051-1/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On macOS function keys such F1-F16 and the arrow keys result in NSEvents with a character in the 0xF700-0xF8FF range of the private use area: https://unicode.org/Public/MAPPINGS/VENDORS/APPLE/CORPCHAR.TXT We used to filter these out for all key events sent from the platform plugin (4dbce2a4696081), but this had the side effect of breaking the Unicode Hex Input keyboard's ability to explicitly input these characters. As of 705665957baf16f9ec4d256dd4d2fad98788314b we started trusting the macOS text input system on whether a key event should include text or not, which fixed both the hex keyboard and Russian keyboard input when the key included the ^⌥ modifiers. Unfortunately this didn't account for the case of non-IM enabled input, so we started sending key events with text for arrow and function keys. And since Arial Unicode MS provides glyphs for these code points, we would end up with confusing characters in input fields when pressing the arrow keys. In general a client can not assume that the text() of a QKeyEvent is printable, and the logic to determine if a character should be filtered out or not depends on the font matching, since all code points can in theory have a font that provides a glyph for it, but since we know that the function key range on macOS is not supposed to have associated glyphs we filter them out explicitly. Note that we only do this for non-IM enabled text input, and otherwise leave it up to the macOS text input system to determine if a event should result in text insertion or not. Task-number: QTBUG-106393 Pick-to: 6.4 6.4.2 Change-Id: I5498fbedee21b0720c56e99b26924959ade897bf Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* macOS: Pass on native virtual key (key code) for modifier keysTor Arne Vestbø2022-10-051-1/+8
| | | | | | | | | | | | Regression after f563203f60f2cb4d03650af3a357e988aa6bce32. Unlike the characters and charactersIgnoringModifiers properties, the keyCode property of an NSEventTypeFlagsChanged event can be read without causing an NSInternalInconsistencyException. Fixes: QTBUG-69608 Pick-to: 6.2 6.4 Change-Id: Id3679a468fbc609112bd8fb37aa7acc526492d19 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* macOS: Remove hard-coded logic for determining if key event has textTor Arne Vestbø2022-09-171-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The normal flow for a keyDown event when sent to a text input enabled view (NSTextInputClient), is that it's sent through interpretKeyEvents, which in turn goes through the input methods, and result in either composing (marking) text, inserting text, or executing a text editing command such as moving the cursor to the beginning of the line. https://apple.co/3qDhwNb In our case, we prefer to treat "simple" text insertion (non-composed text) outside of the Qt input method protocol, and send these as normal key events instead. The same applies when a key event results in a text editing command that we don't handle. The problem is that in the latter case, the key event would contain the text that resulted from e.g. ⌘+K, or one of the function or arrow keys, which in many cases would not be suitable for inserting into a text field by a naive client that trusted the text property of the QKeyEvent. To work around this two exceptions were added; first in 4dbce2a4696081 to ignore text when inside the U+F700-U+F8FF unicode range (arrow keys, function keys, etc), and second in 933fab137dcaa8 to ignore text for events that had one or both of the control or command modifiers. Unfortunately this hard-coded logic was not taking into account that some keyboard layouts may produce text that match these exceptions, for example ^⌥+ю with a Russian keyboard layout should result in inserting a period. Instead of continuing to add hard-coded exceptions to this logic, (for example by only filtering out single-modifier events), we instead use the information that the text input system gives us via doCommandBySelector to decide whether the key event should have text or not. Note: We have similar workarounds for detecting text that is not suitable for text insertion in other places of Qt, for example in QInputControl::isAcceptableInput(), but since we can't assume the client uses QInputControl for their text input needs we need to filter out the text earlier than that. Fixes: QTBUG-106393 Task-number: QTBUG-36281 Task-number: QTBUG-35734 Pick-to: 6.4 Change-Id: I7769098cba1c605f6fdb6b23964eb614578724bb Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QWSI: Remove dead code for macOS-specific shortcut-override handlingTor Arne Vestbø2022-09-151-2/+1
| | | | | | | | | | | | | | | | | | | | | | 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>
* macOS: Check m_platformWindow before processing key event after shortcutTimur Pocheptsov2022-08-051-1/+1
| | | | | | | | | | | Processing shortcut events may result in the window being deleted, so we need to check if m_platformWindow is still valid before continuing with the key press event. Pick-to: 6.4 6.3 6.2 5.15 Fixes: QTBUG-105160 Change-Id: I9cd362873b19c078a4fced3ac3c815d70bfc7fbe Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@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>
* macOS: Don't read keyCode of non-key events when inserting newlinesTor Arne Vestbø2021-12-221-1/+2
| | | | | | | | | | | | | | | | | | | | | | | When the system input method decides to trigger an insertNewline message it might come from a synthetic NSEvent of type AppKitDefined, which does not respond to the keyCode message. Accessing the keyCode would result in an exception being thrown. We guard for this scenario by moving the keyCode access into the key-press and -release specific parts of the KeyEvent constructor, making the KeyEvent usable with generic NSEvents (even if that means it will only pull out the timestamp and modifiers). We also prefer to use the currently interpreted NSEvent, if one is available, when preparing the synthetic newline event. This ensures that we get a valid timestamp and modifiers, since the synthetic AppKitDefined event that the system IM generates does not provide valid values for these. Fixes: QTBUG-99186 Pick-to: 6.2 6.3 Change-Id: I050ae2aa2d8ded1be3541f746e6c052f3546e27c Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Initialize member variables before we check their valuesVolker Hilsheimer2021-10-251-5/+3
| | | | | | | | | | | | | Amends 51679efcf97dfea86431912eeb9489088c0804ed, which broke Ctrl+key handling so that the key was not translated based on the alphanumerical character anymore. Fixes: QTBUG-97713 Pick-to: 6.2 Change-Id: I9835fd7af99693aae636ba3c4c114ef8e11621e9 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Eike Ziller <eike.ziller@qt.io>
* qcocoa: Fix typos in source code commentsJonas Kvinge2021-10-121-1/+1
| | | | | | Pick-to: 6.2 5.15 Change-Id: Ide20e1d133891890a7673c8403ea91b489baa8f6 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: Ensure cancelOperation is sent as regular key eventWang Chuan2021-10-051-1/+3
| | | | | | | | | | | | | | Since 9e1875483ceaf907226f84cd6a58ab59f7f16f80 the logic of sending QKeyEvent was changed to only happen when we explicitly decided to not treat input as complex text, or when a selector for a command was not found. This missed the case where we handle cancelOperation by falling back to sending a regular key event. We now set m_sendKeyEvent to true to trigger this logic. Fixes: QTBUG-97119 Pick-to: 6.2 Change-Id: Ibb72f4b068cce735db8d76e5e0a1882aae115207 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: Don't re-send key event through input method on focus object changeTor Arne Vestbø2021-09-211-9/+0
| | | | | | | | | | | | | | | | | | | | | | | In 0c2ca26cd9583092f3ade7b18bc2423336a6202b we started re-sending the key event through the input method when we detected a focus object change, to support the use-case of QAbstractItemView opening an editor and changing focus in response to the first QEvent::InputMethod event. Unfortunately this doesn't work as a general approach, because we don't know what the reason was for the change in focus object. For example, a client might respond to a Qt::Key_Return press by changing the focus to the next input element, and re-sending the key event would in that case insert a new-line in the new focus object -- counter to the expectations of the client. Since we can't know the reason for the changed focus object we can't assume re-sending the key event is safe. Task-number: QTBUG-54848 Fixes: QTBUG-96726 Pick-to: 6.2 6.2.0 Change-Id: Iea8b166385925cd1a05ef62d5cf763638d9f8a67 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* macOS: remove mouse and key grabbing logic from Cocoa pluginVolker Hilsheimer2021-09-151-6/+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: Hide mouse cursor when initiating IM enabled text inputTor Arne Vestbø2021-08-271-0/+13
| | | | | | | Fixes: QTBUG-72744 Pick-to: 6.2 Change-Id: I952710e88a11fd00498562c9011461a010f02f7b Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* macOS: Assume input method handles key eventTor Arne Vestbø2021-08-271-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When input methods are enabled for the focus object we send key events through interpretKeyEvents, which will involve the input method in the key event processing. The input method will get back to us with callbacks such as insertText, setMarkedText, or doCommandBySelector. In the case of insertText, when the inserted text matches the originating key event's text, we opt to not send the text as an QInputMethodEvent, and instead fall back to sending it as a normal QKeyEvent. The reason for this is that Qt's IM protocol was designed to handle composited text, so sending non-composited (but IM-initiated) text input as IM events is unexpected (see 2d05d3bd2815c220474b3c07bf3f2ef7417d3070). However, we cannot assume that the input method will always call us back with one of the above mentioned methods. The input method can very well eat the event as part of its own operation. This happens for example when pressing and holding 'a' in a US English keyboard layout, which will pop up an input panel for the various accents available. Or it may happen when using the AquaSKK third party IM, which uses the 'l' key to switch the input mode to latin without producing any characters. To allow these input methods the freedom to control the processing of key events we need to reverse the logic for when we send key events as QKeyEvent. We now assume that the IM will handle the event, and only trigger QKeyEvent in two cases where we explicitly were called back by the IM, but decided that a QKeyEvent is needed: - If the IM calls insertText and we consider the text simple text - If the IM calls doCommandBySelector and we can't find a matching selector for the command. We only implement insertNewline and cancel, so in all other cases we want to pass on the key event to let the focus object handle it, for example for 'Select All' and similar key combinations. Fixes: QTBUG-46300 Fixes: QTBUG-71394 Pick-to: 6.2 Inspired-by: Vladimir Belyavsky Change-Id: I9a73a8e1baa2ebe0c5df1166a9ec3d9843632bb1 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* macOS: Handle IM insertNewline by sending synthetic Qt::Key_ReturnTor Arne Vestbø2021-08-271-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Depending on the input method, pressing enter may result in simply dismissing the input method editor, without confirming the composition. For example with Hiragana, pressing 'a', then 'Tab', and then 'Enter'. In other cases it may confirm the composition as well, for example with Hiragana, pressing 'a' and then 'Enter'. And in some cases the IME will produce an explicit new line, for example with US English, pressing '~' and then 'Enter', or with 2-Set Korean, pressing 'a', then 'j', and then 'Enter'. Semantically, the input method has then asked us to insert a newline, and we should probably do so via an QInputMethodEvent, either directly or via [self insertText:@"\r"]. This is also how NSTextView handles the command. But, if we did, we would bypass all the code in Qt (and clients) that assume that pressing the return key results in a key event, for example the QLineEdit::returnPressed logic. To ensure that clients will still see the Qt::Key_Return key event, we send it as a normal key event. But, we can not fall back to handleKeyEvent for this, as the original key event may have text that reflects the combination of the inserted text and the newline, e.g. "~\r". We have already inserted the composition, so we need to follow up with a single newline event. Task-number: QTBUG-39125 Pick-to: 6.2 Change-Id: If1e95687e6d5b06011692175a325f457b0b8a72f Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* macOS: Factor out key event handling into helper structTor Arne Vestbø2021-08-271-72/+115
| | | | | | | | | | | This allows us to share code between handleKeyEvent: and flagsChanged: for parsing the incoming NSEvent, and allows for sending key events from other call sites in the future without duplicating the parsing and sending logic. Pick-to: 6.2 Change-Id: Ic63f740523496a9432e439663a20f78b5bc234c5 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* macOS: Return early from key handler if shortcut was handledTor Arne Vestbø2021-08-271-7/+3
| | | | | | | | The code paths after accepting a shortcut event can never be hit. Pick-to: 6.2 Change-Id: Ida77417adb8fcfd25a4b20c4eb86056b3769f014 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* macOS: Check NSEvent.characters to determine dead key stateTor Arne Vestbø2021-08-271-2/+3
| | | | | | | | | | | | | | We map NSEvent.characters to text that we pass on in our QKeyEvent, but for Qt 4 compatibility we explicitly skip function keys and arrow keys, as the text these events produce are control characters. See 4dbce2a469608194527188a136baa3e812caf361. However, these keys are not dead keys, so we can't use the resolved text we're planning to pass on to Qt to determine if they are. Pick-to: 6.2 Change-Id: Ib59f0489ae014379c699600f14634c55161ccc8a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* macOS: Use current NSEvent to determine if IM text matches key eventTor Arne Vestbø2021-08-271-4/+0
| | | | | | | | | Gives us one less state member to worry about in the IM machinery. Task-number: QTBUG-35700 Pick-to: 6.2 Change-Id: Iaa06b29015f9b9594b8107b74a8931f076a26e12 Reviewed-by: Liang Qi <liang.qi@qt.io>
* macOS: Modernize and clean up key event handlingTor Arne Vestbø2021-08-261-54/+56
| | | | | | | | | | | | | - Pass key event type as QEvent::Type - Use proper type for NSEventModifierFlags - Use modern Objective-C property access in key handler - Modernize flagsChanged implementation using ranged-for - Use explicit Qt::Key type in key handling - Add FIXME comments for dubious code Pick-to: 6.2 Change-Id: I533e0a5685108dc3cdccd2b276b4eb7a729d172e Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* macOS: Use helper method for querying input method parametersTor Arne Vestbø2021-08-191-12/+19
| | | | | | Pick-to: 6.2 Change-Id: I379d4ca20101899db2dfbd8f0c5a22f423e40d6b Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* macOS: Add logging for keyboard and complex text inputTor Arne Vestbø2021-08-161-7/+22
| | | | | | Pick-to: 6.2 Change-Id: I098829e051d4f63950b2e35ee6dd4def8d70cf01 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* macOS: Resend event if the first input method event changes focusVolker Hilsheimer2021-06-181-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QAbstractItemView opens the editor and changes focus in response to the first QEvent::InputMethod event. Changing focus however cancels the current composition, so the key press is lost and needs to be repeated by the user. What QAbstractItemView does is probably not that unique, so fixing this there - if possible at all - is not a general solution. In the platform specific input method handling code, we can generally discover that the focus object changed in response to the InputMethod event that gets sent to the focus object. On macOS, we can then pass the key event to the input method once more, which works fine. On Windows and X11, the situation is more complicated. That the focus changed is easily discovered, but re-sending the key press in such a way that the input method responds doesn't seem possible. On Windows, using SendInput simply delivers the exact key to the focus object, without starting the expected composition. On X11 with IBus, it should be possible to call ProcessKeyEvent again on the IBus input context when we discover in filterEventFinished that the focus object changed while delivering the event. However, any attempt to do so has no effect. So, for now only fixing this for macOS. Task-number: QTBUG-54848 Change-Id: I0f7b786cfa57430e6a1e7d605415265cf53eb675 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: in password lineedits, pass dead keys to the input methodVolker Hilsheimer2021-05-061-1/+5
| | | | | | | | | | | | | | | Otherwise the IM cannot correctly compose the input, making it impossible to enter e.g. ü or ~ on certain keyboard layouts. Note that the native macOS NSSecureTextField does not allow that either, which is however a very bad user experience. With this change, the modifier characters like ¨ diacritics will be visible when entering them in either NoEcho or Password line edits. The follow-up commit will remove those as well. Fixes: QTBUG-84664 Change-Id: Ib4c5ab85634c17c407623f82b46c4849c72d9e69 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* iOS: Handle keyboard events when using an external keyboardAndy Shaw2021-01-201-4/+4
| | | | | | | | | | | | | | | | | | 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>
* Un-special-case macOS in handling of QKeyEvent::nativeScanCode()Tor Arne Vestbø2020-10-061-10/+12
| | | | | | | | | | | | | | | | | | | | | | | In the porting from Qt 4 to Qt 5 an assumption was made in QKeyMapper that the underlying platform implementation needed the native scan code to be able to resolve the possible keymaps for an event. As a result, the macOS platform plugin started sending key events with a fake native scan code of 1, so that it would still be allowed to map key events. Which in turn led to the documentation of QKeyEvent::nativeScanCode() getting an exception for macOS. Let's clean up this by removing the original assumption, and leave it up to the platforms to decide what information from the key event is needed. QKeyMapperPrivate::possibleKeys() will still call extractKeyFromEvent as a fallback if the platform layer doesn't return any possible keys. Change-Id: I122a45bcec658c45ccc0b2c0671eb264d85d7be6 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* [macOS] Add native virtual key code to modifier keysMichael Brüning2020-09-101-9/+18
| | | | | | | | | | | | | | Not forwarding the native virtual key code when sending key events in the flagsChanged handler caused a number of problems, e.g. the inability to determine which of the Alt or Shift keys were pressed. Use handleExtendedKeyEvent to include the native virtual key code. Patch inspired by Nyan Pasu. Fixes: QTBUG-69608 Change-Id: I15e9ff1069528d4b50ee4638ab2d8a6fd279db0b Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: Simplify dead key handlingTor Arne Vestbø2020-07-101-2/+2
| | | | | Change-Id: Ie2e2c6e1b1daf08146fd42f3ce58194ee1918794 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* macOS: Move key mapping from QtCore to platform pluginTor Arne Vestbø2020-07-021-6/+1
| | | | | | | | | | | There's a bunch of similar and overlapping logic in QCocoaKeyMapper already. Moving it to the same place allows us to easier find ways to reduce the overlap. None of the exported functions were used outside of the plugin. Change-Id: I6953690cdfda5ee8265b33ccbf919184c3a1700f Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* macOS: Move Cocoa modifier mapping logic to QCocoaKeyMapperTor Arne Vestbø2020-07-021-24/+3
| | | | | | | Along with similar logic for Carbon. Change-Id: Ie32f8ffa336006387d50d3b9e8491816aba4ea04 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* macOS: Simplify Objective-C namespacingTor Arne Vestbø2019-10-151-2/+2
| | | | | | | | | | | | | | | | 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>
* qnsview_keys - fix a typoTimur Pocheptsov2018-10-131-1/+1
| | | | | | | | | that resulted in 'Cmd' reported as combo of Qt::Meta/Qt::Control and Qt::KeypadModifier. Task-number: QTBUG-71006 Change-Id: I3dddc56f4d404a1ceefb21d57ac120b6273456ec Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* qnsview_key/qnsview_mouse make Ctrl+left click work againTimur Pocheptsov2018-09-241-1/+1
| | | | | | | | | 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-11/+11
| | | | | Change-Id: I3034258da95c9c70eb6758db92967f438617f6e9 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* macOS: Split up qnsview.mm into separate category-files for major areasTor Arne Vestbø2018-03-171-0/+262
Makes it easier to get an overview of the code, work on separate sections/areas in isolation, and highlights which part of the APIs we are using from outside of QNSView, and internally between the different parts of QNSView. Change-Id: Ia2c5ab9a68bf75feddba853ac20d3bb397f7564b Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-08 20:06:50 +0000