summaryrefslogtreecommitdiffstats
path: root/src/plugins/platforms/cocoa
Commit message (Collapse)AuthorAgeFilesLines
* QCocoaEventDispatcher: Save interrupt state between embedded callsGabriel de Dietrich2016-10-041-1/+1
| | | | | | | | | | | | | | | | Since QCocoaEventDispatcher::processEvents() resets the interrupt state, this may prevent a higher level event loop from returning. For example, calling QMenu::exec() and, as a result of an action being triggered, the application calls QCoreApplication::processEvents() after QMenu::hideEvent(). In this case, the menu event loop can be stuck until we run another event loop. Task-number: QTBUG-53947 Change-Id: If7efe1c3c07f7222c695195cbb4f41715e49b02e Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com> Reviewed-by: Wayne Arnold <wayne.arnold@autodesk.com> Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* Update swap interval of QCocoaGLContext after creationTor Arne Vestbø2016-09-191-0/+5
| | | | | | | | | QSurfaceFormat is recreated from scratch, and by not reading back the swap interval the QCocoaGLContext seemed to be vsynced even if it actually was not. Change-Id: I72ddaae9a4c695fe4c74d7b4b70ca9db84bcc084 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Cocoa: Add support for triple-buffered GL contextsTor Arne Vestbø2016-08-291-1/+9
| | | | | | | | | As usual, the requested format may not be available, so clients should check the actual format to confirm triple-buffering. Change-Id: Icf073cc9ddf2c912eb5c3ce0ac80d1694d1c56d7 Reviewed-by: Jake Petroules <jake.petroules@qt.io> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* QCocoaInputContext: Fix wrong memory releaseGabriel de Dietrich2016-08-181-1/+1
| | | | | | | | | | | As per Core Foundation ownership conventions, we should release 'source', which is a copy, and not 'langRef', which is a reference. This has shown to lead to crashes in some occasions. Change-Id: I2e59b8d62aac13bc60dc013c1ea621850132c719 Task-number: QTBUG-48772 Reviewed-by: Jake Petroules <jake.petroules@qt.io>
* Cocoa QPA Menus: Propagate enabled state downwardsGabriel de Dietrich2016-08-175-41/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | NSMenu has autoenableItems set to true by default, and we keep it this way in Qt. This means that NSMenuItem's enabled property is basically ignored and therefore QCocoaMenuItem::syncModalState() is wrong. What is also wrong, is syncModalState()'s name in both QCocoaMenuItem and QCocoaMenu. Indeed, this function's role should be to ensure that the enabled state is properly propagated down the menu hierarchy, whether the reason is being in the context of a modal dialog or the parent menu having been disabled by the app. Notice that the latter case is specially needed when a menubar menu is explicitly disabled. Therefore, we introduce a separate flag for the parent enabled state in order to avoid polluting the app-set enabled state flag. This is done in both QCocoaMenu and QCocoaMenuItem. In the case of QCocoaMenuItem, these two flags define whether an NSMenuItem is enabled state conjointly, and set from -[QCocoaMenuDelegate validateMenuItem:]. The rest of the logic remains as before. Similar logic is used in QCocoaMenu::isEnabled(). In addition, the presence of the second flag allows us to show disabled submenus in the same fashion native Cocoa applications do. This means, the submenu item itself remains enabled, allowing to show the submenu popup where all its menu items will appear disabled. Bonus change: merged all the bool flags into a bitfield and made the compiler happy about the ivar reordering in QCocoaMenu and QCocoaMenuItem's constructor. Task-number: QTBUG-54698 Task-number: QTBUG-55121 Change-Id: Ie156cb3aa57a519103908ad4605f7b43c57e5aef Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com>
* Doc: Change instances of '(Mac) OS X' to 'macOS'Topi Reinio2016-08-121-1/+1
| | | | | | | | | | | | | | | As of version 10.12 (Sierra), the name of Apple's desktop operating system will be macOS. Change the occurrences where the Mac platform is discussed to use a macro \macos, which expands to 'macOS'. This helps with adapting to future renaming. Update the instructions on mac-specific Q_OS_* macro usage. Add a \target for the old 'Qt for OS X' topic to keep links working for other documentation modules that try to link with the old name. Change-Id: Id33fb0cd985df702a4ae4efb4c5fd428e77d9b85 Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
* Cocoa: Update deprecated dragging session APIsGabriel de Dietrich2016-08-111-10/+13
| | | | | Change-Id: I06e2dd3861c4bc5d85421ac71daf188732279e77 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com>
* Drag and Drop: Don't let Cocoa override proposed actionsGabriel de Dietrich2016-08-111-1/+9
| | | | | | | | | | | | When pressing the Command key, or any other modifier key, Cocoa will filter whatever the application has set in the QDrag object. However, Qt is already taking all this into account, so we should not let yet another voice chime in. Task-number: QTBUG-55177 Change-Id: I7c56e72d846d10cdfc132776bdfdd6b79799bcff Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com> Reviewed-by: Jake Petroules <jake.petroules@qt.io>
* HiDPI Drag and Drop: Properly render the default image on MacGabriel de Dietrich2016-08-091-1/+15
| | | | | | | | | | | | | | | | | This is only when the attached MIME data contains text, and we fall back to rendering that text into a pixmap. It requires getting the device pixel ratio from the source which, for now, may be a QWidget or a QWindow. Other cases may exist, but that would bring more dependencies than desired. Similarly, it fixes the draggabletext example. Other examples would require either to get updated pixmaps or change substantially in order to support HiDPI (e.g., the fridgemagnets example). Change-Id: I66198214233e3e06c87505744e2aaa9691fe1bb6 Reviewed-by: Filipe Azevedo <filipe.azevedo@kdab.com> Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com> Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* Cocoa integration - fix a crash in QMacPasteboardTimur Pocheptsov2016-07-252-13/+7
| | | | | | | | | | | | | | | | QMacPasteboard's dtor skips LazyRequest promises and this leaves pasteboard manager in broken state, since we release the pasteboard itself of the next step in destructor. As a result, not only Qt's app doing D & D (and thus via QCocoaDrag creating a stack-allocated QMacPasteboard) can die suddenly when somebody inspects a pasteboard, this 'somebody' ... can also die amazingly. So now we DO resolve promises using PasteboardResolvePromises (but we also preserve the original intent of not providing or providing empty data for lazy requests). Task-number: QTBUG-54663 Task-number: QTBUG-54832 Change-Id: I3ce90bd0a012dd3cbb30c93b2b17dce9473acb28 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* QCocoaMenuBar: Sync items only when they are attached to a menuGabriel de Dietrich2016-07-131-3/+5
| | | | | | | | | | | | | Another one of Cocoa's capricious behaviors. Evidence shows that the menu item's submenu property needs to be set before we can set the item's hidden property. We ensure this is the case by getting the NSMenuItem through QCocoaMenu::attachedItem() instead of QCocoaMenuBar::nativeItemForMenu() in QCocoaMenuBar::syncMenu(). Change-Id: Id50356dae5f556fa3d745ba9a5982e5a72bf0ac2 Task-number: QTBUG-54637 Reviewed-by: Jake Petroules <jake.petroules@qt.io> Reviewed-by: Jason Haslam <jason@scitools.com>
* QCocoaMenu: Attach late items to their submenuGabriel de Dietrich2016-07-082-2/+21
| | | | | | | | | | | | | | | | Because the QMenu::aboutToShow() signal is emitted way after -[QCocoaMenuDelegate menu:updateItem: atIndex:shouldCancel:], we miss the opportunity to attach the submenu to the menu item. The solution is to track the "open" state of the NSMenu. Then, if any submenu item gets added while the NSMenu is open, then we immediately attach the native item to the menu. Change-Id: I1f3a84ed3832520344da07e06cb3483ad6bd4ffd Task-number: QTBUG-54633 Reviewed-by: Jake Petroules <jake.petroules@qt.io>
* [macOS] Check that the screen's index is still valid after updatingAndy Shaw2016-07-082-1/+6
| | | | | | | | | | It is possible for a screen to be disconnected while it is doing an update of the available screens. Therefore before returning the pointer to the screen then it should be rechecked that the index is still within the range of available screens. Change-Id: Iaa08070e79a72cb309d8a24cea786a5dccf6b719 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com>
* QCocoaTheme: Remove unreachable codeGabriel de Dietrich2016-07-061-22/+2
| | | | | | | | | | | | | | The condition iconType != kGenericApplicationIcon is never false, therefore we will never execute the else statement. Consequently, overlyaIcon will always be null. This was triggered by the deprecation of ProcessSerialNumber related APIs since 10.9. Change-Id: If9eec1d2cc6e7e5b0c5323d4550f0c823a5eb0d8 Reviewed-by: Jake Petroules <jake.petroules@qt.io>
* Cocoa QPA: Mute mouse dragging warningsGabriel de Dietrich2016-06-044-3/+8
| | | | | | | | | | | | | | | While probably valid, these warnings are beyond the user's control, and more likely a sign of Qt's own expectations or misbehavior. So, we should not annoy the users with them. This change introduces the same logging category as 3ee01f74031d9e1d0 in 5.7 as is a partial backport to simplify a subsequent 5.6 to 5.7 merge. Change-Id: Ica2e3b1c5bc372923fd823b5d7d537d319835685 Task-number: QTBUG-42846 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com>
* Merge remote-tracking branch 'origin/5.6.1' into 5.6Liang Qi2016-06-021-3/+9
|\ | | | | | | | | | | | | | | | | | | | | | | This merge also blacklists a flaky tst_QGL::clipTest test on OpenSUSE 13.1. Conflicts: src/network/socket/qnativesocketengine_winrt.cpp tests/auto/opengl/qgl/BLACKLIST Task-number: QTBUG-53133 Change-Id: I14b431aa5a189b7dd1d3e2dfff767d15df20fde3
| * QNSView: Pass on the responder chain if deletion is pendingGabriel de Dietrich2016-05-201-3/+9
| | | | | | | | | | | | | | Change-Id: I7d098b61f6feb2ac38582c0efb1bbdf25a83e967 Task-number: QTBUG-53398 Reviewed-by: René J.V. Bertin <rjvbertin@gmail.com> Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* | Cocoa integration - fix QCocoaWindow::setContentViewTimur Pocheptsov2016-05-251-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - QCocoaWindow::setContentView calls -removeFromSuperView and this is not valid for a view that is a content view for a NSWindow: using it will release the view but not clear the window.contentView pointer. Set contentView to nil instead. Fixing this makes visible the second problem: - QNSWindowHelper in its -handleWindowEvent: can access content view and assumes it's QNSView - it is not always guaranteed and can result in invalid message sent to a view, we can use m_qtView instead (it will be nil if it has a type different from QNSView, the call will be noop then). Task-number: QTBUG-53325 Change-Id: I0472eba8165a04b6a3f81b2171b3bb9827ff5681 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* | QNSView: Reset the internal buttons state after dragging endsGabriel de Dietrich2016-05-241-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | We only track left and right mouse buttons when dragging. But some applications may do this with other mouse buttons. In this case, instead of tracking which button was pressed and which one was released, we just ask Cocoa for the current state. Change-Id: I0df7799b7ae6d7816377f881bc0ede867737d245 Task-number: QTBUG-53374 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com>
* | Merge remote-tracking branch 'origin/5.6.1' into 5.6Liang Qi2016-05-191-0/+2
|\| | | | | | | | | | | | | Conflicts: src/network/socket/qnativesocketengine_winrt.cpp Change-Id: I8edb72f8ba958d80c3d7993b3feaaae782ca8d9c
| * Merge 5.6 into 5.6.1Oswald Buddenhagen2016-05-124-24/+59
| |\ | | | | | | | | | Change-Id: I22003b840f1a7ac685a1ec3353d7e7dbd84c3953
| * | Cocoa integration - avoid dangling menuitem pointerTimur Pocheptsov2016-05-101-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since QCocoaMenu can live longer than its m_attachedItem pointer, this pointer is becoming invalid after QCocoaMenuItem deleted (and its 'm_native' was released). Task-number: QTBUG-53251 Change-Id: I6d97b75b2c09e2443cd21415c5db94206d5d89ce Reviewed-by: Frederik Gladhorn <frederik.gladhorn@theqtcompany.com> Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
* | | Use QPlatformTheme for the context to translate the color dialog buttonsAndy Shaw2016-05-161-1/+1
| |/ |/| | | | | | | | | | | | | | | | | QDialogButtonBox does not have translations, it queries QPlatformTheme for button texts. So in order to ensure that the buttons added to QColorDialog natively are translated it should be set to use QPlatformTheme instead. Change-Id: I67d0e509398aa81f9de9b8785544c1e23bb596d9 Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
* | QCocoaWindow - do not call resignKeyWindowTimur Pocheptsov2016-05-101-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | QCocoaWindow::setMouseGrabEnabled/setKeyboardGrabEnabled calls resignKeyWindow. According to Apple's docs, we should _never_ call this function (it's done by Cocoa automatically). Calling this function leaves a window in weird state where it can not become key again until you explicitly make another window key first. Task-number: QTBUG-53050 Change-Id: I7a887659df8df11880328ffa2adc07c4a3af63e6 Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io> Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* | Cocoa: Add QCocoaWindowPointerGabriel de Dietrich2016-05-063-19/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch extends 5b54c352edbc597ec5283bc9cfdd77906350161f by abstracting the watcher pattern. The class is specialized for QCocoaWindow since it's aware of the QObject sentinel there. We update the usage in QNSWindowHelper and extend it to the forward window (this one is used for mouse coordinate conversion when docking windows). Change-Id: I628415527593daec835bbad1b6e83d13fe7b6703 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com>
* | Cocoa: Clear the backing store pointer when changing windowGabriel de Dietrich2016-05-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the geometry is being changed at some point while showing the widget after reparenting, we set the Cocoa frame on the QNSView. This results in Cocoa invalidating the view and calling drawRect: before we get a chance to flush the backing store. This may be an issue if the previous parent toplevel window has been deleted. In that case, the backing store pointer is a dangling one, resulting in a crash. Change-Id: I18b5dd7794a3bde8815daf3f84e4113a37aaea90 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com>
* | QCocoaMenuBar: set the native item's titleGabriel de Dietrich2016-05-061-1/+3
|/ | | | | | | | | | | | | | | | | | | | Or, "Give Cocoa a Chance to do its Magic" Some menubar items, like the "Edit" menu, get extra items added at some point by Cocoa. Evidence points out to those extra items being added right after the NSMenu holding the menubar is set as the current menubar. At that point, both the child NSMenu and its NSMenuItem (the entry in the menubar) must have their title set. Therefore, we must set the menubar native item's title before QCocoaMenuBar::updateMenuBarImmediately() sets the main menu. Task-number: QTBUG-53085 Change-Id: Idd775cf0e3485739f38363a84cfed8d2db9cb662 Reviewed-by: Jake Petroules <jake.petroules@qt.io> Reviewed-by: Liang Qi <liang.qi@qt.io> Reviewed-by: Marko Kangas <marko.kangas@theqtcompany.com> Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com>
* Cocoa: Enable skipping Ctrl+LMB to RMB overrideGabriel de Dietrich2016-05-031-1/+5
| | | | | | | | | | This can be enabled with QT_MAC_DONT_OVERRIDE_CTRL_LMB=1 environment variable. The goal is to provide consistent cross-platform input when it's more desirable than full platform comformance. Change-Id: I3b96733077bd1c0367edeef21a98a44b15425807 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com>
* QCocoaMenu: Have the menu delegate return the right amount of itemsGabriel de Dietrich2016-04-271-1/+1
| | | | | | | | | | | | | In some cases we move menu items around, therefore we should not rely on QCocoaMenu::items() being the actual items inside the menu. But, since the NSMenu is updated before hand, we can rely on NSMenu.numberOfItems instead. Change-Id: Icd4497beca4f52a6d38408eeaa2e6ec71b579685 Task-number: QTBUG-52931 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com> Reviewed-by: Eike Ziller <eike.ziller@qt.io> Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* OSX: mark mouse events from tablet devices as synthesizedShawn Rutledge2016-04-262-6/+8
| | | | | | | | | This is equivalent to d7db6c6c1944894737babf3958d0cff1e6222a22 on the xcb platform. Task-number: QTBUG-51617 Change-Id: I837a764c8382244307ba6aa02bd8bde12bd08bff Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* Cocoa integration - add a protection against dangling pointersTimur Pocheptsov2016-04-222-2/+10
| | | | | | | | Backport watcher-sentinel trick (QPointer->QObject) from dev. Task-number: QTBUG-42059 Change-Id: I9b2c7cde635c2ed9a3f667f216da62870d0b5ccb Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* Fix gesture processing on OS X 10.11Timur Pocheptsov2016-04-151-1/+25
| | | | | | | | | | | | Starting from 10.11 beginGestureWithEvent/endGestureWithEvent never gets called, we must test event.phase instead (magnify/rotate gestures). For a magnify/rotate gesture, we'll first test phase (on 10.11) and manually call our begin/endGestureWithEvent. Task-number: QTBUG-48666 Change-Id: I69752b3c6578360b98607ceea2cffb5c166bb7c9 Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@theqtcompany.com> Reviewed-by: Morten Johan Sørvig <morten.sorvig@theqtcompany.com>
* OS X: Fix available geometry at startup when menu bar is hiddenTor Arne Vestbø2016-04-131-0/+9
| | | | | | | | | | | | | | | | Later versions of OS X allow you to auto-hide the menu bar, which should free up 22 pixels vertically at the top of the screen in the available geometry. Due to how the NSScreens are invalidated (asynchronously), we pick up this geometry change too late, resulting in QWindows maximizing as if the menu bar was still there. To work around this we explicitly tell the system to apply the default presentation options before initializing the QScreen properties, which results in the NSScreen being invalidated synchronously and having the right available geometry. Change-Id: I40d6ef2211165d53e0825173e3b6c6c17a5a954e Reviewed-by: Jake Petroules <jake.petroules@theqtcompany.com>
* QNSView: Disable focus ringGabriel de Dietrich2016-04-111-0/+1
| | | | | | | | | | | | | | Not only we don't need Cocoa to display it for us, but it also seems to take a lot of time after the call to -[NSView setNeedsDisplayInRect:]. While resizing a large and busy widgets window, we can decrease the relative time spent in -[QNSView flushBackingStore:region: offset:] from over 15% down to around 3%. Change-Id: I2a8d51be28b77c4c3da2588d9a14e461e7910167 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com> Reviewed-by: Morten Johan Sørvig <morten.sorvig@theqtcompany.com>
* QCocoaMenus: Use mix-in pattern to implement menu hierarchyGabriel de Dietrich2016-03-225-18/+34
| | | | | | | | | | | | | | | | | | | | | | To solve menu item roles from their text, we need to find its depth in the menubar hierarchy. Unfortunately, there's no trivial way to access that hierarchy from the QPA side, so we need to come with an ad-hoc solution. Previously, we were using a dynamic proprety to keep track of the 'parent' object. However, as the life span of the different objects has changed since 09acf326dbc6b7b67f21a36, we need a way to keep track of the parent's existence. This is what we do in this patch by having both QCocoaMenu and QCocoaMenuItem also inherit QCocoaMenuObject. This class' sole role is to store the menu hierarchy's parent object and wrap it in a QPointer. Change-Id: Ia18d95171af76d26f6325eef04c77b40d99c4285 Reviewed-by: Morten Johan Sørvig <morten.sorvig@theqtcompany.com> Reviewed-by: J-P Nurmi <jpnurmi@theqtcompany.com> Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com>
* QCocoaMenu: Decouple NSMenuItem from NSMenuGabriel de Dietrich2016-03-166-121/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While Cocoa requires an NSMenu to be coupled to an NSMenuItem (just as Qt requires a QMenu to be coupled to a QAction), making that a hard coupling comes with some limitations. This is because Cocoa won't allow the NSMenu object to be simultaneously coupled to more than one NSMenuItem and, similarly, an NSMenuItem can only be added to a single parent NSMenu. Therefore, it becomes difficult to share one QMenu between two different QMenuBars in different windows, or to use a QMenu as context menu while being accessible from the menu bar. Previous solutions to circumvent those limitations were less than ideal (see 119882714f87ffeb6945fdb2d02997ae125ff50c for the QMenuBar shared QMenu issue). Other workarounds that relied on that hard coupling, like 996054f5e65bc676aaea0743c2eacec51918e4aa, also added gratuitous complexity. In this patch, we break that hard NSMenuItem-NSMenu coupling, and we replace it with a temporary, looser coupling. As a consequence, * QCocoaMenu only contains and manages a NSMenu instance, removing the previously used NSMenuItem. It gets a temporarily attached NSMenuItem instead. * QCocoaMenuItem gains a safe pointer to its QCocoaMenu property removing the necessity containingMenuItem() in QCocoaMenu. * QCocoaMenuBar manages its own NSMenuItems. With this setup, we bind the NSMenu to its parent NSMenuItem at the last moment. In QCocoaMenuBar, when we call updateMenuBarImmediately(). In QCocoaMenu, we use the delegate's -[QCocoaMenuDelegate menu: updateItem:atIndex:shouldCancel:] method which is called when Cocoa is about to display the NSMenu. Note: There's still one use case we don't support, which is sharing a toplevel QMenuBar menu. This is because Cocoa's menu bar requires each of its menu items to have a submenu assigned, and therefore we can't rely on that last moment assignment. Task-number: QTBUG-34160 Task-number: QTBUG-31342 Task-number: QTBUG-41587 Change-Id: I92bdb444c680789c78e43fe0b585dc6661770281 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com>
* Compile with -no-openglMorten Johan Sørvig2016-03-151-0/+4
| | | | | | | | | | QCocoaBackingstore::toImage() can only be Q_DECL_OVERRIDE if QPlatformBackingStore::toImage() is present, which it isn’t for NO_OPENGL builds. Change-Id: Ib116f40fd26defb29a8d520d3e3fb104d8da8d57 Task-number: QTBUG-51694 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com>
* Cocoa: Fix crash on screen disconnect.Morten Johan Sørvig2016-03-151-3/+7
| | | | | | | | | | | | | | | | | | | | | Maintain virtual siblings list on screen deletion. QCocoaIntegration::updateScreens() has a loop which will delete all non-current QScreen objects using QPlatformIntegration::destroyScreen(). destroyScreen() vill eventually call QWindowPrivate:: setTopLevelScreen() which accesses the virtual siblings list for the deleted screen. This can cause a stale pointer access if the virtual screen list is not up to date, especially when disconnecting two screens at the same time. Change-Id: Ia6b9d01edf8e5eea25b64604a2b3b28b173125f7 Task-number: QTBUG-48275 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com> Reviewed-by: Morten Johan Sørvig <morten.sorvig@theqtcompany.com>
* Cocoa: Improve native view lifetime accuracy.Morten Johan Sørvig2016-03-111-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | Ideally all native NSWindows and NSViews owned by QCocoaWindow should be deallocated during the QCocoaWindow destructor. In reality this does not always happen since Cocoa is free to hold references to the views after Qt releases its reference. We can help Cocoa clean up: - Clear the first responder for the NSWindow under the ~QCocoaWndow() autoreleasepool. - Use an autoreleasepool to clean up temp objects from [NSWindow orderFront:] immediately. Together this makes the QNSView lifetime be contained by the QCocoaWindow lifetime, at least for simple QWindow usage. It also fixes the observed memory leak reported in QTBUG-51766 Change-Id: Idd224f54ebd6f61f274461a204ff30c666b22768 Task-number: QTBUG-51766 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com>
* consistently put {qt,qml}_{module,plugin} at the end of project filesOswald Buddenhagen2016-03-071-5/+5
| | | | | | | | this fixes static builds by ensuring that all dependencies are exported. Task-number: QTBUG-51071 Change-Id: Icbce502dcbcb4d4b4d922c42679f44e2cc930bf3 Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* QWheelEvent: make NoScrollPhase opt-inShawn Rutledge2016-03-051-0/+2
| | | | | | | | | | | | | | | | | | | | | | | The fix for QTBUG-50199 involves adding an undocumented enum value which can be returned from QWheelEvent::phase(). This will be quite unexpected for applications that use it, which work fine with 5.6.0 and then start receiving this new phase value in 5.6.1. So it should not happen by default. Set the env variable QT_ENABLE_MOUSE_WHEEL_TRACKING to enable this functionality. In 5.7 it will be default behavior. But in 5.6 the default behavior is as it was before: if you use a conventional mouse wheel, the phase stays at ScrollUpdate continuously. [ChangeLog][QtCore] QWheelEvent::phase() returns 0 rather than Qt::ScrollUpdate when the wheel event comes from an actual non-emulated mouse wheel and the environment variable QT_ENABLE_MOUSE_WHEEL_TRACKING is set. In Qt 5.6, this is required to enable the fix for QTBUG-50199. Change-Id: Ieb2152ff767df24c42730d201235d1225aaec832 Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@theqtcompany.com> Reviewed-by: Shawn Rutledge <shawn.rutledge@theqtcompany.com> Reviewed-by: Alex Blasche <alexander.blasche@theqtcompany.com>
* Cocoa integration - do not invalidate backing store on moveTimur Pocheptsov2016-03-041-1/+3
| | | | | | | | | If window is only moving, there is no reason to reset a backing store, otherwise with current expose/flush events machinery it's possible to have glitches while moving a window programmatically. Change-Id: Ia4408bd23388e529ae93617a92ae84304b707ca1 Reviewed-by: Morten Johan Sørvig <morten.sorvig@theqtcompany.com>
* QMacStyle and QCocoaTheme: Fix selected item color for non-native menubarGabriel de Dietrich2016-02-291-1/+3
| | | | | | Change-Id: I3b55e9ce896383338cf6ed768d912ca1835b7742 Task-number: QTBUG-28960 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com>
* Track target widget when wheel events are receivedGabriel de Dietrich2016-02-291-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This issue is reproducible on OS X when using a Magic Mouse or a combination of Magic Trackpad and regular mouse. In these cases it's possible to start a scrolling gesture on one widget and move the mouse cursor over another widget. Although we send the wheel event phase information, we never made any use of it. This means that a widget would start scrolling even though it never received a ScrollBegin event. In this patch, we make sure the scrolling cycle is respected and that once a widget starts scrolling, it'll be recieving all the wheel events until a ScrollEnd event reaches the application. For those input devices not supporting a proper phase cycle, we introduce a new (undocumented) phase value, NoScrollPhase. If the wheel event phase is NoScrollPhase, then we ignore the current scroll widget and proceed as usual. This value is the default for wheel events. It's up to the platform plugin to set the proper phase value according to the data received from the OS. Finally, we fix a few of QWheelEvent constructors to properly initialize the phase and source properties. Task-number: QTBUG-50199 Change-Id: I3773729a9c757e2d2fcc5100dcd79f0ed26cb808 Reviewed-by: Shawn Rutledge <shawn.rutledge@theqtcompany.com>
* QMacPrintEngine: Really set the printer resolutionKai Pastor2016-02-251-2/+11
| | | | | | | | | | | | | As already reported in 2009 (Qt 4.6) QPrinter never actually set the printer resolution. This change adds the necessary call to PMPrinterSetOutputResolution (available since OS X 10.5). [ChangeLog][QtPrintSupport][OS X] QMacPrintEngine now really sets the printer resolution. Task-number: QTBUG-7000 Change-Id: I3e851b62e1a7ed78564a8a6fd576b0a18d7eff63 Reviewed-by: Andy Shaw <andy.shaw@theqtcompany.com>
* QCocoaMenuItem: Use the right Objective C class forwarding macrosGabriel de Dietrich2016-02-191-11/+4
| | | | | Change-Id: Icdde469e6854c250d44c88fc79b7615647f0783a Reviewed-by: Jake Petroules <jake.petroules@theqtcompany.com>
* Merge remote-tracking branch 'origin/5.6.0' into 5.6Liang Qi2016-02-153-16/+21
|\ | | | | | | Change-Id: I0b190005377a23a91da3563428e223b8a3b18333
| * Merge 5.6 into 5.6.0Oswald Buddenhagen2016-02-023-141/+3
| |\ | | | | | | | | | Change-Id: I95962e28b6fc101cbbad41230585e2b61f1f6c0f
| * | Cocoa integration - fix outdated path in QCocoaFileDialogHelperTimur Pocheptsov2016-01-301-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we set accessory view sometimes (sic!) a delegate's callback fires: -panel:directoryDidChange: with an outdated path (probably because panels are shared?) resetting our current directory; later we open file dialog with a wrong path as result. Change-Id: Iffb02e801c44c5d9a62c2cca3acdf9278eaadb26 Task-number: QTBUG-50140 Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@theqtcompany.com>
| * | Accessibility OS X: Fix hang when editing password line editsFrederik Gladhorn2016-01-281-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes a regression when entering data in a password field. The important part is to simply not call convertLineOffset for single line text edits. The reason is that the function when dealing with password fields gets an empty string back when calling textAt etc. This is good since we don't want to leak passwords through a11y apis. The problem with the functions returning empty strings is that we end up in an infinite loop in convertLineOffset. Task-number: QTBUG-49437 Change-Id: I76faa7e33e3ad5c3aeb5c75d8c4b93f1b8227bfc Reviewed-by: Morten Johan Sørvig <morten.sorvig@theqtcompany.com>