summaryrefslogtreecommitdiffstats
path: root/src/gui/kernel
Commit message (Collapse)AuthorAgeFilesLines
* Fixed a crash with input methodsPierre Rossi2009-07-102-6/+3
| | | | | | | | | The inputContext's focusWidget was not reset when disabling input methods. Thanks to Benjamin P. Task-number: 257832 Reviewed-by: Denis
* Document limitation in Cocoa cursor handling.Norwegian Rock Cat2009-07-071-0/+5
| | | | | | | | | | It seems there is a bug in AppKit which will automatically reset a cursor even when it is grabbed, but won't reset it when it's brought back into the window. The upshot of this is that doing a setCursor() inside of mouse handling behaves slightly different than on the other platforms (including Carbon). However, we are at the mercy of Cocoa here and I would rather have all the other things AppKit does right and live with this bug which they may fix some day.
* Fix typo in color calculation.Norwegian Rock Cat2009-07-071-3/+3
| | | | | | | | | Argh! It's divide by 256 not 265. The worst part was that I used the same values in Cocoa as well, so they were both "damaged." It should be good now. Task-number: 257499 Reviewed-by: Prasanth Ullattil
* Fix issue where a mainwindow would show two size grips in Cocoa.Norwegian Rock Cat2009-07-061-2/+5
| | | | | | | | | | | | | | | | | | | OK. this is a bit strange. It seems the topdata->resizer value is used to control whether or not we should show a resize handle based on a count (0 no, non-zero yes). Since we somehow decided that this value will never be larger than 15, we made it 4-bits wide. There's a "Qt/Mac" API, QWidgetPrivate::qt_mac_update_sizer(QWidget *, int = 0) which would adjust this value by the int passed in.. We use that in several places, not excluding the QStatusBar where we would pass 1 if we want to show, and -1 if we didn't. Now if you subtract -1 from zero when you are 4 bits wide, well, bad things happen. Therefore protect that (since if it's at zero we have succeeded, we don't want to show the resizer). This seems to work well. The private API is certainly an interesting way of solving the problem, but is easy to abuse (for example, this code will break if resizer = 1 and we are passed -2 in the function. Task-number: 257485 Reviewed-by: Prasanth Ullattil
* Implement QApplication::setOverrideCursor to use pure Cocoa callsNorwegian Rock Cat2009-07-061-1/+11
| | | | | | | | | | | Seems this was a victim of our cursor fixing. Cocoa does a lot for us with setting cursors. This meant that we didn't need to do as much meddling and as a result qt_mac_set_cursor does nothing in Cocoa. Unfortunately, this broke setOverrideCursor. Luckily Cocoa has a stack that works exactly like Qt, so we can just use that. Task-number: 257507 Reviewed-by: Prasanth Ullattil
* Remove unused function viewUnderTransparentForMouseView in QCocoaView.Prasanth Ullattil2009-07-022-57/+0
| | | | | | | After we implemented hitTest for QCocoaView, this function is no longer used. Reviewed-by: Norwegian Rock Cat
* Drag and drop events are not delivered correctly in CocoaPrasanth Ullattil2009-07-022-8/+43
| | | | | | | | | | | Drag and drop events should consider the WA_TransparentForMouseEvents attribute like the mouse events. If this attribute is set for a widget, the event has to be passed to right widget under mouse. The widget is identified by calling hitTest. In such cases the leave event has to be delivered to the widget which actually accepted the enter event. Task-number: 252088 Reviewed-by: Norwegian Rock Cat
* Implement hitTestNorwegian Rock Cat2009-07-022-54/+7
| | | | | | | | | | | | | | | Cocoa calls hitTest on our view to determine if the view should get the mouse press. We always said, "yes" and did all the logic ourselves. Turns out that we can say "no" if I'm transparent to mouse events and remove all that code where we do all the work ourselves. Big maintenance win! For the time being I've kept the "transparentViewForEvent" method since it might be useful for others, but no one is using it at the moment and we may just kill it soon. HitTest should handle this situation correctly.
* Fix a regression where dynamic tooltips wouldn't show up in Cocoa.Norwegian Rock Cat2009-07-022-4/+15
| | | | | | | | | | | | | | Tracking of mouse events was only enabled when enableMouseTracking or Hover or a tooltip had been set explictly on the item, but this meant that the dynamic QEvent::Tooltips would never get dispatched. So, in order to help out people that might use this feature, all QCocoaViews must pay the mouse move event tax *sigh*. I added comments in the proper places so that we DO the right thing for a release where we can force the change in behavior. Task-number: 257320 Reviewed-by: Denis
* Fix Toolbars in unified toolbar looking bad Carbon w/Fullscreen changesNorwegian Rock Cat2009-06-301-2/+17
| | | | | | | | | | | | | | | There was a bug in the Carbon code when an item went in full-screen, than out with a unified toolbar. In those cases the toolbars would end up getting but into the mainwindow area. The reason this was happening was that we were calling transferChildren() after we had set up our toolbar. This cause problems because we end up pulling the QToolbars right out of the unified toolbar. The easiest way to solve this is to just update the status on it again. This should solve any issues. I also added some logic to avoid calling this too many times in that one case. Luckily, this seems to only affect Carbon. Task-number: 254462 Reviewed-by: Jens Bache-Wiig
* Doc: About menu on the Mac gets the application name from Info.plist.Geir Vattekar2009-06-301-1/+3
| | | | | Task-number: 256818 Reviewed-by: Trenton Schulz
* QWidget::adjustSize() sends a spontaneous event - Mac OS X CocoaPrasanth Ullattil2009-06-302-2/+12
| | | | | | | | The windowDidResize notification now differentiates an internally triggered resize from a user triggered resize. Task-number: 256269 Reviewed-by: Norwegian Rock Cat
* Always turn on shadows for Cocoa.Norwegian Rock Cat2009-06-291-2/+1
| | | | | | | | | | | | Frameless windows wouldn't get shadows in Cocoa, which they do in Carbon. You can argue over who is more correct, but the fact is they can't be inconsistent. Since Cocoa is the newcomer, I'm bending that. Though it would seem useful to have an ability to provide some developer control over the shadow. At the moment, the only thing we have to ensure is that we always turn on the shadow. Task-number: 254725 Reviewed-by: Denis
* Fix painting errors in QScrollArea on Mac (Carbon)Morten Sørvig2009-06-261-2/+2
| | | | | | | | | | | | | | | This is mainly a stop-gap solution for 4.5.x. It trades painting performance for correct painting. Commit 7988d05da changed the opaque test from q->testAttribute(Qt::WA_OpaquePaintEvent) to qt_widget_private(w)->isOpaque in qt_mac_update_widget_posisiton. This means we'll do optimized moves in more cases. Unfortunately it also causes painting errors in some cases (see the task). Revert the commit for now to put the 4.5 branch in a god shape. Task-number: 252295 Reviewed-by: nrc
* Remove some warnings in the Cocoa build.Norwegian Rock Cat2009-06-236-18/+50
| | | | | | | | | | After discussing with some of the Objective-C people I have finally got a fair number of the warnings to disappear in both 10.5 and 10.6. I also took the opportunity to remove a bunch of other warnings. Reviewed by: Morten Sørvig
* Cleanup our usage of the term "Qt Software".Jason McDonald2009-06-161-3/+3
| | | | Reviewed-by: Trust Me
* Update license headers as requested by the marketing department.Jason McDonald2009-06-16151-302/+302
| | | | Reviewed-by: Trust Me
* Rename nsCursorForQCursor -> qt_mac_nsCursorForQCursor.Morten Sørvig2009-06-154-4/+4
| | | | Reviewed-by: Richard Moe Gustavsen
* Copy-paste didn't work for application on non-first screen in multiscreen setup.Denis Dzyubenko2009-06-112-8/+14
| | | | | | | | | | | | We need to subscribe to xfixes selection notify events on all available screens. Also implemented delayed subscription to xfixes events since we don't really need clipboard change notifications unless the application explicitely asked for by (i.e. created a qclipboard object). Task-number: 255609 Reviewed-by: Bradley T. Hughes
* Doc fix: add a link to focus() and focusWidget() from QWidget::setFocus ↵Denis Dzyubenko2009-06-111-2/+2
| | | | | | documentation. Reviewed-by: TrustMe
* Compilefix for QT_NO_TABLETEVENT and QT_NO_COMPLETERThomas Hartmann2009-06-101-2/+4
| | | | | Task-number: 253086 Reviewed-by: Joerg
* 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
* Avoid a crash when setting a focus in a widget hierarchy containingDenis Dzyubenko2009-06-021-2/+3
| | | | | | | | | | | | both visible and invisible widgets. This is a quick hack to avoid a crash in Qt when setting a focus on a visible widget that has invisible parent. Proper fix was committed into master 1a7da7096bbda17197738061902f4489af234bc0, see it's description for more details. Task-number: 254563 Reviewed-by: Thierry Bastian
* 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
* Fixes possible infinite loop in QApplication::topLevelAtJoão Abecasis2009-06-021-4/+4
| | | | | KDE Bug: https://bugs.kde.org/show_bug.cgi?id=191759 Reviewed-by: Bradley T. Hughes
* Remove unused variable.Alexis Menard2009-05-291-1/+0
|
* Scroll the dirty region with WA_PaintOnScreenBenjamin Poulain2009-05-281-0/+2
| | | | | | | | When QWidget::scroll() is called on a widget with WA_PaintOnScreen, scroll the dirty region. Task-number: 254742 Reviewed-by: bnilsen
* BT:Fix access of deleted memory with a static QCursor.Michael Goddard2009-05-261-1/+3
| | | | | | | | | If a QCursor with a predefined shape is declared static, it could be destroyed after the application dtor has already cleaned up QCursor memory. Task-number: 254467 Reviewed-by: Rhys Weatherley
* Doc: Removed documentation about the non-existentDavid Boddie2009-05-251-2/+0
| | | | | | | QKeyEvent::standardKey() function. Task-number: 254074 Reviewed-by: Trust Me
* BT: Namespace compile fixes.Norwegian Rock Cat2009-05-252-1/+2
| | | | | This broke again. I Need to get a way to automate this, I'll discuss with QA.
* BT: fix systray balloon crash bug on Windows CEJoerg Bornemann2009-05-251-13/+16
| | | | | | | | | | | | Its the context menu handling code... again. Problem is, that during execution of translateMouseEvent, the widget is closed and a modal message box is shown. After that, there's no widget at globalPos and thus, alienWidget is null. This patch just adds a null check for alienWidget. Task-number: 254425 Reviewed-by: mauricek BT: yes
* BT: Prevent crash in Designer when using a scroll wheel to change a property.Norwegian Rock Cat2009-05-251-8/+20
| | | | | | | | | | | There was some strangeness happening here with parents, but the main problem was the fact that wheel was getting sent to the focusframe and not to the widget below. However, the focusframe has the "transparent for mouse events" flag set and wheel events probably should be transparent as well. Task-number: 253539 Reviewed-by: Richard Moe Gustavsen
* Fix a crash where QCocoaWindow get events after its widget is deadNorwegian Rock Cat2009-05-202-5/+19
| | | | | | | | | | | | | | | The invariant that QCocoaWindow's lifetime is contained in a QWidget is simply not true. A top-level QWidget gets associated with a QCocoaWindow (which is reference counted). However, it can be the case that we've destroyed our QWidget, the link is removed, the window is hidden, but the window still gets an event. In that case we would crash with an eventual null pointer access. However, we don't really need to do anything in this case, so just call super and return. Task-number: 253402 Reviewed-by: Morten Sørvig
* Fix some typos in the documentation.Frederik Schwarzer2009-05-182-2/+2
| | | | | | Usually, "the the" is not proper English Reviewed-By: Thiago Macieira
* Prevent a crash with brushed metal windows and a qApp style sheetNorwegian Rock Cat2009-05-181-4/+17
| | | | | | | | | | My great metal hack simply needs to hack more and not do the "extra" assign since I'm doing this through a back door in set attribute. We probably should have had the brushed metal go via an actual QStyle subclass instead of through the attribute. Task-number: 253448 Reviewed-by: ogoffart
* 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
* Fixed regression that prevented any widget from having focus when graphics ↵jasplin2009-05-141-4/+2
| | | | | | | | | | | view was disabled. A bug in Commit d5c018f7b014ab794e49d6e1f24e02233555847d prevented any widget from having focus when QT_NO_GRAPHICSVIEW was defined. This patch fixes the bug. Reviewed-by: bnilsen Task-number: 249589
* 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
* Fixed bug with Qt::WidgetWithChildren shortcut context in QGraphicsWidget.jasplin2009-05-121-0/+1
| | | | | | | | | For a QGraphicsWidget w, a shortcut with Qt::WidgetWithChildren context would trigger even if w did not have focus (provided no other widgets in the view had focus). Reviewed-by: andreas Task-number: 250119
* Explaining details in QKeyEvent consruktor signatureMorten Engvoldsen2009-05-111-6/+7
| | | | | | | Explained the role of the key attribute. Task-number:246839 Rev-by: Richard Moe Gustavsen
* qdoc: Moved platform-specific qdoc comments to common .cpp file.Martin Smith2009-05-082-13/+14
| | | | | | | | | When building docs for the mac, qdoc comments for functions defined in the .h file were not found in any of the .cpp files in the mac package because they were in the x11 or windows .cpp file. So I moved them to a .cpp file that is in all the packages. Task-number: 252496 252492
* handle the back soft key on Windows mobile SmartPhonesJoerg Bornemann2009-05-071-0/+15
| | | | | | | | | We must tell the system that we want to intercept the back key on Windows mobile. Each toplevel widget that needs correct back key behaviour needs to have a menu bar. Why? Ask Microsoft... Task-number: 248846 Reviewed-by: thartman
* qdoc: Moved platform-specific qdoc comments to common .cpp file.Martin Smith2009-05-074-119/+131
| | | | | | | | | When building docs for the mac, qdoc comments for functions defined in the .h file were not found in any of the .cpp files in the mac package because they were in the x11 or windows .cpp file. So I moved them to a .cpp file that is in all the packages. Task-number: 252496 252492
* Fix strange context menu related bug on Windows MobileThomas Hartmann2009-05-071-2/+7
| | | | | | | Fixes 245347 again and does not trigger 252319 Task-number: 245347 Reviewed-by: Maurice
* Crash in QWidget::render when passing an untransformed QPixmap painter.Bjoern Erik Nilsen2009-05-061-1/+1
| | | | | | | | | | | | | | | | | | | The crash only occurred on Windows and X11 when running with -graphicssystem raster. The reason is that the actual paint device in QRasterPaintEngine::begin() is changed to pixmap->data->buffer(), which means QPaintEngine::paintDevice() returns something else than what it was told to paint on (see cb0c899b56b84154f69ddc545991bc6ded96ab01) The root of the problem, however, was that we used a weird condition (painter->worldMatrixEnabled(), added in 345072b9 for Qt 4.4) to find the target device. We did that because the shared painter was completely different in 4.4. We refactored it in 4.5.0, and we can only trust QPaintEngine::paintDevice to be the target device. Auto-test included. Task-number: 252837 Reviewed-by: Trond
* Optimize QCocoaView::registerDragTypes and mode switching in QtCreator.Morten Sørvig2009-05-063-8/+17
| | | | | | | | | | | | 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
* QComboBox: Click-drag-release does not work for combo boxes using CocoaRichard Moe Gustavsen2009-05-061-4/+19
| | | | | | | | | | The problem is that the mouse event was redirected to the active pop-up, while it should have been redirected to the widget under the mouse under the active popup. This patch does the correct redirection Task-number: 252259 Reviewed-by: Trenton Schulz
* Mac OS X QWidget::setMinimumSize locks.Richard Moe Gustavsen2009-05-062-43/+46
| | | | | | | | | | | 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
* Make command-quit not terminate the program on Qt/Cocoa.Morten Sørvig2009-05-051-3/+6
| | | | | | | | Instead instigate the quit by calling QApplication::quit(), using the code that was already in place. This allows QApplication::exec() to return normally and prevents resrouce leaks for objects created on the stack in main(). Reviewed-by: nrc
generated by cgit v0.12 at 2024-12-04 08:21:08 (GMT)