summaryrefslogtreecommitdiffstats
path: root/src/gui/kernel
Commit message (Collapse)AuthorAgeFilesLines
* 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
* On Windows loosing focus should result in clearing focus if widget is ↵Denis Dzyubenko2009-05-051-1/+3
| | | | | | | | | | | embedded somewhere. If a widget is embedded to non-Qt window on Windows, then we should still clear the focus whenever we receive WM_KILLFOCUS since we won't get WM_ACTIVATEAPP in this case. This is an addition to 6ed196051d0f19bfe2d045eaf12f5f5ca30670d0 Task-number: 251259 Reviewed-by: Thierry
* Added a check that X11 timestamp goes forward only.Denis Dzyubenko2009-05-041-15/+20
| | | | | | | | Got a case somehow with a timestamp of the mouse event that is less than the timestamp we already had, so we need to make sure time only goes forward. Reviewed-by: Brad
* Ensure that we send the Apple Events even when Cocoa isn't ready.Norwegian Rock Cat2009-05-042-11/+23
| | | | | | | | | | | | | | In general, Cocoa handles the the Apple Events for us. However, this is time between creating the NSApplication and Cocoa has set everything up, usually after the event loop is running. This means that until that time, the events are dropped on the floor :-/. The workaround is to use the same handler that we use for Carbon, but to only have it enabled for until Cocoa is ready to handle things. This will result in not stepping on the toes when used in a plugin (if it does, we can conditionalize it). Task-number: 252795 Reviewed-by: Richard Moe Gustavsen
* Wrong clip in QWidget::render(QPainter *, ...) when using Qt::(Replace|No)Clip.Bjoern Erik Nilsen2009-04-291-2/+7
| | | | | | | | | | | | | | | The problem was that we didn't take the painter's clip into account when setting the system viewport ("hard clip"). We only used the system clip, but we have to use system clip + painter clip, which is the current engine clip. Unfortunately, we have to calculate it again since there's no cross-platform way of retrieving it. This was only a problem with Qt::(Replace|No)Clip, since we in all other cases combine the old clip with the new one. (Uber cool) auto test included. Task-number: 250482 Reviewed-by: Samuel
* Corrected description of the QLayout::takeAt() functionMorten Engvoldsen2009-04-291-1/+1
| | | | | | | An item is not deleted when removed from the index. The remaining items get a new index. I changed deleted to removed. Tasknumber: 252547 Rev-by: janarve
* Don't send extra events when using the scroll wheel in CocoaNorwegian Rock Cat2009-04-281-2/+2
| | | | | | | | Argh! Copy and paste is evil, not only was the test was wrong, We sent the event twice and the second time we sent the wrong value. Task-number: 250668 Reviewed-by: Morten Sørvig
* Cocoa: qwidget auto test fails (windowMoveResize)Richard Moe Gustavsen2009-04-282-11/+31
| | | | | | | | | | | | 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
* Fixes wrong QPaintEvent::region() in QGLWidget::paintEvent.Bjoern Erik Nilsen2009-04-272-0/+2
| | | | | | | | | | | | | | QGLWidget does not support partial updates unless the context is single buffered and auto-fill background is disabled. The problem was that QPaintEvent::region() returned the requested update region without taking into account the limitation of QGLWidget. If QGLWidget doesn't support partial updates, it means everything has to be updated, and QPaintEvent::region() must return the whole widget rect. Auto test included. Task-number: 241785 Reviewed-by: Trond
* Document what QWidget::winId() returns on Mac OS X.Norwegian Rock Cat2009-04-271-0/+4
| | | | | | | | There are different types depending on Carbon and Cocoa, and it is probably helpful to point that out. Task-number: 251001 Reviewed-by: Kavindra
* Sometimes wrong clipping in QWidget::render() when passing a device orBjoern Erik Nilsen2009-04-241-4/+7
| | | | | | | | | | | | | | | | | | an untransformed painter When passing a painter to QWidget::render, we use the painter->paintEngine()->systemClip() as the "system viewport", i.e. all painting triggered by render() should be limited to this area. The only way to achieve this is by always ensuring the system clip is clipped to the same area (systemClip &= systemViewport). The problem however, was that we only did this for transformed painters. We must of course always do it when there's a systemViewport set, regardless of whether the painter is transformed or not. Auto test included. Task-number: 248852 Reviewed-by: Trond
* Drag and drop examples not working correctly in CocoaPrasanth Ullattil2009-04-243-27/+62
| | | | | | | | | | | In the updated examples, the drag operation is changed in the drop-event handler, which was not handled correctly in the Cocoa. This is now supported for drag and drop from same application. If the drop was to another application, the drag will return the result from the last drag-move event. Task-number: 252103 Reviewed-by: nrc
* Revert "Removed dead code."jasplin2009-04-231-0/+2
| | | | | This reverts commit 99d243860548d6be8a68dfd027c51530351d12cb. Needed because of commit b51dd5a7b328291c5dbda540ce228e7d867662cb.
* Revert "Fixed key sequence eating behavior for QShortcut and QAction."jasplin2009-04-234-50/+27
| | | | | | | | | | | This reverts commit 031adeaf42ddaef8d01338f6c59ba97170be5d53. The patch had some unforeseen side-effects for Creator. It may also affect other existing applications in a similar way. For now, this behavior (eating key sequences for disabled shortcuts) should be achieved using a local workaround in creator. Reviewed-by: mariusSO Task-number: 251246
* Disable MIT-SHM usage on BGR server layouts under X11.Trond Kjernåsen2009-04-231-6/+12
| | | | | | | | Since the raster engine always assumes RGB layout in a QImage, we can't support this out of the box. Task-number: 248720 Reviewed-by: Samuel
* Carbon/Cocoa: It is possible to resize a widget above its maximum sizeRichard Moe Gustavsen2009-04-232-39/+50
| | | | | | | | | | 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
* Removed dead code.jasplin2009-04-231-2/+0
| | | | Reviewed-by: TrustMe
* Don't emit QApplication::focusChanged for no reasonThorbjørn Lindeijer2009-04-221-1/+1
| | | | | | | | | | | | | | | | The Qt::NoFocusReason is used when Qt temporarily moves the focus to the QMenuBar while switching from one widget to another. While this did not result in a QFocusEvent, it did result in emitting the QApplication::focusChanged signal. This in turn caused a slowness in Qt Creator, since it wanted to update the current context and find filter. The fix here makes sure the focusChanged signal is not emitted when the focus reason is Qt::NoFocusReason, since these focus changes are not interesting for the application. Reviewed-by: mae
* Doc fixesJoão Abecasis2009-04-221-2/+3
| | | | Reviewed-by: Thiago
* BT: Make things work on 10.3Norwegian Rock Cat2009-04-211-1/+1
| | | | | | The #ifdef was typed wrong. Reviewed-by: Prasanth Ullattil
* Fixed key sequence eating behavior for QShortcut and QAction.jasplin2009-04-204-27/+50
| | | | | | | | | | | | | | | | | | A disabled QShortcut should eat its key sequence even for complex sequences like "Ctrl-E 1". For example, a line edit with such a shortcut should not display 1 after typing "Ctrl-E" and then "1". The patch achieves this essentially by moving more of the decision making (of whether to eat the key secuence) from shortcutmap.cpp to qhortcut.cpp. Moreover, an invisible QAction should not eat any of its key sequences (primary nor alternates). In the example above, the line edit would display 1 when typing this sequence for an invisible action. The patch achieves this by temporarily unregistering all of the action's shortcuts while the action is invisible. Reviewed-by: mariusSO Task-number: 251246
* Fixed incorrect documentation.axis2009-04-201-3/+4
|
* 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
generated by cgit v0.12 at 2024-11-14 19:37:37 (GMT)