summaryrefslogtreecommitdiffstats
path: root/src/plugins/platforms/cocoa
Commit message (Collapse)AuthorAgeFilesLines
* Merge remote-tracking branch 'origin/5.11' into 5.12Liang Qi2018-10-173-0/+14
|\ | | | | | | | | | | | | | | Conflicts: src/plugins/platformthemes/platformthemes.pro src/printsupport/kernel/qplatformprintdevice.cpp Change-Id: Iac01729ad954bb1c7af5867d982eb243b2139ee6
| * Modernize the "mimetype" featureLiang Qi2018-10-122-0/+6
| | | | | | | | | | | | Change-Id: I9b67c2cbc0891a38ece18d521c86fbc7344dce7a Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
| * [macOS] Fix position of sheets when using unifiedTitleAndToolBarOnMacAlexandru Croitor2018-10-081-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Modal sheets are supposed to appear below the toolbar if a toolbar exists, or below the title bar if a toolbar doesn't exist. In the unified title and toolbar mode, sheets should to appear directly below the toolbar, if the toolbar is positioned at the top of the window. Code-wise we achieve that by calling setUnifiedTitleAndToolBarOnMac on a QMainWindow, which results in adjusting the top content border of the NSWindow via [NSWindow setContentBorderThickness:forEdge], which Cocoa uses to position a modal sheet (the sheet top edge is aligned with the top edge of the content view + the Y border thickness value). The issue is that because NSWindow.titlebarAppearsTransparent is set to YES, for sheet presentation purposes, Cocoa considers the content view to begin at the position of the top left corner of the frame (where the title bar is), and thus sheets appear somewhere in the middle of the unified toolbar. To fix that we need to account for the title bar height in the border thickness value. Compute the title bar height from the window frame height - window content view height, and add it to the top border thickness value. Amends 8ac9addd946637401e4685c6e91d1a3cd5b2d768 Change-Id: Icf85c513035cc3710b438e60eb14dc04c5bbaced Fixes: QTBUG-65451 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* | qt_mac_createRolePalettes: fix the highlight color for ItemViewPalette roleTimur Pocheptsov2018-10-141-1/+1
| | | | | | | | | | | | | | | | | | While this requires from us calling a deprecated method, a (non-deprecated) method we were using gives a wrong color which is too bright/saturated. Task-number: QTBUG-70676 Change-Id: Icebeb53e351caa646c533595ca1a886e5eb6b5b8 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* | qnsview_keys - fix a typoTimur Pocheptsov2018-10-131-1/+1
| | | | | | | | | | | | | | | | | | that resulted in 'Cmd' reported as combo of Qt::Meta/Qt::Control and Qt::KeypadModifier. Task-number: QTBUG-71006 Change-Id: I3dddc56f4d404a1ceefb21d57ac120b6273456ec Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* | Cocoa integration: fix incorrect keyboard mappingTimur Pocheptsov2018-10-041-4/+6
| | | | | | | | | | | | | | | | When switching between different input sources, we have to update layouts. Task-number: QTBUG-50865 Change-Id: I0c23c19b79a2102dcc533822b0f861c387582c6c Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* | QCocoaKeyMapper: Properly initialize all members and reset on updateUlf Hermann2018-10-042-12/+10
| | | | | | | | | | | | | | | | | | | | | | Previously some of the members would have random initial values. Also, on updateKeyboard() if we don't find usable uchrData, we should just reset keyboard_layout_format and keyboard_mode, rather than keep the previous values. Task-number: QTBUG-50865 Change-Id: I1297fa55bb1593dd549d0bc122713d5d98f7b1fc Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* | macOS: Don't call [NSOpenGLContext update] for every frameTor Arne Vestbø2018-10-032-3/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Calling update has a cost, and should only be done when the drawable object changes size or location. Instead of calling update each time makeCurrent is called, we listen for the appropriate notifications, limiting the number of update calls significantly. We still call update on the thread owning the QOpenGLContext, which is not ideal, as [NSOpenGLContext update] should only be called on the main thread, but in practice this works. Getting out of this situation is tricky, and setView has in theory the same problems. Until those problems have been solved we keep the behavior as is. Task-number: QTBUG-63572 Change-Id: Ibac9f8be7843f2aa006af6f7ee670bf027122440 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* | macOS: Ensure QFontDialog picks up changes in NSFontPanelTor Arne Vestbø2018-10-031-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the font changes in NSFontPanel, it notifies NSFontManager via -[NSFontManager modifyFontViaPanel:], which in turn sends the font manager's action (by default changeFont:) to its target (nil, unless set). Sending the action in -[NSApplication(NSResponder) sendAction:to:from:] will sanitize the 'to' argument via _NSTargetForSendAction. If the argument is non-nill (if we've set the NSFontManager target explicitly), and we're running in an app-modal session (which we are), the target is checked for worksWhenModal -- a property which is defined on NSWindow, and only supposed to be set for subclasses of NSPanel. Since our QNSFontPanelDelegate class doesn't implement this method, the _NSTargetForSendAction function will return nil, and the action is never sent. If we don't set the NSFontManager target (leaving it as nil), the function will skip the worksWhenModal check, and fall back to resolving the target via the responder chain, which includes taking the NSPanel's delegate into account: #0 -[NSWindow delegate] () #1 -[NSWindow(NSEventRouting) supplementalTargetForAction:sender:] () #2 _objectFromResponderChainWhichRespondsToAction () #3 _NSTargetForSendAction () #4 -[NSApplication(NSResponder) sendAction:to:from:] () #5 -[NSFontManager sendAction] () ... Since we want to end up in the QNSFontPanelDelegate, we can rely on the default logic to resolve the target based on the responder chain. But in case _NSTargetForSendAction will at some point also check the resolved target for worksWhenModal, we also implement the worksWhenModal method, to be on the safe side. Fixes: QTBUG-69878 Change-Id: Ie739d016fe0efd17b3d8a99cc1fb1ace81807aff Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* | macOS: Use light color for tooltip text in dark modeMorten Johan Sørvig2018-09-251-0/+3
| | | | | | | | | | | | | | | | Tool tip text is drawn by QLabel using ToolTipText text role. Give it a system palette entry. Change-Id: I2e1b4f0b130783efd8d03f53a42c3e64aec32425 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* | qnsview_key/qnsview_mouse make Ctrl+left click work againTimur Pocheptsov2018-09-242-4/+8
| | | | | | | | | | | | | | | | | | A result of typo/incorrect keyboard modifiers extracted + wrong button sent via QWindowSystemInterface::handleMouseEvent. Task-number: QTBUG-70512 Change-Id: I809168e363496884312412051e8d435f5794b3be Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* | macOS: Clarify what static mutex in QCocoaGLContext is used forTor Arne Vestbø2018-09-131-4/+6
| | | | | | | | | | | | Change-Id: I4af0b78dbecad40b2a73cdbdb09a8eb60efdb013 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* | macOS: Prevent flickering when resizing window rendered to by separate threadTor Arne Vestbø2018-09-111-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a window is resized AppKit groups all updates to the view frames and corresponding layer bounds, so that the result of the resize is visually atomic, but this only works for the main thread. http://openradar.appspot.com/radar?id=4990815088672768 When a separate thread renders to one of the views in the window, it may result in the view and its layer updating its bounds visually before the resize has been visually reflected for the window itself and its border. To ensure visually atomic updates, we disable all screen updates for the process during resizing. This is the same workaround used by e.g. the NSOpenPanel class, which renders the content of the view out of process, and by Chromium for a similar use-case: https://chromium-review.googlesource.com/c/chromium/src/+/798774 Ideally we'd do this only for the window that is being resized, but there's no known API to do that. The deprecated [NSWindow disableScreenUpdatesUntilFlush] is a no-op these days, and used NSDisableScreenUpdates internally anyways). Fixes: QTBUG-69321 Change-Id: I84de714782278f2e0b2b2e1eb245c30810cb3023 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* | Merge "Merge remote-tracking branch 'origin/5.11' into 5.12" into ↵Liang Qi2018-09-101-21/+0
|\ \ | | | | | | | | | refs/staging/5.12
| * | Merge remote-tracking branch 'origin/5.11' into 5.12Liang Qi2018-09-101-21/+0
| |\| | | | | | | | | | | | | | | | | | | Conflicts: mkspecs/common/macx.conf Change-Id: I8576493b417912fa5e5501bc2c1b935d186ac209
| | * Revert "macOS: Force light theme on macOS 10.14+"Morten Johan Sørvig2018-09-031-21/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This does not really work: as soon as you build with the 10.14 SDK you opt-in to having updated palette management, which the Qt 5.11 series does not have. This leaves app developers with two ways to opt-out of dark mode: - Build with the 10.13 (or earlier) SDK. - Set NSRequiresAquaSystemAppearance in Info.plist This reverts commit 04671a80db32bd7fce470c50934cf60f2e8ffa70. Change-Id: I5c01b9965da45de914f699526ba0723837f36e1d Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
* | | macOS: Release surfaces straight away when reconfiguring QCocoaGLContextTor Arne Vestbø2018-09-101-0/+10
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Calling setView or update on NSOpenGLContext results in recreating the internal GL surfaces of the view. Unfortunately there seems to be a fixed amount of these surfaces available, so if we spin a loop where we for some reason end up recreating them, we'll easily run out, and lock up the whole window system: thread #6, name = 'SwapThread' frame #0: 0x00007fff7b45220a libsystem_kernel.dylib`mach_msg_trap + 10 frame #1: 0x00007fff7b451724 libsystem_kernel.dylib`mach_msg + 60 frame #2: 0x00007fff751c1675 SkyLight`SLSBindSurface + 247 frame #3: 0x00007fff5d9c4328 OpenGL`___lldb_unnamed_symbol29$$OpenGL + 255 frame #4: 0x00007fff6bf42c33 libGPUSupportMercury.dylib`gldAttachDrawable + 364 frame #5: 0x00007fff5d9e61e7 GLEngine`gliAttachDrawableWithOptions + 257 frame #6: 0x00007fff5d9c4bb0 OpenGL`___lldb_unnamed_symbol38$$OpenGL + 969 frame #7: 0x00007fff5d9c8b0e OpenGL`___lldb_unnamed_symbol57$$OpenGL + 82 frame #8: 0x00007fff5d9c8e55 OpenGL`CGLSetSurface + 330 frame #9: 0x00007fff50d0eb2c AppKit`NSOpenGLContextAttachOffScreenViewSurface + 352 This can happen e.g. when resizing the application, where AppKit itself spins a loop where we don't end up back in QCocoaEventDispatcher::processEvents() for each pass (where we do have a local pool). Or it can happen in the render-loop of a render-thread that doesn't use the event dispatcher. Change-Id: Iaf2f879dd01e3d807d0f35705ccc978dbc89036b Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* | macOS: Use NSOpenGLContext's drawable directly to track active drawableTor Arne Vestbø2018-09-095-64/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | We don't need a separate QWindow pointer to keep track of the active window, it's recorded already by the NSOpenGLContext's drawable. And we don't need to juggle the drawable when the window is hidden, the drawable is still valid after the window is re-shown, and we call update on every frame (for now) anyways, which will reconfigure the drawable if needed. Change-Id: I199b6c027226dd239c13ecc4aba86986ca09a1eb Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* | Cocoa: change background color of selected menu itemsRichard Moe Gustavsen2018-09-081-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change 582d221b29 caused a regression when drawing menu items in e.g a QComboBox. After that change, QCocoaSystemSettings would set the QPalette::Highlight color to [NSColor selectedMenuItemTextColor]. But the Highlight color is the background color, not the text color. And we also use [NSColor selectedMenuItemTextColor] as the QPalette::HighlightedText color. The result is that highlighed menu items end up with the same foreground and background color (white), which means that they "disappear". The color that we used before the patch, alternateSelectedControlColor, could be used, but has the downside that it doesn't follow the appearance color in system settings (like it should, compared to native apps). And it's also slightly to blue. But using keyboardFocusIndicatorColor seems like a perfect match. Fixes: QTBUG-69500 Change-Id: I07f091a5130a7308525743948d2a435226658a6f Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* | macOS: Clear NSOpenGLContex's drawable when using offscreen surfacesTor Arne Vestbø2018-09-071-21/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Otherwise the user might accidentally render to the previously active window, if not explicitly using an FBO. This will have an performance impact if doing makeCurrent on a real window and an offscreen window back and forth with the same context, but that's not really a common or recommended use of QOffscreenSurface, as you can create FBOs with a normal window current as well. The use case of QOffscreenSurface is when a real window is not available. Change-Id: If93d04f82564523e15d5970429afea34c5cd31fe Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* | cocoa: Fix build with MoltenVKLaszlo Agocs2018-09-061-2/+6
| | | | | | | | | | Change-Id: If92afa2d30d55e1dd2968f582350ba2cf16fe27b Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* | macOS: Use single call site for timer processing in event dispatcherTor Arne Vestbø2018-09-062-5/+11
| | | | | | | | | | | | | | | | | | | | Makes it easier to add shared logic later on. The call to maybeCancelWaitForMoreEvents() has been left out as it was not called from all call sites. Change-Id: Ibcb10ab4d788de80850b0e5a4286b4d49091cddb Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* | macOS: Rename QCocoaGLContext::setActiveWindow to setDrawableTor Arne Vestbø2018-09-062-12/+16
| | | | | | | | | | Change-Id: I0be5125b434418c005f45f05c54b22f0418b46e4 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* | macOS: Remove support for QSurfaceFormat::StereoBuffersTor Arne Vestbø2018-08-311-5/+3
| | | | | | | | | | | | | | | | | | | | The NSOpenGLPFAStereo attribute was deprecated in macOS 10.12, without any replacement, and adding the attribute to the pixel format results in context creation failure, so we're assuming the feature is no longer supported an disable it wholesale on macOS. Change-Id: I27d9f300fdaff9abe90781e3160b97f8b66121ad Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* | macOS: Update all deprecated enums to their 10.12+ equivalentsTor Arne Vestbø2018-08-3113-125/+123
| | | | | | | | | | Change-Id: I3034258da95c9c70eb6758db92967f438617f6e9 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* | Remove codepaths and checks for unsupported Apple platformsTor Arne Vestbø2018-08-313-35/+19
| | | | | | | | | | | | | | We no longer support macOS 10.11, iOS/tvOS 10, or watchOS 3. Change-Id: Ide03d8fac06185ef4162ba75ee54a0adf6916905 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* | macOS: minor refactoring QSendSuperHelperMikhail Svetkin2018-08-241-14/+5
| | | | | | | | | | | | | | Replace local implementation of index_sequence with QtPrivate::IndexesList Change-Id: I193b9183ec6832294687e979576a2e3ec56d550b Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* | macOS: Teach QWheelEvent to handle a new ScrollMomentum phaseTor Arne Vestbø2018-08-171-23/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We detect if there's an upcoming momentum phase using the same trick used by e.g. Mozilla in their event handling: https://tinyurl.com/yd8lcs4l, and as recommended by an Apple engineer: https://tinyurl.com/y8yytlgv The event is not guaranteed to be in the queue, but in practice it seems to be. If this assumption fails we can add a wait timeout to the event search instead of using [NSDate distantPast] as a timeout (which only looks at queued events). When the momentum phase is detected, QWheelEvent::phase will have the new ScrollMomentum value, and the phase transitions will be ScrollBegin -> ScrollUpdate -> ScrollMomentum -> ScrollEnd. We no longer send ScrollEnd to signify that the user's fingers have been lifted off the trackpad; rather, the first event with ScrollMomentum phase means that the fingers have been lifted and macOS is now sending simulated-momentum events. This means ScrollEnd is a reliable indicator that the entire scroll gesture (both the user interaction and the momentum) has ended. If the ScrollMomentum phase is skipped, it means the user's fingers came to rest before being lifted, so there is no momentum. In that case the transitions will be ScrollBegin -> ScrollUpdate -> ScrollEnd. Task-number: QTBUG-63026 Task-number: QTBUG-65160 Change-Id: I80191a472f6fa892387004c199166a6350124274 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Merge remote-tracking branch 'origin/5.11' into devLiang Qi2018-08-161-0/+21
|\| | | | | | | | | | | | | | | | | Conflicts: src/corelib/global/qconfig-bootstrapped.h src/plugins/platforms/xcb/qxcbbackingstore.cpp Done-with: Gatis Paeglis <gatis.paeglis@qt.io> Change-Id: I4af138ffb2f5306373244523768209e8873b2798
| * macOS: Force light theme on macOS 10.14+Gabriel de Dietrich2018-08-091-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until we can properly fix QPalette and QMacStyle, we should disable dark appearance in Qt applications. Disable by setting NSApp.appearance to Aqua, unless dark mode support has been requested via Info.plist or environment variable. Read the NSRequiresAquaSystemAppearance Info.plist key, don’t set NSApp.appearance if its value is false. Also check the QT_MAC_REQUIRES_AQUA_SYSTEM_APPEARANCE environment variable and apply similar logic. You then enable dark mode support by setting: QT_MAC_REQUIRES_AQUA_SYSTEM_APPEARANCE=0 which is slightly awkward, but matches Info.plist behavior. Task-number: QTBUG-68891 Change-Id: I86dc6cf3dee951d46c953396c57d2c31f2e4afcc Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* | Revert "macOS: Don't call [NSOpenGLContext update] for every frame"Liang Qi2018-08-155-99/+76
| | | | | | | | | | | | | | | | | | | | This reverts commit 823acb069d92b68b36f1b2bb59575bb0595275b4. It caused some test failures in qtdeclarative and etc. Task-number: QTBUG-69891 Change-Id: I2e4038a46de254834e6389c63f6dad0c2e523b8e Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* | Cocoa: Update palette after accent color or appearance changesGabriel de Dietrich2018-08-092-21/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This updates the UI after the accent color or NSApp's effective appearance have changed. For the accent color, we listen to NSSystemColorsDidChangeNotification. For the effective appearance changes, we do KVO on NSApp.effectiveAppearance. Both changes will trigger rebuilding the system palettes followed by a ThemeChangeEvent in the window system interface layer. Task-number: QTBUG-68891 Change-Id: Iab1ec874e05f1f6d54cd60217c273e0f8ffbf49e Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* | Merge remote-tracking branch 'origin/5.11' into devQt Forward Merge Bot2018-08-082-6/+24
|\| | | | | | | | | | | | | | | Conflicts: src/plugins/platforms/cocoa/qcocoabackingstore.mm src/plugins/platforms/cocoa/qcocoascreen.mm Change-Id: Iac965aea4867059dbf7bc401b71e8e8b5b259afb
| * macOS: Don't blend the backingstore unless the window has a backgroundTor Arne Vestbø2018-08-071-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | If there's no background, we should copy the backingstore, so that the backingstore is not blended with the result of the previous flush. The unified toolbar case is covered by the window having a textured background. Task-number: QTBUG-69773 Change-Id: I2f4eed9f44a60ebe7495ce68cf5a54d3d2424b0c Reviewed-by: Erik Verbruggen <erik.verbruggen@qt.io> Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
| * macOS: Update window geometries after screen properties changeTor Arne Vestbø2018-08-071-0/+14
| | | | | | | | | | | | | | Task-number: QTBUG-69794 Task-number: QTBUG-68140 Change-Id: I4d33bc2136478d779cc4ae8170c3421d9a7557cc Reviewed-by: Erik Verbruggen <erik.verbruggen@qt.io>
* | macOS: Don't call [NSOpenGLContext update] for every frameTor Arne Vestbø2018-08-075-76/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Calling update has a cost, and should only be done when the drawable object changes size or location. Instead of calling update each time makeCurrent is called, we listen for the appropriate notifications, limiting the number of update calls significantly. The code has also been refactored to get rid of the m_activeWindow member, as the active window can be tracked through the context's drawable object property. There is also no need to clear the drawable when a window is hidden, so the hook into QCocoaWindow can be removed. The QPlatformNativeInterface hook is internal and can safely be removed. Task-number: QTBUG-63572 Change-Id: I70e3267f47882e151144bd36a50abe906164429a Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* | Merge "Merge remote-tracking branch 'origin/5.11' into dev" into ↵Liang Qi2018-08-071-18/+15
|\ \ | | | | | | | | | refs/staging/dev
| * | Merge remote-tracking branch 'origin/5.11' into devQt Forward Merge Bot2018-08-071-18/+15
| |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: .qmake.conf src/corelib/doc/src/objectmodel/signalsandslots.qdoc src/plugins/platforms/cocoa/qcocoamenuloader.mm src/plugins/platforms/xcb/qxcbconnection.cpp src/plugins/platforms/xcb/qxcbconnection.h src/plugins/platforms/xcb/qxcbconnection_xi2.cpp src/plugins/platforms/xcb/qxcbwindow.cpp tests/auto/gui/image/qimage/tst_qimage.cpp Done-with: Gatis Paeglis <gatis.paeglis@qt.io> Change-Id: I9bd24ee9b00d4f26c8f344ce3970aa6e93935ff5
| | * QCocoaMenuLoader - ensure that ensureAppMenuInMenu indeed, ensuresGabriel de Dietrich2018-08-011-18/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The logic seems to be incorrect (or the naming is misleading): it only adds 'appMenu' if it was found in the previous 'mainMenu', failing otherwise. Consider the following example: while (true){ QApplication app(a,b); MainWindow w; w.show(); app.exec(); } It's quite a contrived but apparently allowed API use (OP claims they have to switch languages in their app). The main window and the app are destroyed, so is the menu bar. Then a new main window is created, with a new menu bar. Now the current [NSApp mainMenu] (the one set after we deleted the previous) does not have 'appMenu' anymore (we removed it when initializing the first menu bar). So as a result we have app menu missing and add new menus/items to a wrong menus/at wrong index. Change-Id: I64fce766d6c12ebf7ae12bb94af41c8c1de3d78b Task-number: QTBUG-69496 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* | | Add logging for QPlatformBackingStore::composeAndFlushTor Arne Vestbø2018-08-071-2/+0
| | | | | | | | | | | | | | | Change-Id: I96778296480d2aaad5e01ed15353106bc90d4d2b Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* | | macOS: Add missing braces in QCocoaIntegration::updateScreens()Tor Arne Vestbø2018-08-071-1/+2
|/ / | | | | | | | | | | Change-Id: I0f5009c8ba8f2f1853a968d9853dc45e8cbc2b5f Reviewed-by: Erik Verbruggen <erik.verbruggen@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* | macOS: Don't make QCocoaGLContext current unless we have a drawableTor Arne Vestbø2018-08-041-3/+5
| | | | | | | | | | Change-Id: I12ac982aa977c69af936f503369c91bac88492a9 Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
* | macOS: Modernize and clean up QCocoaGLContext::updateSurfaceFormat()Tor Arne Vestbø2018-08-041-97/+76
| | | | | | | | | | | | | | | | | | | | The updateFormatFromContext function that read GL state has been merged into updateSurfaceFormat(), we're using AppKit classes and functions instead of Core GL, and the logic has been simplified by using attribute/parameter helpers. Change-Id: Iec6717f457a0b4dbc8e34c3e15fcbcc42895b23e Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
* | macOS: Add note about high-resolution workaround in QCocoaGLContext::makeCurrentTor Arne Vestbø2018-08-041-0/+2
| | | | | | | | | | Change-Id: I0b82ef95c1a058586e8005665e1e2cab3f975833 Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
* | macOS: Simplify and clean up QCocoaGLContext constructorTor Arne Vestbø2018-08-043-34/+36
| | | | | | | | | | Change-Id: Ie16256282784926506355012a735511b98118614 Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
* | macOS: Clean up and rename QCocoaGLContext::pixelFormatForSurfaceFormat()Tor Arne Vestbø2018-08-042-24/+27
| | | | | | | | | | Change-Id: I1a439d8cec950cb23c977eedfcc1b8810c6cd1c5 Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
* | macOS: Disambiguate use of native handles in QCocoaGLContextTor Arne Vestbø2018-08-034-16/+10
| | | | | | | | | | | | | | | | | | We only need the QVariant native handle when creating the context, so there's no need for a getter, and we then rename the NSOpenGLContext getter to match e.g. QCocoaScreen::nativeScreen(). Change-Id: I041e0eff39af9c8836d8ecd560ea07e92dc63e03 Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
* | macOS: Remove GL defines from QCocoaGLContextTor Arne Vestbø2018-08-031-20/+0
| | | | | | | | | | | | | | They should be available in all SDKs we build against and support. Change-Id: I799492e0b21a877717fb3a8391bcbad0f8581628 Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
* | macOS: Don't mess with native handle for QOpenGLContextTor Arne Vestbø2018-08-031-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | QOpenGLContext::setNativeHandle() is documented as: "configuration settings, like format(), are ignored since this QOpenGLContext will wrap an already created native context" We should respect this and not apply QT_MAC_OPENGL_SURFACE_ORDER. Change-Id: Idfdf3eac0e9f9d0a86f1b23aa475c3e4f12127e2 Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
* | macOS: Remove unneeded auto-release-pools in QCocoaGLContextTor Arne Vestbø2018-08-031-3/+0
| | | | | | | | | | | | | | | | The makeCurrent one was not explained in the commit message that introduced it, and doesn't make any sense, while the constructor one is no longer needed. Change-Id: I67e2f2aaff5d8602781b27f122f415068a1f2301 Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-03 08:43:50 +0000