summaryrefslogtreecommitdiffstats
path: root/src/gui/kernel/qwidget_mac.mm
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'master' of git@scm.dev.nokia.troll.no:qt/qtBradley T. Hughes2009-06-241-174/+94
|\ | | | | | | | | Conflicts: src/gui/kernel/qapplication_x11.cpp
| * More culling of Panther Code.Norwegian Rock Cat2009-06-231-160/+91
| | | | | | | | | | | | Removed lots of places where we check for Tiger. Now we can assume it. Reviewed-by: Morten Sørvig
| * Scroll the dirty parts of the scroll area in scrollby for Cocoa.Norwegian Rock Cat2009-06-231-14/+3
| | | | | | | | | | | | | | | | | | | | | | | | Ah! One less ###! The scroll functions in Carbon and Cocoa don't scroll the regions that have been marked dirty. In the past, we killed performance by updating the whole view. We got a workaround for Carbon in the form of an SPI, but I wasn't aware of a corresponding item in the NSView API, but it is there publically and available in 10.5. Fast scrolling in Cocoa now for people who like to use the keyboard. Reviewed by: Morten Sørvig
* | Multitouch, Cocoa: First revision of multi touch in Qt/CocoaRichard Moe Gustavsen2009-06-191-1/+19
|/
* Merge license header changes from 4.5Volker Hilsheimer2009-06-161-2/+2
|\
| * Update license headers as requested by the marketing department.Jason McDonald2009-06-161-2/+2
| | | | | | | | Reviewed-by: Trust Me
* | Merge commit 'origin/4.5'Oswald Buddenhagen2009-06-081-5/+8
|\ \ | |/ | | | | | | | | | | | | Conflicts: src/3rdparty/phonon/qt7/mediaobject.mm src/3rdparty/phonon/qt7/quicktimevideoplayer.mm src/gui/text/qfontengine_win.cpp tools/linguist/shared/cpp.cpp
| * Revert "BT: Fixed crash on Mac caused by erroneous handling of native focus ↵jasplin2009-06-051-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | events." This reverts commit 7314c07a3e443b1d5349b419a03db8d41ca43f7e. As reported by Eike, this patch caused several problems for Qt Creator. Potentially it may cause problems for other (external) applications as well. An alternative fix (scheduled for 4.5.x) needs to be found for tasks 254456 and 254460. Reviewed-by: Richard Moe Gustavsen
| * Example MDI: keybord focus not working correctly!Richard Moe Gustavsen2009-06-051-1/+7
| | | | | | | | | | | | | | | | | | The reason is that cocoa looses the first responder when we raise the fake window inside the MDA area. So we need to re-set the first responder again Task-number: 255040 Reviewed-by: Trenton Schulz
* | Merge branch '4.5'Denis Dzyubenko2009-06-021-1/+4
|\ \ | |/
| * BT: Fixed crash on Mac caused by erroneous handling of native focus events.jasplin2009-06-021-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Mac, a widget with a NoFocus policy could still get focus (if only temporarily) as the result of a native focus event. In particular, a line edit with a completer should not lose focus (if only for a brief moment) as a result of the completer popup being shown. This will for example cause an item delegate to think that the user has navigated away from the cell and delete the line edit as a result. This will in turn cause the completer to access a null pointer. Reviewed-by: Richard Moe Gustavsen Task-number: 254456 and 254460
* | Merge commit 'origin/4.5'Olivier Goffart2009-05-181-2/+2
|\ \ | |/ | | | | | | | | | | Conflicts: src/corelib/kernel/qobject.cpp src/corelib/kernel/qobject_p.h src/network/access/qhttpnetworkconnection.cpp
| * Cocoa: Window flickers when resized with a QTabWidgetRichard Moe Gustavsen2009-05-151-2/+2
| | | | | | | | | | | | | | | | | | Seems like we were not using the correct functions for setting the max/min size on a cocoa window. The version we used before included the unified toolbar, which is wrong. The new one does not. Task-number: 252642 Reviewed-by: Trenton Schulz
* | Merge branch '4.5'Thiago Macieira2009-05-141-10/+0
|\ \ | |/ | | | | | | Conflicts: tools/macdeployqt/shared/shared.cpp
| * Sheets misbehaviour on Carbon - Mac OS XRichard Moe Gustavsen2009-05-141-10/+0
| | | | | | | | | | | | | | | | | | | | Seems like some old legacy code was left behind when sheets behaved as application modal. This is not the case anymore, so this patch just removes the special case code for enforcing the old behaviour, and let carbon do the correct thing instead. Task-number: 252379 Reviewed-by: Trenton Schulz
* | Ensure that sheets are hidden if the parents are hidden in Carbon.Norwegian Rock Cat2009-05-131-0/+14
| | | | | | | | | | | | | | | | Seems to work correctly in Cocoa, but we need to handle this special case in Carbon ourselves. Task-number: 253324 Reviewed-by: Richard Moe Gustavsen
* | Cleanup private QWidget functions.Bjørn Erik Nilsen2009-05-121-18/+0
| | | | | | | | | | | | | | | | I actually found a few functions that were not even implemented, only declared. Those should obviously not be in the header file. I've also removed a few functions not in use / not belonging to QWidgetPrivate. Reviewed-by: Olivier
* | Reduce QWidget footprint and do some cleanup.Bjørn Erik Nilsen2009-05-121-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch cleans up several things, like bit fields that are interleaved with with other variables, resulting in bits not being packed properly. Example: "uint a : 8; int c; uint b: 8;" -> "uint a : 8; uint b : 8; int c;" In that case we'll use 12 bytes instead of 8 bytes. I've also changed the order we declare certain variables to avoid unnecessary gaps/padding on 64-bit architectures. Example: "char *a; int c; char *b;" -> "char *a; char *b; int c;" Pointers are 64-bit aligned, so padding appears between 'c' and 'b', resulting in a total use of 24 bytes instead of 20 bytes. ...and since I anyways was moving the code around, I took the opportunity to add some overall structure by first declaring cross-platform functions/variables followed by platform specific functions/variables. ...and it was kinda scary to actually be able to see all the QStrings, pointers and whatnot we put into QWidgetPrivate. I'm sure we can remove lots of stuff, but I'll do that in a separate commit. Quick numbers (X11/64 bit): sizeof(QWidgetPrivate) == before: 472, after: 456 sizeof(QTLWExtra) == before: 112, after: 104 sizeof(QWExtra) == before: 152, after: 144 Acked-by: Olivier
* | Merge branch '4.5' of git@scm.dev.troll.no:qt/qtSimon Hausmann2009-05-061-2/+2
|\ \ | |/ | | | | | | | | Conflicts: src/gui/kernel/qcocoaview_mac_p.h src/gui/widgets/qmainwindow.cpp
| * Optimize QCocoaView::registerDragTypes and mode switching in QtCreator.Morten Sørvig2009-05-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | We were registering the types each time drag and drop was enabled, which caused slowdowns when for example switching between the Edit and Debug modes in QtCreator. Instead, register the types on first enable and also when the custom types change. Add check to draggingEntered() that disables the drag if WA_DropSiteRegistered is false. Reviewed-by: nrc
| * Mac OS X QWidget::setMinimumSize locks.Richard Moe Gustavsen2009-05-061-42/+44
| | | | | | | | | | | | | | | | | | | | | | There was code for updating the size constrains inside setConstraints_sys. This is now added. Factored out the code that does this into a function, and since we never applied size constraines on a window upon creation, I also added an extra call from that code part Task-number: 219695 Reviewed-by: Trenton Schulz
* | Mac: QWidget::setMinimumSize does not workRichard Moe Gustavsen2009-05-041-42/+44
| | | | | | | | | | | | | | | | | | The reason is that we never applied the new max min values on the native window itself. This patch does that, and also makes sure that we do this on the appropriate times (window creation, etc) Task-number: 219695 Reviewed-by: Trenton Schulz
* | Merge branch '4.5' of git@scm.dev.nokia.troll.no:qt/qtSimon Hausmann2009-04-291-2/+23
|\ \ | |/
| * Cocoa: qwidget auto test fails (windowMoveResize)Richard Moe Gustavsen2009-04-281-2/+23
| | | | | | | | | | | | | | | | | | | | | | | | The test fails because, in cocoa, when resizing a window to zero (either w or h), cocoa will also move the window up in the corner (!). So the fix is to issue an extra move back to it's true location after the resize. The faulty cocoa move is issued inside the resize callback, so we choose to not update the window location anymore from a pure resize callback. Task-number: 251895 Reviewed-by: Trenton Schulz
* | Merge branch '4.5' of git@scm.dev.nokia.troll.no:qt/qtSimon Hausmann2009-04-231-39/+49
|\ \ | |/ | | | | | | | | | | Conflicts: src/corelib/global/qfeatures.h src/gui/painting/qtransform.cpp util/scripts/make_qfeatures_dot_h
| * Carbon/Cocoa: It is possible to resize a widget above its maximum sizeRichard Moe Gustavsen2009-04-231-39/+49
| | | | | | | | | | | | | | | | | | | | This is not strange since we never did anything to limit a resize within the max min boundries. This patch factores out the code that ensures this into a private function that is called both as a reaction to a resize event, but also if resize is done programatically. Task-number: 251893 Reviewed-by: Trenton Schulz
* | Merge branch '4.5'Thiago Macieira2009-04-201-1/+4
|\ \ | |/ | | | | | | Conflicts: tests/auto/qaction/tst_qaction.cpp
| * BT: Fix a crash when using Q(File)Dialog::open() in QCocoa.Norwegian Rock Cat2009-04-201-1/+4
| | | | | | | | | | | | | | | | If we don't have a sheet, we need to recreate it in Cocoa. Unfortunately, we neglected to reassign the NSWindow pointer in that case, so the program would crash. Reviewed-by: Richard Moe Gustavsen
* | Merge branch '4.5' of git@scm.dev.nokia.troll.no:qt/qtSimon Hausmann2009-04-171-3/+14
|\ \ | |/ | | | | | | Conflicts: tests/auto/qpainterpath/tst_qpainterpath.cpp
| * BT:Stop widgets disappearing in unified when clicking the toolbar buttonNorwegian Rock Cat2009-04-161-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The comment in the code pretty much says it all, so I'll repeat it: This is a workaround for NSToolbar. When a widget is hidden by clicking the toolbar button, Cocoa reparents the widgets to another window (but Qt doesn't know about it). When we start showing them, it reparents back, but at this point it's window is nil, but the window it's being brought into (the Qt one) is for sure created. This stops the hierarchy moving under our feet. Task-number: 251294 Reviewed-by: Prasanth Ullattil
| * Remove some warningsNorwegian Rock Cat2009-04-161-2/+2
| | | | | | | | These aren't used in Carbon, so don't reference them.
* | Merge commit 'origin/4.5'Olivier Goffart2009-04-151-0/+17
|\ \ | |/ | | | | | | Conflicts: src/gui/graphicsview/qgraphicsitem.cpp
| * Fix a bug where a widget would not always get the correct Cursor in CocoaNorwegian Rock Cat2009-04-141-0/+14
| | | | | | | | | | | | | | | | | | | | Cocoa has a different way of dealing with cursors than our heavy handed approach that we used in Carbon. We simply need to re-implement the proper function in NSView and set up the rectangles for the cursor correctly. We also need to expose an QCursor2NSCursor type functions since the current QCursor::handle() is useless for doing this and we shouldn't change that. With this change things seem to work much more like the native stuff for both Carbon and Cocoa.
| * Cocoa: dialogs are sometimes not shown if triggered from outside the appRichard Moe Gustavsen2009-04-141-0/+3
| | | | | | | | | | | | | | | | | | | | NSPanels are set to hide when the application becomes inactive by default. This is not what we wan't for normal dialogs in Qt. This patch makes this setting explicit, in case the window we're about to create is a dialog. Task-number: 250869 Reviewed-by: Trenton Schulz
* | Merge commit 'origin/4.5'Bjoern Erik Nilsen2009-04-071-0/+14
|\ \ | |/ | | | | | | | | | | | | Conflicts: src/gui/graphicsview/qgraphicsitem.cpp src/gui/graphicsview/qgraphicsitem_p.h src/gui/graphicsview/qgraphicsscene.cpp src/gui/painting/qtransform.cpp
| * BT: Fix regression when tooltips dissappear suddenly in Unified toolbarNorwegian Rock Cat2009-04-071-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QWidget::childAt() makes some assumptions about its children (they are all contained in its geometry). This does not hold up when using the unified toolbar because the toolbar ends up in the "non-client" area. So, when dispatching an enter/leave event in tooltip show, we end up dispatching to the wrong widgets and that results in the tooltip cleverly thinking that it needs to hide itself because we've left the widget that needs the tooltip. I've special cased this by just having a "native" mapFromParent() that is only called for on the mac, though there is nothing that is limiting this from being called on other platfroms. Also QWidget::mapFromParent() probably needs to be looked at at some point. Task-number: 248048 Reviewed-by: Richard Moe Gustavsen
* | Merge branch '4.5' of git@scm.dev.nokia.troll.no:qt/qtSimon Hausmann2009-04-061-7/+5
|\ \ | |/
| * BT: Fix a crash when running a widget window modal when it has no parentNorwegian Rock Cat2009-04-061-7/+5
| | | | | | | | | | | | | | | | We changed the logic for determining sheets, but it seems we forgot to take the parentWidget() into account. It's required for WindowModality to make any sense. Reviewed-by: Richard Moe Gustavsen
* | Consistency between Carbon and Cocoa with fullscreen mode.Norwegian Rock Cat2009-03-301-11/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | On Carbon, we did show/hide menubar, on Cocoa we used SetSystemUIMode. But SetSystemUIMode is available to both, so why not just do that and make everything consistent. We now act more like other fullscreen apps (i.e., we show the menu and dock when the mouse is close to them). The good thing is that it should be easier to override this behavior as well. I also removed some code in our mouse handler where we were calling HideMenuBar as I don't see a great reason for it at the moment in any case, it would be inconsistent between Carbon and Cocoa. Task-number: 249655 Reviewed-by: Prasanth Ullattil
* | Call documented API.Norwegian Rock Cat2009-03-301-11/+2
|/ | | | | | | | | We were using the older CGSSetWindowAlpha function, which really is not well advertised. Instead, Apple eventually added SetWindowAlpha, but we neglected to update. May as well do that now skip the wrath of a change in the private API. Task-number: 244629
* Fix a bug where lineedits in a second page of a stack widget would not get ↵Norwegian Rock Cat2009-03-261-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | key events. We need to be more explicit in setting the first responder, and a bit more agressing about rejecting it when called with no responder. It seems that Cocoa has a tendency to reset the first responder when lots of widgets get hidden or shown. During this it will call "makeFirstResponder" on the window with a nil responder. Doing this will reset our what Cocoa thinks is the focus widget, but Qt will still show a focus widget. The way to solve it is to reject the make first responder if the responder is nil. I'm not sure if there will be far reaching implications for this, but it seems to be doing the right thing at the moment. We also need to share this code between QCocoaWindow and QCocoaPanel. Thanks to the dynamic nature of objective-C we have to have a copy of the code in both places. It's unfortunate. Finally, it's also important to have the QWidget let Cocoa know it has focus after it has been created. So, make sure that is in sync. Task-number: 249296 Reviewed-by: Prasanth Ullattil
* Long live Qt 4.5!Lars Knoll2009-03-231-0/+4842