summaryrefslogtreecommitdiffstats
path: root/src/plugins/platforms
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* Remove unused code in qwasmcompositorMikolaj Boc2023-03-313-58/+3
| | | | | | | | Some dead code was left after transferring event support to QWasmWindow. Remove it now. Change-Id: I40e15bc62bcbb6fff071f53c45223c8a2d12e348 Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
* QWSI: Remove handleFrameStrutMouseEvent in favor of handleMouseEvent+typeTor Arne Vestbø2023-03-314-24/+13
| | | | | | | | | | | | | | | 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>
* iOS: request authorization before presenting image-pickerTimur Pocheptsov2023-03-283-3/+43
| | | | | | | | | | | | | | | | | | | | | | | Right now, image picker view is shown first (it does not require access to photos, since it's essentially Photos app getting access to photos ...). Then, we use AssetsLibrary to get asset for an url (using ALAssetsLibrarie's -assetForURL method). This may trigger a permission-related alert, asking to: a. Select more photos or ... b. Allow access to all photos or ... c. Deny access. Showing this alert _after_ picker has selected an image makes little sense (and probably was never intended this way anyway). Instead, we now use Photos.framework to check the authorization and, if needed, we request an authorization (when the current status is 'Nondetermined'). If authorization is 'Granted' as a result, we show picker view and proceed as normal/before. Pick-to: 6.5 Task-number: QTBUG-109120 Change-Id: I0acfd7b0476346360d75a5e37f5845aaf2d6e3e0 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Windows: Send synthetic mouse release after move/resize using right APITor Arne Vestbø2023-03-281-3/+7
| | | | | | | | | | | | | | | | | | | The end of a move or resize might happen with the mouse still inside the non-client area of the window, in which case we correctly resolved the type to QEvent::NonClientAreaMouseButtonRelease, but we sent it via QWindowSystemInterface::handleMouseEvent, which sets nonClientArea of the event to false. This in turn resulted in QGuiApplication sending a synthetic QEvent::MouseMove in case the position was out of sync, instead of the correct QEvent::NonClientAreaMouseMove. This should really be cleaned up on the QWSI level, as there is no reason to have a dedicated API for handleFrameStrutMouseEvent, when handleMouseEvent already takes an event type, but for now we fix the immediate issue in the Windows platform plugin. Pick-to: 6.5 6.2 Change-Id: I8a831f5f19adb0625b29b50ebce9c0c6514e93f3 Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* Stop propagation and default action on WASM window pointer eventMikolaj Boc2023-03-281-2/+3
| | | | | | | | | | | | | | | | The windows should not let events through to targets below (unless they are Qt::WindowTransparentForInput, which is handled independently). Therefore, stopPropagation and preventDefault are now called regardless of whether the window has handled the event or not. If the event is not handled explicitly, we still consume the DOM event so that the windows/elements below don't get focus by mistake. Fixes: QTBUG-111706 Change-Id: Idc78ac5076e97992d9f6f13a1fa574d0df4178ac Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io> Reviewed-by: Aleksandr Reviakin <aleksandr.reviakin@qt.io> Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* Pick up initial state of foreign windows instead of reflecting QWindowTor Arne Vestbø2023-03-281-12/+18
| | | | | | | | | | | | | | A foreign window can be used both for embedding a Qt window into a native window hierarchy, or for embedding a native window into a Qt window hierarchy. In the former case, we should not modify the foreign window in any way. Since the platform does not know anything about the intended use case at the time of the foreign window creation, it should avoid modifying the foreign window in any way, and should instead pick up the foreign window state and reflect that through QWindow. Pick-to: 6.5 Change-Id: Id2e39d101277ecebd656d615cea3e7f734a4b0a6 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* macOS: Don't try to create or manage NSWindow of foreign windowsTor Arne Vestbø2023-03-281-0/+8
| | | | | | | | | | | A foreign window is a single NSView, and unlike our QNSView, where we in addition manage a NSWindow for top level windows we should treat the foreign window as just an NSView. It's not our place to neither create nor dispose of any NSWindows attached to the foreign window. Pick-to: 6.5 Change-Id: I88aa796c679be0489abf4999829d1378ba054bdc Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* Remove the redundant QWasmCompositor::requestUpdateAllWindowsMikolaj Boc2023-03-283-35/+13
| | | | | | | | | | | | | | | | Now that the browser compositor is used for rendering windows, the method has become redundant, as windows that got resized during screen resize will schedule their updates directly with the compositor. This also fixes an assertion in QPlatformWindow::hasPendingUpdateRequest as no windows without pending update requests will now have update requests delivered. Also offers a significant speedup with multiple restored window setups. Fixes: QTBUG-112289 Change-Id: Ie5dff69c04d66c4aef8351adef0da8530daf7ab8 Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
* macOS: Simplify child window parenting in recreateWindowIfNeeded()Tor Arne Vestbø2023-03-281-3/+1
| | | | | | | | | The logic for this should ideally be handled in setParent(), but for now let's clean up the code a tiny bit. Pick-to: 6.5 Change-Id: Id2370d6704625038ab6b4fa246dea5d1c037371c Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* macOS: Create NSView as initially hidden, to match QWindow behaviorTor Arne Vestbø2023-03-282-10/+12
| | | | | | | | | | | | | | | | | Initially attempted in 096b56f336e5bb994d46f073d55496d36d38e6b1, but that broke QQuickWindow::grabWindow(), which at the time was not prepared for grabbing non-visible windows. This is no longer an issue, as QQuickWindow::grabWindow() has fallback logic for non-renderable windows. QWidget::grab() also works fine, as it grabs from the backingstore directly. For top level windows we apply the visibility state to both the NSWindow (orderIn/Out), and to the NSView (hidden=YES/NO). Pick-to: 6.5 Change-Id: I617b292ca6bfba66e65b55941c5b002e415da88d Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Windows: Don't send non-client mouse events unless frameStrutEventsEnabledTor Arne Vestbø2023-03-281-2/+6
| | | | | | | | | | During refactoring in 38504041148f2d1cffea6520ea448dd4171adb0b the logic was changed in a way that ended up sending non-client mouse events even if frameStrutEventsEnabled() was not set on the platform window. Pick-to: 6.5 6.2 Change-Id: Icbde51641020aeec99572d80859082fdcf656311 Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* macOS: Apply QWindow properties to NSWindow when setting content viewTor Arne Vestbø2023-03-282-9/+23
| | | | | | | | | | | | | | | | | | | | | The main responsibility of QCocoaWindow::recreateWindowIfNeeded() is to decide if the platform window is top level or not, and if so needs an NSWindow or NSPanel accompanying it. Once that decision has been made, and we've created an NSWindow or NSPanel, and made the view the content view of this window, we need to apply the QWindow properties to the newly created NSWindow or NSPanel. But doing so in recreateWindowIfNeeded increases the complexity and responsibilities of the function, so we move the logic to [QNSWindow setContentView:] instead. This is analogous to applying the properties during [QNSWindow init], but since we are now the content view we can use the same code paths to apply the initial properties as we use when they are updated later on. Pick-to: 6.5 Change-Id: Idb4c812f4b22a029030bf4638357cf8628caea40 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* macOS: Skip DisplayLink updates when in live resizeLaszlo Agocs2023-03-231-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...and the view is using a CAMetalLayer and a non-default contents placement. (the default would be scaling/stretching of the content, that hides a lot of out-of-sync size problems during resize, but is not great for UIs so we never use that in practice) This achieves two things: - when presenting from the main thread with transactions (i.e. with parent patch in place), resizing the window will be even nicer, basically flicker free on the M1 Mini as well, - when presenting from outside the main thread, resizing becomes a lot smoother, even if the window background is still visible from time to time due to the size not catching up and due to Qt having to use NSViewLayerContentsPlacementTopLeft. Thus resizing Qt Quick-based windows, which use the threaded render loop by default and cannot use presentsWithTransaction, becomes a nicer experience than before, even if not always perfect. This comes at the expense of not animating during the live resize operation whenever the size is not changed (because only a resize triggers updates then, the CVDisplayLink-based updates are skipped in order to reduce flicker due to out of sync sizes) To force the old behavior, set QT_MAC_DISPLAY_LINK_UPDATE_IN_RESIZE. Task-number: QTBUG-107198 Change-Id: I796c3a74119510c62f7245b0ebbe78797d2df03e Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* wasm: add support for input languages win32 mobileLorn Potter2023-03-231-16/+18
| | | | | | | | | | | on Windows virtual keyboard sends characters through the textInput handler, we can use the same mechanism as Android to create an offscreen input element and send the characters from there. Fixes: QTBUG-107139 Pick-to: 6.5 Change-Id: I84a143aedf93d22521fcfa368532eed8c0e7d002 Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
* Close popups on WASM window non-client area interactionsMikolaj Boc2023-03-231-0/+1
| | | | | | | | | This mimics the behavior displayed by the Cocoa window Fixes: QTBUG-111436 Change-Id: I800fd15e870e54cf2c22ba5bd7f0c8b3f7f85bbf Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io> Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
* Windows QPA: Change handling of maximised frame/title-less windowsTimothée Keller2023-03-223-34/+37
| | | | | | | | | | | | | | So far, the framele/tite-less window maximising has been done by adjusting the MINMAXINFO to prevent them from covering the taskbar. It does not work when moving the windows from one screen to another using keyboard shortcuts, since the MINMAXINFO is that of the old monitor. This moves the adjustment to the WM_SIZE message that occurs after the window has been resized. Pick-to: 6.5 6.4 6.2 Change-Id: I0d36fe5d2e8eaa0739414835b8d99a0b2ed44cf6 Reviewed-by: Yuhang Zhao <yuhangzhao@deepin.org> Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* xcb: Delete QInputDevice instances that X11 no longer findsShawn Rutledge2023-03-211-22/+60
| | | | | | | | | | | | | | | | | | | | | | | | QXcbConnection::xi2HandleHierarchyEvent() calls xi2SetupDevices() whenever the event tells us that a device was added or removed; but until now, those instances were not getting deleted until application exit. That was a memory leak, and also tended to get us confused when a newly-attached device happened to reuse the same device ID of something that was there before but had been removed in the meantime. Now, we hope that QInputDevice::devices() will be in sync with reality as X11 presents it to us. Amends da5dea807f497bc6004f40e966e5d882a2ba72b0 6589f2ed0cf78c9b8a5bdffcdc458dc40a974c60 etc. Task-number: QTBUG-46412 Fixes: QTBUG-56214 Fixes: QTBUG-98720 Fixes: QTBUG-99331 Task-number: QTBUG-104878 Fixes: QTBUG-112141 Pick-to: 6.2 6.5 6.5.0 Change-Id: I573805a41a12850f94561a030071f1437c4dc37e Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* macOS: Disable interaction for modally blocked transient parent windowsTor Arne Vestbø2023-03-202-4/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a window-modal window has a transient ancestor, Qt treats this ancestor window as modally blocked by the modal window, as if it had been a true non-transient parent of the modal window. Unfortunately, this is not how macOS natively behaves. Window-modal windows only block their direct parent, and AppKit will happily send events to any other top level window. This is different from how application modal windows work, where NSApplication will filter many events (but not all) in [[NSApplication _modalSession:sendEvent:]. Note that NSWindow.worksWhenModal has no effect in this situation, as that property is only considered by AppKit for application modal session are active (and NSApp.modalWidow returns non-nil). Instead of trying to replicate the event filtering that AppKit does, which would be fragile, we disable some of the effects these events could potentially have, by for example preventing modally blocked windows from becoming key, and temporarily disabling the close button in the title bar. One remaining issue is that, unlike with application modal windows, the modally blocked transient parents can still be ordered above the modal window. Fixing this requires informing the window server about the modally blocked state of the window, which we can't do using public APIs. Even returning NO from [NSWindow _allowsOrdering] is not sufficient. Task-number: QTBUG-104905 Pick-to: 6.5 Change-Id: I7e764a354f397ae6ef61304ca5442a4e1bb7589c Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* macOS: Bail out if handling cut/copy/paste action from non-Qt NSMenuItemTor Arne Vestbø2023-03-201-3/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The typical way to set up menus on macOS, which we follow, is to create NSMenuItems with an action selector set (copy:), but without a target. This will result in AppKit finding a target dynamically, starting with the first responder, walking the responder chain, and then moving on to other NSWindows, before ending up in the NSApplication and its delegate. Unfortunately, we don't have a mechanism in Qt to forward generic actions, such as the cut/copy/paste, or selectAll, so we rely on mapping the actions back to QCocoaNSMenuItem that we can trace back to a QPlatformMenuItem that we in turn emit activated() for. Normally this works fine, but in the case where the Qt app is embedded in a native UI, which has its own menu items with cut/copy/paste, we'll get callbacks into QNSView for actions triggered by a generic NSMenuItem. In that case, we need to bail out, but we must do so without calling [super forwardInvocation:invocation], as that will just try to invoke the action on ourselves again. It's unfortunately too late to try to redirect the action to another responder, that might have handled the action, and it's questionable whether that would be the behavior we'd want, as that would possibly result in e.g. pasting text into another window than the Qt one that currently has an active cursor in a text entry. Fixes: QTBUG-111916 Pick-to: 6.5 Change-Id: I56318e4f7efd779cd20bf577aec8c2de04a6a142 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* macOS: Add logging category for menu machineryTor Arne Vestbø2023-03-208-27/+27
| | | | | | | | The machinery is quit fragile, so any logging will help here. Pick-to: 6.5 Change-Id: I1906c0e33b4afbf649a20bfe2aa7210b6822087e Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Wasm: Fix displaying frameless QWasmWindow with transparent contentPiotr Wierciński2023-03-203-8/+20
| | | | | | | | | | | | | | | | | | Currently we render shadow and default background-color even for frameless windows with transparent content. This behavior is not consistent comparing to other platforms. An example of such window is InputSelectionHandle from VirtualKeyboard module. This commit disables shadow-box and provides transparent background-color for QWasmWindow which are frameless. It also provides distinction between "frame" as logic property of window and "border" as visual decoration. Change-Id: I902692ea561a2e88e2e6ab7faad8e3eeb536a26b Reviewed-by: Aleksandr Reviakin <aleksandr.reviakin@qt.io> Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
* Revert "QCocoaMenuBar: avoid duplication of 'special' entries in the 'Edit' ↵Timur Pocheptsov2023-03-171-16/+12
| | | | | | | | | | | | | | | | menu" This reverts commit 6c2387571a6ccace9edb600ce6798f75affd961d. Caused a regression when the edit menu did not have any entries from the system. Fixing that regression (out of bound index, crash), revealed that the original patch is simply not working anymore - items are still duplicated anyway. Fixes: QTBUG-111798 Pick-to: 6.5 Change-Id: Id4a88f30e2cf300bc63181c4bc7aa113a8b13ac6 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Handle device loss for texture widgetsDavid Redondo2023-03-171-2/+4
| | | | | | | | | | | | Previously the widget stayed black and we printed "QBackingStoreDefaultCompositor: the QRhi has changed unexpectedly, this should not happen". To make it work the compositor is recreated in addition to the rhi and the widgets are informed with the internal events. Change-Id: I982d08bd3530478fe0f827080154c008a92a812e Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Fix compilation issues for androidMichal Klocek2023-03-162-0/+8
| | | | | | | | | | Deals with: * unknown class name 'Object'; did you mean 'QObject'? * use of undeclared identifier 'QTimer'; did you mean 'QTime'? Pick-to: 6.5 Change-Id: Id63064e70090ed1f816fa19db047b382220d634c Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
* Wasm: Hide "Enable screen reader" button in QWasmWindowPiotr Wierciński2023-03-152-4/+16
| | | | | | | | | | | | | | | For each QWasmWindow, there is "Enable screeen reader" button added for accessibility. It's hidden visually by z-ordering behind main QWasmWindow div. Sometimes the content of QWasmWindow contains transparent elements and the underlying accessibility button gets visible. This commit introduces new CSS class which hides elements visually, but keeps it accessible for screen readers. Fixes: QTBUG-111896 Change-Id: I78ef5746da9e0d1584ee36dd0ca6ba476623a3de Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io> Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* Wasm: Add support for setOpacity() in QWasmWindowPiotr Wierciński2023-03-142-0/+6
| | | | | | | Add support for QPlatformWindow::setOpacity() in QWasmWindow. Change-Id: Ib54cecf1f49e3d576a386f4109b8c6df1f16f312 Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
* wasm: restore windowCursor nullptr checkMorten Sørvig2023-03-141-4/+3
| | | | | | | | | | This check was accidentally removed in commit 783b63ce. If the cursor is null, set the default cursor. Pick-to: 6.5 6.5.0 Change-Id: I894d5e04cd7b49041bd0d3b59fc816a8b7efffe7 Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
* Utilize NO_UNITY_BUILD arguments instead of manual exclusionAmir Masoud Abdol2023-03-144-8/+4
| | | | | | | | | | | Unity build is disabled by default for all 3rdparty libraries, so we don't need to set the manually anymore; and for the plugins we can use NO_UNITY_BUILD instead. Pick-to: 6.5 Task-number: QTBUG-109394 Change-Id: Ia2f83ae083924d31adf07e7647b34ae6571ed01f Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* macOS: Remove workaround for worksWhenModal not being reevaluatedTor Arne Vestbø2023-03-131-39/+0
| | | | | | | | | | | | | | On macOS < 10.15 the worksWhenModal property of our NSWindow was read on window initialization and propagated to the window server, but never updated on the window server past that point, even if updating the worksWhenModal property on the NSWindow. Now that we no longer support macOS < 10.15, we can remove the workaround, that was using private APIs to talk to the window server directly. Pick-to: 6.5 Change-Id: Ide5a6d63cc471fd04748d1aa7f7915ccde2a1cdc Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* macOS: Guard text input client from destroyed QCocoaWindowTor Arne Vestbø2023-03-132-13/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | The text input system on macOS may in some cases hold references to our QNSView, even after we've destroyed the corresponding QCocoaWindow. This happens e.g. when using the Keyboard Viewer to input text into a dialog, and then closing the dialog. In this situation we get text input callbacks such as selectedRange, attributedSubstringForProposedRange, firstRectForCharacterRange, and need to account for the lack of a valid platform window. This happens even if NSTextInputContext.currentInputContext has been updated to the input context of the parent window, and even if we explicitly deactivate the old input context and return nil for the input context of the now QCocoaWindow-less QNSView. We can combine this situation with the handling of a missing focus object, so that each callback doesn't need explicit platform window checks. Fixes: QTBUG-106369 Fixes: QTBUG-111183 Fixes: QTBUG-105250 Pick-to: 6.5 6.2 5.15 Change-Id: I5bc1b9667376c87221fe5007db162224c022c09f Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Reuse the existing canvas context for offscreen surfacesMikolaj Boc2023-03-122-29/+60
| | | | | | | | | | | | | Due to the nature of WebGL contexts, which cannot be reassigned to targets other than they were created for, we will now reuse the created canvas context for offscreen surfaces, since those (hopefully) mostly operate on textures anyway. If this is not done, any switch to an offscreen surface for the main RHI context invalidates resources on contexts in a share group with it. Fixes: QTBUG-111617 Change-Id: I9752f7eec396a3ef11414881f5f79f26e1e2c859 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* QObject: implement startTimer(int) in terms of startTimer(chrono)Ahmad Samir2023-03-113-4/+4
| | | | | | | | | | I.e. use chrono first, this means the API isn't limited by the size of int, but by the size of whatever chrono::milliseconds uses (typically int64_t), and chrono units are much more readable as well. Task-number: QTBUG-110059 Change-Id: Ie7f2d90864782361a89866693011803be6f8545e Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Windows: initialize COM in internal threadVolker Hilsheimer2023-03-091-0/+2
| | | | | | | | | The QWindowsDialogThread uses COM APIs, so we need to initialize COM. Task-number: QTBUG-111625 Pick-to: 6.5 6.2 Change-Id: Ief136ee70671034cb8996ab2f5b113e3884d2953 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Plumb QMessageBox::setCheckBox() through QPlatformMessageDialogHelperTor Arne Vestbø2023-03-093-4/+31
| | | | | | | | | | | | | | | | | | | | | | | Without this plumbing we have no way of knowing if the QMessageBox has a checkbox set, and can't decide to skip the native dialog, leaving the user without the expected checkbox. As the suppression checkbox on macOS can be customized, we can use this plumbing to actually provide native dialog support for generic check boxes. This mechanism can also be used by QErrorMessage, which now matches behavior between native and non-native dialogs in terms of the label of the checkbox and its initial state. We might want to tweak this in the future, since user's might expect the suppression label and state to match the system default, but that's something we can expose from the platform theme if so, and should apply equally to the non-native dialog. Fixes: QTBUG-111803 Pick-to: 6.5.0 6.5 Change-Id: Ied9fc34383fe79fbd8437592ad1c1993b9396178 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* macOS: Remove content border thickness members from QCocoaWindowTor Arne Vestbø2023-03-082-4/+2
| | | | | | | | | They were only set by QCocoaWindow::setContentBorderThickness(), which was removed in 19fc78e9672f4350a06790a9a0f0edba75244875. Pick-to: 6.5 Change-Id: Ia1b429c56c9627506023b76bddf878a4321d5f0b Reviewed-by: Doris Verria <doris.verria@qt.io>
* macOS: Class initialize QCocoaWindow membersTor Arne Vestbø2023-03-082-34/+18
| | | | | | Pick-to: 6.5 Change-Id: I76e107b676ce27526094f851ec23bb544689e32f Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* macOS: Move setMask call out of recreateWindowIfNeededTor Arne Vestbø2023-03-081-2/+2
| | | | | | | | | It semantically applies during platform window initialization, and doesn't depend on the logic of choosing an appropriate NSWindow class. Pick-to: 6.5 Change-Id: Ia24a2deafc78ed4c79df766b6372ad64de2d0dde Reviewed-by: Doris Verria <doris.verria@qt.io>
* macOS: Don't set opacity on non-top level windows during NSWindow creationTor Arne Vestbø2023-03-081-4/+1
| | | | | | | | | | | | | | The opacity is a property of NSWindow. There's no point in pulling out the opacity from QWindowPrivate, as QWindow has a public accessor for it. And we don't need to guard the call with a check for non-1.0 opacity. If we want logic to avoid redundant calls to the platform APIs, they should be in the setter. Pick-to: 6.5 Change-Id: Ic9b8d1051f30d3b7e09dae14b9f22ca899d05865 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* macOS: Use non-native app modal message box from nested event loopsTor Arne Vestbø2023-03-071-0/+5
| | | | | | | | | | | The NSAlert does not stay open when ran from a nested event loop, so we need to fall back to the cross platform dialog. The window modal dialog does not have this issue. Fixes: QTBUG-111524 Pick-to: 6.5 6.5.0 Change-Id: I63fba0a092018bb19edeef78c06587455d752235 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* Wasm: Hide resizing divs when the window is not resizablePiotr Wierciński2023-03-074-18/+55
| | | | | | | | | Hide divs that are responsible for resizing the window and changing the appearance of the cursor on this window if this window is not resizable. Fixes: QTBUG-111618 Change-Id: I1948eaedf02fdd2a5289ae314521b3fd74ad7811 Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
* wasm: fix respecting minimum size of QWasmWindowPiotr Wierciński2023-03-052-6/+11
| | | | | | | | | | | Minimum size of QWasmWindow was not properly enforced. Make sure that minimumu size constraints are respected when the QWasmWindow is created, resized manually or changed by setGeometry(). Fixes: QTBUG-111162 Change-Id: I2984b0836b5b53f9163275153d734cb1d81ef3b6 Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
* xcb: ignore the xscreens which don't belong to current connectionLiang Qi2023-03-031-12/+12
| | | | | | | | | | | | | | | | This amends 9a4c98e55659b32db984612e6247ac193812a502. When a X server has multiple xscreens, for example, ":0.0" and ":0.1", a Qt application, which uses ":0.1" as display, can't use the randr monitor from other connection(":0.0") to show contents there. Then we don't need to generate QXcbScreen for them. Pick-to: 6.4 6.5 Fixes: QTBUG-110898 Change-Id: I04c1512664b763ffabb55b75db4411d100536255 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: JiDe Zhang <zhangjide@uniontech.com> Reviewed-by: Liang Qi <liang.qi@qt.io>
* macOS: Send a filename QFileOpenEvent if invalid URL, deprecate openFileVolker Hilsheimer2023-03-021-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | When the string we receive from the system doesn't parse into a valid QUrl (because QUrl requires a valid IDN), then we shouldn't send the QFileOpenEvent based on that invalid QUrl, but instead pass the string through as the file name. The file name is anyway not guaranteed to be path to a file that can be opened, as per the existence of QFileOpenEvent::open and the repective documentation stating: "some files cannot be opened by name, but require specific information stored in this event." However, that API is not useful at all, the implementation just opens the passed-in QFile, using the stored file name. There's no way to override this, and QFileOpenEvent is a locked class with all data stored inline. So we can't even redirect to a platform-implementation. Deprecate that function. Applications should interpret the string returned by file(), which might not be a path to a local file. Fixes: QTBUG-98384 Change-Id: Iff75489de9d7c5fc034f44c0bda4963b2efb1925 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* iOS: Respect QSurfaceFormat::colorSpace() when using MetalTor Arne Vestbø2023-03-021-0/+11
| | | | | | | | | | | | | | Unlike on macOS, there's no colorSpace property on UIWindow or UIView, but CAMetalLayer has one, which allows us to tell Core Animation that the layer targets a specific color space, and Core Animation will then do the rest of the color matching to the target display. Now that we use Metal to flush raster content, this is even more useful. Task-number: QTBUG-108094 Pick-to: 6.5 Change-Id: Ib04b42d9baa296b608983db38faf0398430db093 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* Rely on Windows to generate CF_TEXT when active code page is UTF-8Ilya Fedin2023-03-011-2/+3
| | | | | | | | | | | | | | | | | | It's possible since Windows 10 1903 to set the active code page to UTF-8 using the manifest. In that mode, QString::toLocal8Bit converts to UTF-8 and the legacy programs not using UTF-8 codepage can't interpret the value. We can detect whether the UTF-8 code page is used, and in that case only provide data as CF_UNICODETEXT. Windows will then synthesize the CF_TEXT format when the clipboard data is consumed, using the right code page for the target application. https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page Pick-to: 6.5 6.4 6.2 Change-Id: Ie024a618556d9bb5b5c7ac70507d279b959ff6db Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Add API in QWindowsPrivate to provide window paletteSanthosh Kumar2023-02-281-3/+5
| | | | | | | | | | | | | | | | The window uses default palette (QPalette()) to determine frame color (either light or dark). This doesn't work for quickcontrols as they depend quicktheme palettes and they don't overwrite default palettes. This patch add API in QWindowPrivate to provide palette for window and this can be overridden by quickcontrol windows to provide their corresponding palette. Fixes: QTBUG-111491 Pick-to: 6.5 Change-Id: I39eea20ee7c61ecf0279143c9784da35be15edd3 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Windows drag&drop: Use correct window for drag target processingOliver Wolff2023-02-271-1/+2
| | | | | | | | | | | | | | GetFocus will return the window that currently has keyboard focus. This is not what we want for drag and drop handling though. Use the window under mouse and process events for that window when doing the touch/pen input workaround. If no window is found we fall back to the focus window. Followup to 31e7790102b260344893eaa8bf8b7b1a0f95e3b7 Fixes: QTBUG-111149 Pick-to: 6.5 6.4 6.2 Change-Id: Ib8233debc267df0cc19b21c1dc5c6881d018d84a Reviewed-by: Timothée Keller <timothee.keller@qt.io> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Android: use FileProvider with QDesktopServices::openUrl()Assam Boudjelthia2023-02-241-6/+34
| | | | | | | | | | | | | | | | | Allow openUrl() to use FileProvider for opening files that are located under app scoped paths and that use a file scheme for Android sdk 24 or above. [ChangeLog][Core][Android] Add FileProvider support for QDesktopServices::openUrl(). [ChangeLog][Core][Android] Add AndroidX dependency to Gradle builds by default since it's required by FileProvider. Fixes: QTBUG-85238 Change-Id: Ia7403f74f2a8fd4886f74dba72e42b318ef5d079 Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com> Reviewed-by: Nicholas Bennett <nicholas.bennett@qt.io> Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
* wasm: Fix checking window flags in QWasmWindowPiotr Wierciński2023-02-231-2/+2
| | | | | | | | | Querying bit flags by direct comparison yields incorrect results. As an effect the minimum size for QWasmWindow is not always properly set. Use testFlags() function instead. Change-Id: Ie4cf528ed3c6f664abd17615a6898e8fc49d84b5 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-13 15:33:53 +0000