summaryrefslogtreecommitdiffstats
path: root/src/plugins/platforms
Commit message (Collapse)AuthorAgeFilesLines
...
* macOS: lower the splash screen when a modal dialog blocks itVolker Hilsheimer2019-06-261-0/+19
| | | | | | | | | | | | | | This fixes the usability issue of a modal dialog showing up behind a splash screen, not visible to the user, but blocking user input and the application startup sequence until discarded. [ChangeLog][QtWidgets][QSlashScreen] On macOS, lower the splash screen when a modal dialog is shown to make sure the user sees the dialog. Change-Id: Ibae768f76909d930cb25dcf5cee31edc5f15c29a Fixes: QTBUG-49576 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Android: Use Android button layout for the DialogButtonBoxLayout hintAndy Shaw2019-06-181-0/+2
| | | | | | | | Fixes: QTBUG-70045 Change-Id: I9c51e9a769f510a6f14f6e9d78583caf3df15031 Reviewed-by: BogDan Vatra <bogdan@kdab.com>
* NSMenuItem/NSMenu - set the submenu properlyTimur Pocheptsov2019-06-214-0/+24
| | | | | | | | | | | | | | | | | | ... in case the submenu is set from a slot, attached to the aboutToShow() signal. Normally, with a 'statically' pre-populated menu, we set 'submenu' property on a menu item from 'updateItem' callback in our menu delegate. After that, AppKit calls our delegate's willOpen call back and this is where we emit 'aboutToShow'. Unfortunately, if an application tries to create a nested menu 'dynamically' at this point, it never becomes 'submenu' of the item, since 'updateItem' was already handled at this point. We catch this case in QCocoaMenuItem and call setAttachedItem if needed. Fixes: QTBUG-76060 Change-Id: I676bf1d8529b9ddbfc90e4dff422b39668b7a5fa Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Use Xft DPI as basis for HiDPI scalingAllan Sandfeld Jensen2019-06-192-5/+16
| | | | | | | | | | | | | GNOME indicates DPI modes by setting high DPI values in Xft.DPI, so we need to use the forced DPI setting instead of the real DPI, as basis for QPA pixel density. Change-Id: I6f25636383b16b89a3d5fe4c904afd079fe001aa Fixes: QTBUG-74836 Task-number: QTBUG-65424 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* macOS: prevent duplicate backing store scalingMorten Johan Sørvig2019-06-191-2/+3
| | | | | | | | | | | | | | m_requestedSize is already scaled by the QtGui scale factor (e.g. as set by QT_SCALE_FACTOR). Multiplying by QWindow::devicePixelRatio() then applies this factor again. Use QPlatformWindow::devicePixelRatio() instead, which returns the platform scale factor. Change-Id: I133e99d84f4718215fda9ef0cf81a113b51db2c7 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: Invalidate window shadow after QNSWindowBackingStore resizeTor Arne Vestbø2019-06-183-10/+30
| | | | | | | | | | | The window shadow rendered by AppKit is based on the shape/content of the NSWindow surface. If the backingstore is partially transparent, we need to invalidate the window shadow after each resize (and subsequent flush) of the backingstore. Change-Id: I451370af5a8c0c25faea26beb3faa2483a33a5cf Fixes: QTBUG-74560 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* Windows: Use UUIDs instead of function pointer to mangle window classesTim Blechmann2019-06-181-2/+3
| | | | | | | | | | | Instead of using the address of a function pointer, we name-mangle window classes by using an UUID. This fixes a real-world problem with multiple Qt instances where for some reasons the window function appears to be mapped to the same address. Change-Id: Id27e8d7aa17a4db9c14559224395f49d3ecd8d78 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* iOS Accessibility: implement accessibilityElements and check indexingFrederik Gladhorn2019-05-211-0/+8
| | | | | | Fixes: QTBUG-70683 Change-Id: I122c67a5cee22363de5c8e45dc1c83e7760162fb Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Cocoa: always send queued user input eventsMorten Johan Sørvig2019-03-212-10/+22
| | | | | | | | | | | | | | | | | | | | | | | | | User input events will be queued if processEvents() is called with the ExcludeUserInputEvents flag. User code then expect that the queued events will be sent when the corresponding exec() call returns. We were sending queued user input event at the beginning of processEvents(). However, the cocoa event dispatcher also has a mode where it makes a blocking call to [NSApp run], in which case processEvents() never returns during event processing. This means we don’t get to call the queued-event-sending code. Factor out the queued-event-sending code to a new sendQueuedUserInputEvents() function. Call it from postedEventsSourceCallback() to make sure the queue is emptied after the ExcludeUserInputEvents processEvents() call is done. Task-number: QTBUG-69687 Change-Id: I4ff554ef4d39a69356736c33a650886b56bfdb4c Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* QAndroidInputContext: Improve compatibility with virtual keyboardsVova Mshanetskiy2019-06-052-202/+430
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit improves QAndroidInputContext's conformance to Android's InputConnection interface and/or consistency of it's behavior with Android's native EditText control. * Composing region is now completely independent from cursor and selection, as required by InputConnection documentation. Also, Qt will now never clear composing region (i.e. call finishComposingText()) without receiving a command to do so from the keyboard. This is important for the following reasons: - Some keyboards misbehave if we change composing region without receiving a command from them. Notably, Samsung Keyboard does (QTBUG-68822). - Due to asynchronous nature of interaction between QAndroidInputContext and the keyboard, when user drags cursor handle quickly, the keyboard may call setComposingRegion() to mark a word, which is no longer under the cursor. This was causing text corruption (QTBUG-43156, QTBUG-59958). Also SwiftKey makes such calls when user presses Enter key (QTBUG-57819). - For similar reasons selecting a word with a double-tap could cause text corruption. The keyboard may call setComposingRegion() in response to the first tap after the second tap has been processed and the word has already been already selected. This is achieved by keeping track of start and end of composing region independently from the editor. Whenever possible (i.e. when there is no selection and the cursor is inside composing region), the composing text is represented as preedit text inside editor. And whenever that is imposible, the editor is told to commit, but QAndroidInputContext keeps information about composing region internally to be able to correctly interract with the keyboard. * deleteSurroundingText() has been re-written to work correctly when there are selection and/or composing region. Some keyboards (e.g Ginger Keyboard) do call deleteSurroundingText() when there is non-empty composing region. * All operations are now performed inside a batch edit (i.e. QAndroidInputContext now calls beginBatchEdit() and endBatchEdit() on itself) to ensure that an intermediate state is never reported to the keyboard, whenever an operation requires more than one QInputMethodEvent. BatchEditLock helper class was added to call begin/endBatchEdit() in RAII style. m_blockUpdateSelection has been removed because m_batchEditNestingLevel is now used instead of it. * Selection start and end positions are now reported to the keyboard so that start <= end. Some keyboards can not handle start > end. * getTextBefore/AfterCursor() now exclude selected text from their return values. While Android docs say "text before/after cursor", what they really mean is "text before/after selection" because "the cursor and the selection are one and the same thing". Some keyboards (e.g. Gboard) were behaving incorrectly when selected text was being returned. * getExtractedText() now tries to obtain and return the whole text from the editor. This is to fix compatibility with some buggy keyboards (e.g. Samsung Keyboard, Minuum) that ignore startOffset field and assume that selectionStart and selectionEnd are absolute values. Then they issue commands with wrong indexes in some cases. Fixes: QTBUG-43156 Fixes: QTBUG-59958 Fixes: QTBUG-57819 Fixes: QTBUG-68822 Change-Id: I7e71f3bcfbb2c32248d653a4197293db03579a79 Reviewed-by: BogDan Vatra <bogdan@kdab.com>
* QAndroidInputContext: Don't allow clearing selection by dragging handlesVova Mshanetskiy2019-06-051-39/+27
| | | | | | | | | Android's native text editing controls do not allow user to clear selection by dragging selection handles. Qt apps should behave in the same way. Change-Id: I9a7c3a2aafa484eed8ff2bbd46dd48c705195291 Reviewed-by: BogDan Vatra <bogdan@kdab.com>
* QAndroidInputContext: Fix unneeded preedit commits when dragging handlesVova Mshanetskiy2019-06-051-11/+52
| | | | | | | | | | | | | | | | | | | If the cursor handle was dragged by only a few pixels, position of the cursor did not actually change, but finishComposingText() was called anyway. So the keyboard was thinking that nothing changed and a word is still being composed, but the app was thinking that there is no preedit string. This was resulting in invalid handling of following key presses. This commit essentially inlines QPlatformInputContext::setSelectionOnFocusObject() into QAndroidInputContext::handleLocationChanged(). This allows us to call finishComposingText() and to send a QInputMethodEvent only when position of the cursur actually changes. This also allows us to add a QInputMethodEvent::Cursor attribute into the event for consistency with QAndroidInputContext::longPress(). Change-Id: I2fc82f138f717991f34024cdf521236845dc0adf Reviewed-by: BogDan Vatra <bogdan@kdab.com>
* Track swap interval in QXcbWindowErik Kurzinger2019-06-133-4/+7
| | | | | | | | | | | | | | | | | | As per GLX_EXT_swap_control, the GLX swap interval is specified on a per-drawable basis. However, QGLXContext only tracks it per-context using the m_swapInterval member. If a new drawable is made current to a context, it is still necessary to call glXSwapIntervalEXT to change the swap interval, even if it has been previously called for the same context with a different drawable. However, currently, QGLXContext::makeCurrent doesn't do this if its m_swapInterval field matches the new swap interval. This change removes m_swapInterval from QGLXContext, instead tracking it in QXcbWindow. This still avoids unnecessary calls to glXSwapIntervalEXT, while ensuring the swap interval is always set for new window drawables. Change-Id: Idc34101476c6af618059f6f3d8925dee743994a3 Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Windows: Call ReleaseDC for the private's displayContextAndy Shaw2019-04-101-0/+2
| | | | | Change-Id: Ib5ee1bbe9037ceb13562eadb754c2a5f095b7f87 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* macOS: Introduce QMacKeyValueObserver and use in theme and styleTor Arne Vestbø2019-06-072-48/+10
| | | | | | Change-Id: I2d21c883628933543ae5a66b694ff7503119bc4a Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: Fix QMouseEvent::buttonMikhail Svetkin2019-05-281-3/+2
| | | | | | | | | | cocoaButton2QtButton(NSEvent *event) did not handle NSEventTypeLeftMouseDragged, NSEventTypeRightMouseDragged, NSEventTypeOtherMouseDragged. Task-number: QTBUG-74763 Change-Id: I9f48230599f16400b49edbff392f712eb1fff782 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: Use QMacNotificationObserver over manual notification handlingTor Arne Vestbø2019-05-292-3/+6
| | | | | | | | | This also fixes a bug where we were implicitly capturing this inside the block, which meant that we would crash if the theme was recreated. The capture is now tied to the lifetime of QCocoaTheme. Change-Id: I37df8e6c0b33bf41e76d66be3cf29576041a7546 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* macOS: Fix reported mouse event buttonsMikhail Svetkin2019-06-031-4/+3
| | | | | | | | | | | | Use m_buttons instead of currentlyPressedMouseButtons. The latter returns the state of devices combined with synthesized events at the moment, independent of which events have been delivered via the event stream, so this method is not suitable for tracking. Task-number: QTBUG-74057 Task-number: QTBUG-74121 Change-Id: Iabf99ada6c3d25a995c9ddf895059b70833a9051 Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
* macOS: Enable VK_MVK_macos_surface on the instanceLaszlo Agocs2019-05-301-1/+1
| | | | | | | | | | | | | | Reports say some systems get "Failed to find vkCreateMacOSSurfaceMVK" even though MoltenVK and the corresponding extensionare there. While not reproducable on single GPU Intel systems, it could be that not enabling the extension on the Vulkan instance is causing this. Not opting in to the extension is incorrect in theory anyway. So fix it in cocoa as well, similarly to how other platform plugins do this already. Task-number: QTBUG-76117 Change-Id: I75220f3582a700ce0037003086123d3d38524648 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Mike Krus <mike.krus@kdab.com>
* Rename QMacScopedObserver to the more fittingly QMacNotificationObserverTor Arne Vestbø2019-05-294-7/+7
| | | | | | Change-Id: I1d8280fe88871572a3a27e612de49717b3b9ef77 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Windows QPA: Fix clang warnings about narrowing conversionsFriedemann Kleint2019-05-295-10/+16
| | | | | | Change-Id: Iba173b45fb77918694fc2c7506885fdeef9f6064 Reviewed-by: André de la Rocha <andre.rocha@qt.io>
* Windows QPA: Optimize code that gets window under pointerAndre de la Rocha2019-05-281-1/+4
| | | | | | | | | | | | It's not necessary to call QWindowsScreen::windowAt() for every mouse message received, but only when the mouse is captured, like it's done in the legacy mouse handler. Change-Id: Ib1035921291d22a32dfa3a619815a3f4ff9b3622 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Windows QPA: Fix QGuiApplication::topLevelAt() with screen recorder applicationsFriedemann Kleint2019-05-281-0/+6
| | | | | | | | | | | | | Special applications like screen recorders can create special, invisible windows which are detected by the ChildWindowFromPointEx() as used in QWindowsContext::findPlatformWindowAt(). Fall back to WindowFromPoint() which skips those in case nothing is found. Fixes: QTBUG-40815 Change-Id: Idb5253c412fb4522c844edf5eadedc6e0fad3979 Reviewed-by: André de la Rocha <andre.rocha@qt.io>
* QHighDpi: Remove fromNativePixels()/toNativePixels() overloadsMorten Johan Sørvig2019-05-221-1/+1
| | | | | | | | | | | | Replace QWindow / QScreen / QPlatformScreen overloads with template functions that take a generic context argument. The API now no longer supports implicit conversions from QPointer<QWindow> to QWindow *, add explicit data() call to usage in qxcbdrag.cpp. Change-Id: I63d7f16f6356873280df58f4e7c924bf0b0eca5b Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* QAndroidInputContext: Fix getTextBefore/AfterCursor() in mid. of preeditVova Mshanetskiy2019-05-081-30/+47
| | | | | | | | | | | | | getTextBeforeCursor() and getTextAfterCursor() were not properly handling the case when the cursor is in the middle of preedit string (just as TODO comments inside these functions were saying). This was causing problems with Gboard when the user focuses a text editor by tapping in the middle of a word. Fixes: QTBUG-58063 Change-Id: I4a580a74d79965816557bfb342337975348d1c45 Reviewed-by: Andy Shaw <andy.shaw@qt.io>
* QAndroidInputContext: Fix most "Input method out of sync" warningsVova Mshanetskiy2019-05-131-0/+2
| | | | | | | | | | | | | | | | According to Android docs start == end in a call to setComposingRegion() means finish composing. But this case was not being handled properly: m_composingText was being assigned an empty string, but m_composingTextStart was being assigned the value of start, which is never -1. There is one other possible cause of "Input method out of sync" warnings, but it is tightly coupled with another bug, so it will be fixed by a separate commit. Change-Id: Ie475df84f330453ce4fc623e8b631b435d7d0042 Reviewed-by: Andy Shaw <andy.shaw@qt.io>
* Windows Accessibility: window should be focusableFrederik Gladhorn2019-05-211-6/+15
| | | | | | Fixes: QTBUG-75001 Change-Id: Iac67b9bba70317f8d28ac2d355d584417d1ffebf Reviewed-by: André de la Rocha <andre.rocha@qt.io>
* eglfs/openwfd: do not purge QSurfaceFormat fieldsLaszlo Agocs2019-05-081-1/+1
| | | | | | | | | Change-Id: I6c1d83624838362f6a3daa6c2b309fb518a25d4b Fixes: QTBUG-75673 Reviewed-by: Janne Koskinen <janne.p.koskinen@qt.io> Reviewed-by: Johan Helsing <johan.helsing@qt.io>
* Windows Accessibility: Add UI Automation Window providerFrederik Gladhorn2019-05-204-0/+249
| | | | | | | | | This allows closing, minimizing and maximizing the window. Fixes: QTBUG-74999 Change-Id: I8b3ad806a1767586c8cf7e5a1848fc0e525621cd Reviewed-by: André de la Rocha <andre.rocha@qt.io>
* Windows QPA: Fix QWheelEvent::buttons() after click on title barAndre de la Rocha2019-05-185-15/+84
| | | | | | | | | | | | | | | When the left or right mouse buttons are pressed over the window title bar a WM_NCLBUTTONDOWN/WM_NCRBUTTONDOWN message is received. But when the button is released, no corresponding UP message is received, but only a WM_NCMOUSEMOVE or WM_MOUSEMOVE. This makes the internal mouse button state stored in QGuiApplication get out of sync with the actual state, resulting in an incorrect button state being used in QWheelEvent. This patch detects the button release condition and generates the missing release event. Change-Id: I6dd9f8580bd6ba772522574f9a08298e49c43e61 Fixes: QTBUG-75678 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* winrt: Return monospace font for ↵Oliver Wolff2019-05-152-0/+19
| | | | | | | | | QFontDatabase::systemFont(QFontDatabase::FixedFont) Fixes: QTBUG-75648 Change-Id: I0e5e5e012d3cd5985d1e9a63e776e73ce2d7bf98 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* iOS: be more careful about hiding the edit menuRichard Moe Gustavsen2019-05-151-3/+8
| | | | | | | | | | | | | | | | | | The code that deals with text selection in the iOS QPA plugin, listen for changes to text selection. And depending on whether we have a selection or not, we show or hide the selection handles together with the edit menu. The problem is that the edit menu will also be told to show from other places, even if there is no selection. And for those cases, we should avoid closing it. This patch will check, before we close the edit menu, if we're tracking a selection. If not, we leave the edit menu alone. Fixes: QTBUG-75099 Change-Id: I001d818fa2ad4a215cc3fa6aa4c7faf516e1ed59 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QMenu: show shortcuts in context menus by defaultRichard Moe Gustavsen2019-05-151-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change c2c3452ba introduced a new API in Qt to let QPA inform whether or not shortcuts should be shown in context menus. This was set to false by default, since by observation, this seemed to be the most common behavior across platforms. The problem is that it left no way for the application to override it; The attribute Qt::AA_DontShowShortcutsInContextMenus simply doesn't work when shortcuts are always off. And for some application, showing shortcuts is not just a matter of look-and-feel, but also important information to be able to use the application the way intended. This patch reverts the behavior back to how it was in Qt-5.9, where shortcuts where shown by default (except on macOS where we still keep them off). It's no so much because the "always off" logic is wrong, but because there is no (easy) way/work-around for an app developer to switch them back on (until Qt-5.13, where a new API is introduced to fix the situation: b1a9a77). And this lack of API can be a show-stopper for some when upgrading from e.g 5.9 LTS to 5.12 LTS. This downside of this patch, OTOH, is that it can cause more change that what is normally wanted in a patch release. But out of two evils, this is the best option. Those that wan't to hide shortcuts can set AA_DontShowShortcutsInContextMenus to true, which now will work. [ChangeLog][QtWidgets][QMenu] Shortcuts are again shown by default in context menus, except on macOS. They can be forced off by setting AA_DontShowShortcutsInContextMenus to true. Fixes: QTBUG-69452 Change-Id: Ibcc371395944ac5b19b1d20889940da271bf73d5 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
* macOS: Guard against display on non-main threadsTor Arne Vestbø2019-05-131-0/+9
| | | | | | | | | | | | | | AppKit will in some cases ask our view to display on secondary threads if we call APIs that are only supposed to be called on the main thread, such as -[NSOpenGLContext setView:] or -[NSOpenGLContext update]. Forwarding this display-request is bad, as QtGui expects all window system events to come on the main thread, and we can easily deadlock client code such as the Qt Quick threaded renderer. Change-Id: I1daeabf1dca6ca8ba908d3998b444a2089681e3a Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Windows QPA: Fix resize loops when moving fixed size windows between screensFriedemann Kleint2019-05-133-23/+44
| | | | | | | | | | Postpone the screen change until the DPI changed event in case a move between screens with different DPI is detected. Task-number: QTBUG-65580 Change-Id: I356f144b243d7d1ce7feabf0434c3f534b903965 Reviewed-by: Oliver Wolff <oliver.wolff@qt.io> Reviewed-by: Andre de la Rocha <andre.rocha@qt.io>
* Windows QPA: Fix window frame calculation in multi-monitor setupsFriedemann Kleint2019-05-137-60/+146
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When introducing EnableNonClientDpiScaling() for QTBUG-53255, the window frame calculation was not adapted. That is, window frames were calculated from the style for the primary screen only, causing - minimum size constraints not being calculated correctly for applications on secondary screens when populating the MINMAXINFO structure. - warnings about not being able to apply a geometry when moving fixed size windows across screens. The calculation of the frames for propagating size hints is also no longer required after 3035400f36731c400adb9204b94e9afe346a71b7, which retrieves them from the WM_NCCALCSIZE message; QWindowsWindow::fullFrameMargins() can be used instead. For newly created windows, use the newly added AdjustWindowRectExForDpi() function to calculate the initial frame size. Change QWindowsGeometryHint from a class to a collection of static functions and add overloads to calculate the frame. In checkForScreenChanged(), update the margins until WM_NCCALCSIZE is received. Task-number: QTBUG-67777 Task-number: QTBUG-65580 Task-number: QTBUG-53255 Change-Id: Iff2d382b2b316adec6c1a0622ae8015dba6de371 Reviewed-by: Oliver Wolff <oliver.wolff@qt.io> Reviewed-by: Andre de la Rocha <andre.rocha@qt.io>
* QAndroidInputContext: Fix start value of Cursor attribute in longPress()Vova Mshanetskiy2019-05-101-1/+1
| | | | | | | | | | | | The value of start for a QInputMethodEvent::Cursor attribute must be specified relative to the start of preedit string, but longPress() was specifying it relative to start of surrounding text. This was causing QQuickTextInput to return wrong values of cursor and anchor rectangles. And this was causing invalid positioning of cursor selection handles after a long press. Change-Id: Ief67e86dd90b09ebf2ba191a2b0311ff803afdd9 Reviewed-by: BogDan Vatra <bogdan@kdab.com>
* macOS: Deliver geometry changes when content view changes frameTor Arne Vestbø2019-05-101-3/+5
| | | | | | | | | | | | | | | | | This was disabled in 9f22ac0aa0254f20f9b26aec7b124d74141fdfcd under the assumption that the windowDidResize callback was sufficient, but in the situation when macOS native tabs are enabled, AppKit will report the wrong geometry for the first windowDidResize callback when a new tab is created. We could potentially remove the geometry change in windowDidResize, as the viewDidChangeFrame callback should be enough for content views, but this is something that needs more investigation. Change-Id: I85045507da1a01b4a906e6f88301f3321c660943 Fixes: QTBUG-75482 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: Implement QCALayerBackingStore::toImage()Tor Arne Vestbø2019-05-102-0/+16
| | | | | | | | | | | It's not part of the QBackingStore API, but clients such as the Qt Quick software renderer access it through the platform backingstore, to grab the window. Change-Id: I203484ce13a5f8fb6815d27ab07f874fa9d16b8c Fixes: QTBUG-75467 Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Windows QPA: Improve debug messagesFriedemann Kleint2019-05-093-17/+66
| | | | | | | | | | Include screen and MINMAXINFO values in the message about not being able to set the geometry. Suppress output of some window finding functions unless verbose. Change-Id: Iaaae59ecb302438b3444735067d018c77d2af162 Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* macOS: Deliver and handle screen change unconditionallyTor Arne Vestbø2019-05-081-17/+28
| | | | | | | | | | | | | | | | | | | We can't rely on the previous screen and current screen to accurately reflect whether or not the window has been moved from one screen to another, or if the window just stayed on the same screen but the screen was reconfigured by macOS. The reasons for this are many-fold, but include factors such as Qt using the screen of the top level window to resolve the screen of the child windows, and AppKit delivering screen change events in an order that makes things harder to track. The result is that we need to always send screen change events, for all windows, including child windows, and we also need to restart the display link by re-requesting an update request if needed, so that child windows that are running animations will continue to animate on the new screen. Change-Id: I0b87849c41323e92c08f5115842be067fa8f8490 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* macOS: Always respond to cursorUpdate by applying custom cursor if setTor Arne Vestbø2019-05-081-4/+7
| | | | | | | | | | Calling super will push the default arrow cursor, so we should only do that if our own cursor has been unset. Change-Id: I71d8934e7eab2b15e150730e2282e7063ada305a Fixes: QTBUG-75552 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Windows QPA: Fix over-large transparent tooltipsFriedemann Kleint2019-05-071-0/+3
| | | | | | | | | | | Setting transparency (WS_EX_LAYERED) causes a WM_PAINT to be sent to the invisible windows, which causes a resize to the default size (640x480) to be sent from QGuiApplicationPrivate::processExposeEvent(). Suppress these messages. Fixes: QTBUG-75455 Change-Id: Idc540aa7f9bf0047e78ec7c27db260940483f7c4 Reviewed-by: Andre de la Rocha <andre.rocha@qt.io>
* macOS: Guard backingstore composeAndFlush with QT_NO_OPENGLTor Arne Vestbø2019-05-072-0/+4
| | | | | | | Fixes: QTBUG-75612 Change-Id: I0e90a84697c1eb055c4150f2519829977fce7244 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: don’t crash when wrapping foreign viewsMorten Johan Sørvig2019-05-071-1/+3
| | | | | | | | | window.contentView can be of any NSView subclass. Get to the QCocoaWindow via QCocoaNSWindow instead. Change-Id: I8c761fd22e6078b075d8dd035ad767b9e4cb6da2 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: Move off deprecated handleFrameStrutMouseEvent APITor Arne Vestbø2019-05-071-3/+28
| | | | | | | Change-Id: Id95c096700a8bfa733d8620064c2a37eb19cc3db Fixes: QTBUG-72741 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Add an ID for recognition of UGEE tabletsDmitry Kazakov2019-05-071-0/+4
| | | | | | Change-Id: I2228ee9d53aa23a2d2cd9970a363d8424e744093 Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Fix generation of Leave events when using tablet devicesDmitry Kazakov2019-05-071-0/+3
| | | | | | | | | | | | | | When both mouse and tablet events are handled by QWindowsPointerHandler, m_currentWindow variable is shared among the two event streams, therefore each stream should ensure it does equivalent operations, when changing it. Here we should subscribe to the Leave events, when we emit Enter event from the inside of the tablet events flow. Without whis subscription, the cursor may stuck in "resize" state when crossing the window's frame multiple times. Change-Id: I88df4a42ae86243e10ecd4a4cedf87639c96d169 Reviewed-by: Andre de la Rocha <andre.rocha@qt.io>
* Fix dnd regression c427ba53aa0ee1a71aa670783f65bcfd230da653Mikhail Svetkin2019-05-051-0/+19
| | | | | | | | | | | Qt starts drag-and-drop on a mouse button press event. Cococa in this case won't send the matching release event, so we have to synthesize it here. Task-number: QTBUG-72417 Change-Id: I645b6a2733c1ea11ac4545cf3405f826af45fa47 Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* fix compilation with various -no-feature-* optionsNick Shaforostov2019-05-051-1/+2
| | | | | Change-Id: Ic1975db497613e3efe50be4246c167efe10d8e31 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-19 18:01:06 +0000