summaryrefslogtreecommitdiffstats
path: root/src/gui/kernel
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Line edit displays garbage when pressing up or down arrow keys (Cocoa).Prasanth Ullattil2009-04-171-1/+4
| | | | | | | | | The unicode characters between 0xF700 & 0xF8FF are special function-key code characters used by the NSEvent. These characters have to be ignored when converting to a QString. Task-number:244486 Reviewed-by:nrc
* 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.
* Fix a bug that made it hard to click the top items in a list widgetNorwegian Rock Cat2009-04-161-2/+2
| | | | | | | | | | Our "view under tranparent view" function was sound, but it didn't take into consideration that fact that views in the hierarchy could be hidden. This is most prominent when you have a QFocusFrame over a QAbstractScrollArea. Task-number: 251008 Reviewed-by: Morten Sørvig
* Fixed titlebar on X11 for fixed size windows with Qt::CustomizeWindowHintDenis Dzyubenko2009-04-161-1/+3
| | | | | Task-number: 250326 Reviewed-by: Brad
* QX11Embed crashes on 64-bit SolarisBradley T. Hughes2009-04-161-4/+3
| | | | | | | | The data passed to XChangeProperty should be long arrays, as this is what Xlib expects. Task-number: 244062 Reviewed-by: Rhys Weatherley
* BT: Namespace compile fixes for Cocoa.Norwegian Rock Cat2009-04-152-6/+9
| | | | It worked in 4.5.0, so it should work in 4.5.1 too.
* BT: Fix Cocoa bug w/OpenGL widgets in dock widgets would disappear.Norwegian Rock Cat2009-04-151-0/+21
| | | | | | | | | | | | The NSOpenGLContext seems to be tied to the window. So if the view changes from one window to another, the OpenGL context needs to be cleared. We can do this by hooking into the viewWillChangeWindow and viewDidChangeWindow events and clear and reset the drawable respectively. We also found out that QCocoaOpenGLView was not being used at all, so just remove it to get rid of any confusion. Task-number: 250066 Reviewed-by: Trond
* Fix warning: "__LP64__" is not defined"Thiago Macieira2009-04-141-1/+1
| | | | Reviewed-by: Norwegian Rock Cat
* Fix a bug where a widget would not always get the correct Cursor in CocoaNorwegian Rock Cat2009-04-144-0/+61
| | | | | | | | | | 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
* BT: Fix up comments in new Cocoa files.Norwegian Rock Cat2009-04-085-55/+55
| | | | | | It seems that Vim or Xcode or whatever I was using to paste these in messed up and added an extra space. Now we should be consistent with the .cpp files and I found a file that we missed too.
generated by cgit v0.12 at 2025-01-29 13:57:17 (GMT)