summaryrefslogtreecommitdiffstats
path: root/src/plugins/platforms/cocoa
Commit message (Collapse)AuthorAgeFilesLines
* macOS: Add support for custom uri scheme handlingJuha Vuolle26 hours1-1/+13
| | | | | | | | | | | | | | | | With this support applications can claim to be handler for specific custom scheme URLs such as "com.my.app" This requires that the scheme is listed in the plist file (CFBundleURLTypes and CFBundleURLSchemes). One notable usage example is the use of OAuth redirect_uris. [ChangeLog][macOS] Added support for custom uri scheme handling Task-number: QTBUG-124340 Change-Id: Ia04e9b89b53ee6f24129f9dd5ee8fbc5c0f0516c Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: Add support for universal links / https uri scheme handlingJuha Vuolle26 hours3-0/+45
| | | | | | | | | | | | | | | With this support applications can claim to be handler for specific https URLs. This requires that an appropriate AASA (apple-app-site-association) JSON file is hosted and accessible. One notable usage example is the use of OAuth redirect_uris, which are often required to use "https" URI scheme. [ChangeLog][macOS] Added support for https/universal links handling Task-number: QTBUG-124340 Change-Id: I91c725fcf209b295dc1b2687a52cd0a547aff1c8 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QCocoaMenu: fix crash when app quits while menu is openMitch Curtis8 days1-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consider the following QML code: import QtQuick import QtQuick.Controls ApplicationWindow { visible: true Menu { id: menu MenuItem { text: "Some action" } } TapHandler { acceptedButtons: Qt.RightButton onTapped: { exitAppTimer.start() menu.open() } } Timer { id: exitAppTimer interval: 1000 onTriggered: Qt.quit() } } With the new native Qt Quick Menu, this will create a native menu on platforms like macOS. When the user right clicks on the window, a timer is started and a native menu opened. After 1 second, Qt.quit() is called while the menu is still open. As popUpContextMenu is blocking, when the menu is finally closed (by user interaction), control returns to QCocoaMenu::showPopup, but the QCocoaWindow has since been destroyed. Account for this by storing the window in a QPointer. It's not possible to test this as native menus can't be auto-tested. Fixes: QTBUG-124551 Pick-to: 6.5 6.7 Change-Id: I14a97073f350c38828b3e16bb157439aeeeb6529 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* macOS: support shortcut for Ctrl-modified TabVolker Hilsheimer2024-04-131-10/+29
| | | | | | | | | | | | | | Ctrl+(Shift/Option/Cmd)+Tab presses are not handled as a regular key events, and are not seen by our NSView.keyDown implementation. But they are delivered to a performKeyEquivalent implementation, so if we see a Tab key being pressed with the Ctrl modifier down, then send a shortcut event and stop processing if that event got accepted by Qt. Pick-to: 6.7 Fixes: QTBUG-113492 Task-number: QTBUG-8596 Change-Id: Id3aa7021a689b94d97eb881b19ddf7cb039e1bd2 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: Send key press as QKeyEvent if input context doesn't consume itTor Arne Vestbø2024-04-081-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | If IM is enabled we send key events through the macOS text input system, and we do this for all key pressed, including the ones with modifiers pressed. The latter allows the input method to respond to shortcut key combinations to switch its own mode or do more advanced operations on the text. We were relying on the IM to call doCommandBySelector with a noop selector if the shortcut didn't match any of its own internal key sequences, but this fails for key events with more than one modifier pressed. Instead of using [NSView interpretKeyEvents:] to pass the key event to the system IM we now go directly to the NSInputContext, which the former method is just a wrapper for. This allows us to use the result of [NSInputContext handleEvent:] to determine if the system IM consumed the event or not. For key events with multiple modifiers this will be false, which we interpret to send the event as a regular QKeyEvent instead. Fixes: QTBUG-123848 Fixes: QTBUG-106516 Pick-to: 6.7 6.5 6.2 Change-Id: I14a43c2029149514515dd9ece881aed3f6500a4e Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* macOS: Remove popup mouse and app activation monitors on app shutdownTor Arne Vestbø2024-04-031-0/+3
| | | | | | | | | | | | We're not guaranteed to get into any of the code paths that call removePopupMonitor() before the app goes away. In a plugin-scenario, this may cause crashes when our monitor then gets a callback and we try to access QGuiApplicationPrivate::instance(). Pick-to: 6.7 6.6 6.5 6.2 Fixes: QTBUG-123959 Change-Id: I287b91ff261a8aab74adbbad8c63a042daf944d5 Reviewed-by: Doris Verria <doris.verria@qt.io>
* Add AA_DontUseNativeMenuWindowsMitch Curtis2024-03-151-3/+9
| | | | | | | | | | | | | | | Also add some categorized logging output to make it easier to check if native menus are being created. [ChangeLog][Qt Core] Added AA_DontUseNativeMenuWindows application attribute. Menu popup windows (e.g. context menus, combo box menus, and non-native menubar menus) created while this attribute is set to true will not be represented as native top level windows, unless required by the implementation. Task-number: QTBUG-69558 Change-Id: Iba11b89c67d942ce6c5a28a7c57a86e63c020618 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: Forward application{Will,Did}FinishLaunching to reflection delegateTor Arne Vestbø2024-03-141-2/+5
| | | | | | | | | | | If a custom application delegate is installed prior to creating the Qt application delegate we will forward callbacks to the delegate, but this has to be done manually for any callback we implement. Fixes: QTBUG-122996 Pick-to: 6.7 6.6 6.5 Change-Id: Ia25e2c4b8cac37130d604c772c875c5d76c66764 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* QEventDispatcher*: port the Unix dispatchers to V2Thiago Macieira2024-03-132-20/+21
| | | | | | | | | | | They're all ported in one go because all the changes are the same and they all rely on QTimerInfoList. The changes are: - use Qt::TimerId to uniquely identify timer IDs - use Duration (nanoseconds) to specify the timer interval - rename registeredTimers() to timersForObject(), which is const Change-Id: I83dda2d36c904517b3c0fffd17b52958767d8a68 Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
* Add QT_IM_MODULES env to allows specify multi IM keyJiDe Zhang2024-03-051-3/+3
| | | | | | | | | | | | | | | | | Like as QT_QPA_PLATFORM, supports specifying multiple keys, and can perform fallback operations to prioritize the use of a certain plug-in. This is useful when using Wayland and XWayland applications at the same time. For an example, we can set "QT_IM_MODULES=wayland;fcitx", and the wayland application will use the wayland input context plugin, the xwayland application will use fcitx, which can't be done without adding a new environment variable, if we specify "QT_IM_MODULE=wayland", the XWayland applications may not be able to use the input method. Fixes: QTBUG-120202 Change-Id: Iac408af241963147747a2fe685f1e27bf9d9ee64 Reviewed-by: Liang Qi <liang.qi@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: David Edmundson <davidedmundson@kde.org>
* Apple: Fix a few deprecation warnings after bumping deployment targetsTor Arne Vestbø2024-02-195-8/+10
| | | | | | | | | | | | - kIOMasterPortDefault -> kIOMainPortDefault - Use UTType instead of Carbon Core functions/constants - NSWorkspace iconForFileType -> iconForContentType - Removed obsoleted kUTTypeInkText pasteboard type There are still a few more, but these will be fixed in follow ups. Change-Id: Ibbca226d578b4ba64bd9c8c5d0addc1870114a20 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* macOS: Expand and tighten plumbing of QWindow's requested color spaceTor Arne Vestbø2024-02-155-20/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A QWindow can have a requested target color space via its QSurfaceFormat. This allows users who know what color space their source material is in, or who do their own color matching, to ensure a consistent target color space. In the past we plumbed this to NSWindow's colorSpace property. This meant that you could only have one color space per top level, even if child windows were in play, and we could only set the color space if we were the ones creating the NSWindow, failing the color space request in cases where the window was embedded in a non-Qt window hierarchy. We now store the requested color space in our QNSView, and propagate it to both the IOSurfaces we use in QCALayerBackingStore, and to the view's layer, in case it's a CAMetalLayer. We also pick up any changes to the backing properties of the view, and ensure we update the color space accordingly. We still propagate the color space to NSWindow, as for OpenGL we don't use CAOpenGLLayer (which has a colorSpace property), but instead use NSOpenGLContext. This is not something we're going to change, so as a workaround we set the NSWindow color space, which does affect GL drawing via NSOpenGLContext. The granular color spaces we set on the IOSurfaces and CAMetalLayer will override the NSWindow state. Pick-to: 6.7 Change-Id: I5d9765d95140b8523ee09f70ff09a8c9400ffdc7 Reviewed-by: Pavel Dubsky <pavel.dubsky@qt.io> Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io> Reviewed-by: Artem Dyomin <artem.dyomin@qt.io> Reviewed-by: Jøger Hansegård <joger.hansegard@qt.io>
* macOS: Implement support for backing store static contentsTor Arne Vestbø2024-02-133-31/+93
| | | | | | | | | | | | | | | We already had the machinery to copy one buffer to another, so this machinery has been generalized a bit, so we can use it to preserve the static content during buffer resize. As explained in the comments, we need to do the buffer copies during buffer creation, instead of relying on our back buffer finalization, as we are not guaranteed that we can always copy the static content from the front buffer. Pick-to: 6.7 Change-Id: Ia9b3ac6ec982949990d172b0b14f35b13bbae92a Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
* Remove extra semi-colonsTasuku Suzuki2024-02-062-2/+2
| | | | | Change-Id: I92fddb36cd136fd1bd627955f15d0559b9942d7e Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* Fix -Wdeprecated-anon-enum-enum-conversion issue in cocoa pluginAndy Nichols2024-02-021-2/+2
| | | | | | | | Noticed when building with -c++std c++20 for macOS. Lots more warnings in general but this one was an error. Change-Id: I8dd9ae33f23dd77b2ec619b7357f50b97e3ed8ef Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: Don't condition deferred exec on specific NSAlert to be the modal windowTor Arne Vestbø2024-01-301-1/+1
| | | | | | | | | | | | | | | | | | | | | When a QMessageBox is created with setModal(true), the user can in theory choose to show() it, and then return back to the main event loop, instead of calling exec(). We tried to support that case via a single shot timer, called on the next pass of the event loop, that checked if the applications' current modal window was the alert, and if not, showed it at that point. That logic failed when there were more than one alert show at the same time. We do maintain a stack of the modal sessions and their windows in the Cocoa event dispatcher, so we could use that to check if a modal session had been started for the alert's window, but a similar solution is to just check the alert window's visible state. Fixes: QTBUG-121557 Pick-to: 6.7 6.6 6.6.2 6.5 Change-Id: I6f52a53e8f678bb8a071e334a09ab30669d95bbf Reviewed-by: Eike Ziller <eike.ziller@qt.io>
* QCocoaA(11)y: do not try to access an element if rowIndex == -1Timur Pocheptsov2024-01-251-1/+1
| | | | | | | | | | This ends up in out of bounds exception. Pick-to: 6.7 6.6 6.5 6.6.2 Fixes: QTBUG-120469 Fixes: QTBUG-121008 Change-Id: Id895f311bbb59a3734ecadd0d2472a4018332e16 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Revert "macOS: Don't crash when starting a drag with empty mime data"Volker Hilsheimer2024-01-241-2/+0
| | | | | | | | | | | | This reverts commit 09afa7575276d7b500f17671a1ca9ca677767b44. It broke Qt Designer, which creates QDrag objects without any mime format. It's likely that user code does the same to support internal drag'n'drop. Pick-to: 6.7 6.6 6.6.2 6.5 Task-number: QTBUG-119216 Change-Id: I8b74f2d9b89588cd35bca9ca20973810036a2635 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: Work around lack of native support for multi-part extensionsTor Arne Vestbø2024-01-171-21/+105
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Multi-part extensions such as "tar.gz" are not natively supported by macOS, e.g. one can not create a [UTType typeWithFilenameExtension:] for such an extension, and this goes all the way down to Foundation. As a result NSSavePanel gets confused when assigning a multi-part extension to allowedFileTypes, because it's using NSString operations such as stringByDeletingPathExtension or pathExtension, which also lack support for multi-part extensions. We've worked around this in the past by reducing these extensions to their last component, e.g. "tar.gz" reduced to "gz", but this results in the save panel turning the input file name "foo" into "foo.gz" if the user doesn't provide the full file name. Various attempts at working around the lack of multi-part extension support by breaking allowedFileTypes into ["tar.gz", "gz"], or doing selectively toggling of allowedFileTypes in panel:validateURL:error, have all proved to have corner cases and shortcomings of their own. As a last resort, we now treat multi-part extensions manually, by disabling the allowedFileTypes filter, and doing our own validation in the panel:validateURL:error callback. This requires us to also manually handle automatic extension for file names without extensions, as well as overwrite confirmation in the cases we do add an extension manually. The overwrite dialog and error messages for incompatible extensions have been modeled after their native macOS 14 counterparts, using translated strings from AppKit. Task-number: QTBUG-109877 Pick-to: 6.7 Change-Id: I6b7ce3c44b4c3b24802aa1f66f4593457ae4c929 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* macOS: Reset save dialog extension when resetting file name filterTor Arne Vestbø2024-01-172-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | We map QFileDialog name filters to NSSavePanel.allowedFileTypes, for example turning "Text Files (*.txt)" into allowedFileTypes = @[@"txt"]. In this case, the NSSavePanel will automatically add the extension to the user's file name, if they just type "foo". When a filter allows all files, we reset the allowedFileTypes to nil, but this does not reset the automatically added extension, so if the user switches from one filter (*.txt) to another (*.*), the file name will still have a .txt extension. This is problematic when the save panel's file name field does not show the extension to the user, which can happen automatically if the user types an initial file name without an extension, overriding what we've asked by setting extensionHidden=NO. When that happens, the user is shown "foo", but the actual file name is "foo.txt". To mitigate this confusing situation we do a round-trip via the UTTypeDirectory content type, which is a valid type without any extension. This forces the save panel to remove any extensions added automatically by previous filters. Pick-to: 6.7 Change-Id: Ia17a8c2734eff656116ef77a9813113a5076e9cc Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* macOS: Disable currentChanged signal for NSSavePanelsTor Arne Vestbø2024-01-171-0/+8
| | | | | | | | | | | | | | | The panelSelectionDidChange callback is only called when the user selects a directory in the save panel, as all other files are not selectable. And when that happens, the reported selection is not the directory, but the current file name (which may be based on clicking an exsiting file, but that doesn't cause selection changes). To avoid this confusing and inconsistent behavior we disable the signal entirely when showing an NSSavePanel. Pick-to: 6.7 Change-Id: If706b8faa7027ca284ec8398f5c6e2a110e01f91 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* macOS: Add helper function for getting AppKit localized stringsTor Arne Vestbø2024-01-153-2/+13
| | | | | | | | | | If we for some reason can't look up AppKit, or if the table or string within that table is not found we will end up using the key as is. Pick-to: 6.7 Change-Id: I5d574288e421e586458266899ffdff90eeadec8f Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* macOS: Explicitly show extensions in save dialog if filter is "all files"Tor Arne Vestbø2024-01-101-11/+19
| | | | | | | | | | Otherwise clicking an existing file in the dialog will not populate the full file name, which is what you'd expect for a filter allowing all files. Pick-to: 6.7 Change-Id: Ib9a014352d5e567e54f95414e744566615d735d8 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* macOS: Show extensions in file dialog when filtering on multi-part extensionTor Arne Vestbø2024-01-101-14/+22
| | | | | | | | | | | | | | | | | | | | | | | File extensions with multiple parts, such as as ".tar.gz" are not natively supported on macOS. Asking NSSavePanel to only allow file types with such extensions confuses it severely, so we work around it by reducing the native file name filter to the last component of the extension. In this situation, we explicitly tell the NSSavePanel to show the full filename, including the extension, so that the user can more easily see what the final file name will be. However, as part of 7f8a80ebf87cccb57da316202e5350eb5eca9d5d we ended up changing the logic to count the number of possible extensions for a given file type filter, not the number of parts in the extension. The logic has now been restored, but moved to init, so that it applies even if the initial filter is not a multi-part extension. Task-number: QTBUG-109877 Pick-to: 6.7 6.6 6.5 6.2 Change-Id: I244cea1cc2977f8adf7e359ea7116bbfad0e1059 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* macOS: Remove QScopedScopeLevelCounter from menu qt_itemFired callbackTor Arne Vestbø2023-12-211-1/+0
| | | | | | | | | | | | | | | | | | The activated signal is delivered as a queued connection, so we're going to raise the scope level as part of notifyInternal2() anyways. In addition, since c5d49725779292a04fed599eb7f508d334ffc5c3 we will automatically raise the level to 1 due to the catch all logic, so in case the connection is changed to direct connection, we'll still raise the scope level as needed. This removes the last remaining QScopedScopeLevelCounter outside of QtCore. Task-number: QTBUG-120124 Change-Id: I91a8ab8c1969d2209657daaca5c232928d1dd985 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* macOS a11y: rebuild table model if out-of-bounds cell is requestedVolker Hilsheimer2023-12-161-7/+34
| | | | | | | | | | | | | | | | | | | While it is the itemview's responsibility to keep the accessibility bridge updated about changes in the view's structure and size, we have experienced a number of assertions getting triggered when that wasn't done correctly. Instead of an assert (or hard crash in release builds), recreate the table representation in the accessibility bridge when a cell that is out-of-bounds for the current representation is requested. Emit a warning message to inform widget authors, and improve the debug message with information about the column count as well. Amends 52c2b82082b535123c0eecafe1ec1e4e4190df2a. Pick-to: 6.7 6.6 Change-Id: I19c20a932153268a5176d7378c485277088f10bf Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: Use CALayer backingstore when widgets request non-raster surfaceTor Arne Vestbø2023-12-131-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a non-raster widget is inserted into the widget hierarchy, widgets switches into using RHI for flushing its backingstore, matching the window's surface type with the non-raster widget that was inserted. This happens for example when inserting an QOpenGLWidget, which switches the surface type to QWindow::OpenGLSurface, or a QQuickWidget, which switches the surface type to that used for Qt Quick. In these cases, there might still be child widgets with their own window handle, and as long as these child windows have the same surface type as the window owning the backing store these child windows are flushed through the same rhiFlush() code path as the top level window. For child windows with a different surface type, QWidgetRepaintManager chooses the pain QPlatformBackingStore::flush(). Unfortunately, the implementation of QRhiBackingStore::flush() bails out when flushing child windows, so when we were using QRhiBackingStore on macOS for non-raster surfaces we would end up not flushing these child windows. The way to fix this is to use QCALayerBackingStore for the case where we know the client of the backing store (QWidgetWindow) is going to call rhiFlush() explicitly for non-raster surfaces. That will lead us into QCALayerBackingStore::flush() for the child windows with a non-matching surface type, typically QWindow::RasterSurface, and we'll flush those child windows by setting the layer's contents property. Fixes: QTBUG-119309 Pick-to: 6.7 6.6 6.5 Change-Id: Ia7052b9e651d575d8e34942a25e17ab5a1f5ce05 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* macOS: Deliver focus change events for foreign windowsTor Arne Vestbø2023-12-121-8/+2
| | | | | | | | | | If a foreign window becomes or loses focus window status, we should let QGuiApplication know about it. Pick-to: 6.7 Task-number: QTBUG-119287 Change-Id: I550d72fa13e1c38c9b89880857db9f9cbd7f6568 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* macOS: Don't reset focus window to top level window when becoming keyTor Arne Vestbø2023-12-121-9/+18
| | | | | | | | | | | | | | | | | | | | | | | | | The NSWindow becomes the "key window" when it's the window that currently receives keyboard events. This happens when switching activation between windows of the same app, or when the app is made active, restoring the key window status. Since the keyWindow property only applies to top level windows we were skipping child windows when processing the event callback, but we then proceeded to pass the top level window() to handleFocusWindowChanged, instead of the QWindow of the key window's first responder (the view that receives key input sent to the top level key window). To fix this, we let each platform window send its own focus change event, if it's the first responder, instead of relying on the top level window to send it on behalf of possible child windows. This decoupling ensures that we also send focus changes when we're not part of a view hierarchy Qt controls. Task-number: QTBUG-119287 Fixes: QTBUG-119054 Pick-to: 6.7 6.6 6.5 Change-Id: Iac06fe800291e243432335169c52db7685e173df Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* macOS: Use single truth to track file dialog current directoryTor Arne Vestbø2023-12-112-23/+22
| | | | | | | | | | | | | | | | | | | | | Unfortunately we can not rely on the file dialog panel for this, via the directoryURL property, as that property has not yet been updated during a panel:directoryDidChange: callback, resulting in the directory reported to the user being the previous directory. Since we already have to store the current directory for the case where we haven't yet created the file dialog panel we re-use this variable as the single place to store the current directory. It's not clear whether we still need to normalize the strings we get from the NSSavePanel, but the code has been left in, even if the old callback code didn't normalize the path that we then emitted as directoryEntered(). Fixes: QTBUG-119371 Pick-to: 6.7 6.5 6.6 6.2 Change-Id: I379a47053302e73d5e06a2b941f40365c17390d5 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* macOS: Handle NSNull when file dialog directories changeTor Arne Vestbø2023-12-111-1/+4
| | | | | | | | | | | For some directories, such as the 'Recents' entry in the native file dialog, the panel:directoryDidChange: callback will report a NSNull for the NSString path, which results in an exception when trying to compute the length of this null entry. Pick-to: 6.7 6.6 6.5 6.2 Change-Id: Ic9cddb54ea713b8fbdcaf0f4fb506ac96e90c9fe Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QComboBox: inform accessibility about model change before selectingVolker Hilsheimer2023-12-091-0/+11
| | | | | | | | | | | | | | | | | | | | | QComboBox implicitly selects the first item that gets inserted into the model. This happens in response to the model's rowInserted signal, at which point the item view might not have handled the rowInserted signal yet. Because of that, the view couldn't update the accessibility bridge, so informing accessibility about a row being selected that doens't exist in the bridge's representation of the table yet will result in data being out of sync, and depending on the bridge implementation trigger asserts. Fix this by explicitly updating the accessibility bridge before implicitly selecting the first row. Fixes: QTBUG-119526 Fixes: QTBUG-118585 Pick-to: 6.6 6.5 Change-Id: I2830c00751b3f18feb5d9252b23823c80229fed1 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* QIcon: turn platform engines on by defaultVolker Hilsheimer2023-12-071-4/+1
| | | | | | | | | | | | | | | | | | | | | | They are used when an icon is constructed via QIcon::fromTheme, unless an application-defined theme provides the requested icon. Update the documentation. For now we don't provide a way to "opt out". This might change, depending on the feedback during the Qt 6.7 beta phase. [ChangeLog][QtGui][QIcon] Qt now has implementations of native icon engines for macOS, iOS, Windows 10, Windows 11, and Android. These engines provide access to the native icon libraries and fonts, mapping standard icons to the corresponding native icon asset. Icons from application-defined themes take precedence, but the last-resort fallback icon passed as the second parameter into the QIcon::fromTheme(QString, QIcon) overload is only used if the icon is not available from the native library. See the QIcon documentation for details. Change-Id: I618e5c137c40f8e6309c0e4d4219a5a2759a475d Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: Deliver touch events synchronouslyTor Arne Vestbø2023-12-051-4/+16
| | | | | | | | | As a step towards a more synchronous event delivery on macOS, we enable synchronous delivery of touch events. Change-Id: I2ceda2684a973ed2a83beec624b2bab8dd073dda Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* macOS: Implement QPlatformServiceColorPicker via NSColorSamplerTor Arne Vestbø2023-12-022-0/+37
| | | | | | | | | | | | | | | | | The default behavior for QColorDialog is to use the native dialog, but for clients that implement their own color dialog we should provide the plumbing to do the actual color picking. The fallback path for this on macOS involves grabbing the screen, which brings up the permission dialog. The NSColorSampler API does not have this issue. [ChangeLog][macOS] Non native color dialogs now use native color picking when picking colors from the screen. Pick-to: 6.6 Change-Id: Idd08a90a3747546fd9825431ab7a4f5b5fa40784 Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io> Reviewed-by: Doris Verria <doris.verria@qt.io>
* Rename QWSI::handleWindowActivated to QWSI::handleFocusWindowChangedTor Arne Vestbø2023-11-232-4/+4
| | | | | | | | | | | | | | | | | | | 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>
* Add initial implementation of macOS and iOS icon theme implementationsVolker Hilsheimer2023-11-232-13/+12
| | | | | | | | | | | | | | | | | | | | | | | From macOS 13 on, AppKit provides an API to get a scalable system image from a symbolic icon name. We can map those icon names to the XDG-based icon names we support in Qt, and render the NSImage with palette-based coloring when needed, in an appropriate scale. On iOS, we can use the equivalent UIKit APIs. Coloring functionality is only available from iOS 15 on. Implement a QAppleIconEngine that does that in its scaledPixmap implementation. Use basic caching to store a single QPixmap version of the native vector image. We regenerate the pixmap whenever a different size, mode, or state is requested. Add a manual test for browsing all icons we can get from the various Qt APIs that: standard icons and pixmaps from QStyle, QPlatformTheme, and QIcon::fromTheme, in addition to showing all icon variations for a single QIcon. Task-number: QTBUG-102346 Change-Id: If5ab683ec18d140bd8700ac99b0edada980de9b4 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: Don't crash when starting a drag with empty mime dataVolker Hilsheimer2023-11-221-0/+2
| | | | | | | | | | As with all drag'n'drop code, we can't auto-test this as the test would enter a blocking event loop. Task-number: QTBUG-119216 Pick-to: 6.6 6.5 Change-Id: I7bab4a4fe7f5b315cdaec61636ded6186d9f75b4 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: Guard QCocoaWindow access when handling application activation changeTor Arne Vestbø2023-11-201-3/+4
| | | | | | | | | | | The platform window may in some cases be gone, without its NSWindow yet being deallocated, and if we receive an application activation event at this point we would try to dereference a null-pointer. Fixes: QTBUG-119219 Pick-to: 6.6 6.5 6.2 Change-Id: I72bb2482059d1a256e448705b132e4a8f22ec297 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Cocoa: implement QScreen::orientationVolker Hilsheimer2023-11-162-0/+20
| | | | | | | | | Get the rotation value from the Core Graphics API, and map it to the Qt::ScreenOrientation values. Change-Id: I9bc9f37f34e00affee15e6ce0eace70d853eab0c Reviewed-by: Doris Verria <doris.verria@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Prevent reparenting of foreign window embedding containerTor Arne Vestbø2023-11-151-1/+4
| | | | | | | | | | | A foreign window used to embed a Qt window into it should not end up with changes to its own parent, as its only job is to give the embedded Qt window a parent handle. Pick-to: 6.6 Change-Id: If1bc89658fedf449d266bc0cc750c90b6a841a68 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* macOS: Work around [NSApplication setWindowsMenu:] out of bound accessTor Arne Vestbø2023-11-151-0/+9
| | | | | | | | | | | | | | | | The implementation of [NSApplication setWindowsMenu:] seems to look for the last item in the menu, but doesn't guard the check for the menu having items. Instead it guards on another array being non-empty, and in some situation this array has items of type NSWindowMenuItem while our window menu is empty (FB13369198). To work around this we insert a hidden dummy item into the menu. Fixes: PYSIDE-2525 Pick-to: 6.5 6.6 Change-Id: Iaa9dbc9454249f4eb34f8a338d0cc23685f0025a Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* macOS: Take window mask into account when computing QCocoaScreen::topLevelAtTor Arne Vestbø2023-11-151-1/+6
| | | | | | | | | | | | | | Although not explicitly documented, this is the behavior in practice on XCB and Windows, and we rely on this behavior in our implementation of QApplication::widgetAt(), where we punch a temporary hole in the widget using a mask if it has Qt::WA_TransparentForMouseEvents set. Pick-to: 6.5 6.6 Fixes: QTBUG-41696 Task-number: QTBUG-119092 Change-Id: Ie7abc31b6930ee6b56fcdf391befc625c1ddf502 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* macOS: Always place input panels at NSPopUpMenuWindowLevel or aboveTor Arne Vestbø2023-11-151-2/+11
| | | | | | | | | | | | | | | | | | | | Implementing NSTextInputClient.windowLevel to return the level of the current input client window is not sufficient, as there may be other windows visible with a higher window level than that. For example, QCompleter's completion is shown using a Qt::Popup window, which has a NSPopUpMenuWindowLevel. Ideally we'd hide the QCompleter's completion when the IM is in the process of compositing, but as a first step, and as safeguard for other similar scenarios, we now return a minimum window level of NSPopUpMenuWindowLevel for our text input client. Fixes: QTBUG-102831 Pick-to: 6.6 6.5 6.2 Change-Id: Id74a6350595bd136027a9af470f6700ee90f52a7 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* Cocoa plugin: make sure popups' collection behavior knows about spacesTimur Pocheptsov2023-11-151-2/+3
| | | | | | | | | | | | | | | | It is possible to have several desktops on macOS, and even more - assign an app to one particular desktop. Then, moving such an app to a different desktop and using Qt's widgets like combobox may result in a strange behavior: since it's not a native 'combo button', we create a popup to show contents (list of items) of Qt's combobox and this popup may open on a 'wrong' desktop (the one to which the app is assigned to). To address this, combine the existing collection behavior for popups with NSWindowCollectionBehaviorMoveToActiveSpace. Pick-to: 6.6 6.5 Fixes: QTBUG-113507 Change-Id: Icbbc930fd1fc91089774340793e4bc452b939c1c Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Ensure foreign window can be reparented out of contained window againTor Arne Vestbø2023-11-131-4/+6
| | | | | | | | | A foreign window embedded into a Qt hierarchy must also support being removed from that window hierarchy. Pick-to: 6.6 Change-Id: Id4d08079ff19d67a8989937bc72602e8bd14b31b Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* macOS: Clarify relation between occlusion state, hidden state, and exposeTor Arne Vestbø2023-11-122-7/+23
| | | | | | Pick-to: 6.5 6.6 Change-Id: I0e05332087fb3f876a9d2fadd9d7dcfd556d5734 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* macOS: Respect QPlatformDialogHelper::ButtonLayout in native alertsTor Arne Vestbø2023-11-121-3/+49
| | | | | | | | | | | | | | | | | | | | | The buttons in QMessageDialogOptions do not have any order that we can rely on. The standard buttons is just a bit mask, so any ordering done on the QMessageBox side is lost. The custom buttons are ordered in the same order the user added them, but this is not really the order we want them to appear in the dialog either, as we have a well defined order between roles provided by QPlatformDialogHelper. We now follow the QPlatformDialogHelper::ButtonLayout order for macOS, using the same heuristics for multiple Accept role buttons as QDialogButtonBox. For buttons with the same role, QMessageBox will respect the order they were added in, but this is not something we can do for the standard buttons, as long as they are flattened to a bit mask. Pick-to: 6.6 6.5 Change-Id: I401f202a7c2d83dc253e988531ad145624c97580 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* macOS: Activate all windows on launch, not just key/main windowsTor Arne Vestbø2023-11-121-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | The default macOS behavior when an application is activated is to bring key and main windows to the front. Any window shown after that is order to the front as normal. For Qt apps we show windows in main() instead of waiting for the application to become active first, and the request to show the window may reach the window server before or after Finder has made the application active. If it arrives first, the window may end up behind the currently frontmost application. This is particularly noticeable when the application is not activated by Finder, and we do our own activation workaround. In this case all our windows are hidden, except for the key window. To ensure a consistent behavior here, we explicitly activate all windows of the application on launch. Pick-to: 6.5 6.6 Change-Id: Ice55f7d03e077c5a5ca843f75f1a7296ebb47aa7 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* macOS: Only bring application forward on launch if neededTor Arne Vestbø2023-11-121-5/+14
| | | | | | | | | | | We override the macOS default behavior of not activating applications unless they are launched from Finder. To play a bit nicer, we now try to detect if we're already the frontmost application, and skip the explicit activateIgnoringOtherApps if so. Pick-to: 6.5 6.6 Change-Id: Iff4ddc3dc50aeb9700c88882dd7a270cfea5b737 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-04 10:21:14 +0000