summaryrefslogtreecommitdiffstats
path: root/src/gui/kernel
Commit message (Collapse)AuthorAgeFilesLines
* Add a AA_MacDontSwapCtrlAndMeta application attribute.Norwegian Rock Cat2009-05-114-23/+113
| | | | | | | | | | | | | | | | | | This is to help undo the some magic that is in the Qt/Mac port. Qt automatically flips the Meta and Control keys on Mac. This is a "feature" that makes porting older programs that don't use standard shortcuts easier as Ctrl and Command usually map to the same shortcuts in the application. The upshot of this is that I need to strip the text() out of key events if they contain the Control or Meta modifier. This causes much headache for anyone writing a terminal emulator. Though they would still have to write special code because the keys are swapped anyway. This allows people to write the terminal emulator where hitting the Control key will really send a Control key modifier. We've also done the extra work to ensure that standard shortcuts work correctly regardless of what the value of the attribute is. That is, if you specify QKeySequence::Cut for a shortcut you can always hit Command+X and things will work.
* Add QKeySequence::Quit and QKeySequence::Preferences for standard keys.Norwegian Rock Cat2009-05-111-1/+7
| | | | | | | | These are handy to have and make it possible for people to not have to remember the specific sequences on the different platforms, though some don't have any. Reviewed-by: Jens Bache-Wiig
* Almost 200 symbols that didn't need to be exported.Thierry Bastian2009-05-111-2/+0
|
* Merge branch '4.5'Thiago Macieira2009-05-112-13/+14
|\
| * 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
* | removed more exports on private classes (QMouseEventEx and QKeyEventEx)Thierry Bastian2009-05-081-2/+2
| |
* | Merge branch '4.5'Thiago Macieira2009-05-072-2/+22
|\ \ | |/ | | | | | | | | Conflicts: src/gui/painting/qbackingstore.cpp src/gui/painting/qwindowsurface_raster.cpp
| * 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
* | qdoc: Moved platform-specific qdoc comments to common .cpp file.Martin Smith2009-05-074-120/+132
| | | | | | | | | | | | | | | | | | 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
* | Merge branch '4.5' of git@scm.dev.troll.no:qt/qtSimon Hausmann2009-05-068-32/+66
|\ \ | |/ | | | | | | | | Conflicts: src/gui/kernel/qcocoaview_mac_p.h src/gui/widgets/qmainwindow.cpp
| * 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
* | Fix focus issues in QX11EmbedContainer, affecting Flash plugin in QtWebKit.Kenneth Rohde Christiansen2009-05-061-11/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We are now moving focus to the XEmbed focus proxy when we accept a client and when we get window activation. Window activation did that before, but only when we were the active container, thus had focus in. Now we do it always. Due to race conditions with the window manager, the time stamt we used for XSetInputFocus was the same as that of the window manager. This broke it from time to time in Metacity and Xfce but always in KWin. With other tested window manager we didn't have this issue. Following Owen Tayler's advice (one of the authors of the XEmbed specification) we now use CurrentTime and not qt_x11Data->time when moving the input focus as there is no explicit user interaction involved. Reviewed-by: Denis Dzyubenko <denis.dzyubenko@nokia.com> Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
* | Fix QFormLayout which allowed fields to be smaller that their minimum sizeOlivier Goffart2009-05-061-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | If the label's sizeHint is bigger than its minimumSizeHint, the field may be resized smaller than its minimum size. This also fix another problem where the field would 'jump' from one sizehint to the others. (This can happen if labels can word-wrap for example) Reviewed-by: Michael Goddard
* | Fixed handling of XA_PIXMAP format type in QClipboard on X11.Denis Dzyubenko2009-05-052-19/+6
| | | | | | | | | | | | | | | | | | | | | | When requesting image/ppm type we didn't return the proper pixmap because type 'PIXMAP' is not a proper image format name, but a reserved atom, so the fix is to remove redundant check that was triggered before we entered the actual function that tries to convert the clipboard content. Task-number: 252501 Reviewed-by: Brad
* | When data was copied from Mozilla Firefox to Qt, the text format was not valid.Denis Dzyubenko2009-05-041-7/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Mozilla encodes the text/html format in UTF16 and adds a BOM, however it doesn't specify the charset in the html header. The fix is to guess the encoding by either charset in the html header or BOM for text/html format, or by BOM for non html formats. This commit adds a new public function QTextCodec::codecForUtfText() which can be used to guess encoding out of the BOM. Task-number: 250555 Reviewed-by: Benjamin Poulain Reviewed-by: Simon Hausmann Reviewed-by: Andreas Aardal Hanssen
* | Deprecate qt_mac_set_show_menubar for a public cross-platform API.Norwegian Rock Cat2009-05-043-9/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I'm tired of these "hidden" functions. We have an AA_MacPluginApplication, but sometimes you may have a legitimate reason for setting this outside of "plugin applications." In the footsteps of the menu icon attribute, the attribute is the main leader, but menubars can disable/enable this locally the new QMenuBar::setNativeMenuBar() property. Otherwise, the menubars take their que from the application attribute. This also works for Windows CE. So, there is a bit on convergence as well. Task-number: 236757
* | Merge commit 'origin/4.5'Olivier Goffart2009-05-042-11/+23
|\ \ | |/ | | | | | | Conflicts: src/gui/itemviews/qabstractitemview.cpp
| * 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
* | Mac: QWidget::setMinimumSize does not workRichard Moe Gustavsen2009-05-042-43/+46
| | | | | | | | | | | | | | | | | | 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 commit 'origin/4.5'Bjoern Erik Nilsen2009-04-292-3/+8
|\ \ | |/
| * 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
* | introduce Q_WS_WINCEMaurice Kalinowski2009-04-2910-106/+106
| | | | | | | | | | | | | | | | | | | | | | Task-number: 246130 Reviewed-by: joerg Introduce Q_WS_WINCE for Windows CE only windowing parts. So far we decided to stick with Q_WS_WIN32, but having a separate define makes the code more readable. In addition Q_WS_WINCE_WM is available for Windows Mobile only parts, where we do not check for the OS on runtime.
* | Merge branch '4.5' of git@scm.dev.nokia.troll.no:qt/qtSimon Hausmann2009-04-293-13/+33
|\ \ | |/
| * 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
* | Merge branch '4.5' of git@scm.dev.troll.no:qt/qtSimon Hausmann2009-04-272-0/+6
|\ \ | |/
| * 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
* | Merge branch '4.5' of git@scm.dev.troll.no:qt/qtSimon Hausmann2009-04-251-4/+7
|\ \ | |/
| * 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
* | Merge branch '4.5'Thiago Macieira2009-04-243-27/+62
|\ \ | |/ | | | | | | | | | | | | | | | | | | | | Conflicts (version number change in 4.5): src/corelib/global/qglobal.h src/qbase.pri tools/qdoc3/test/assistant.qdocconf tools/qdoc3/test/designer.qdocconf tools/qdoc3/test/linguist.qdocconf tools/qdoc3/test/qmake.qdocconf tools/qdoc3/test/qt-build-docs.qdocconf tools/qdoc3/test/qt.qdocconf
| * 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
* | Remove the Direct3D engine.Gunnar Sletta2009-04-245-87/+1
| |
* | Merge branch '4.5'Thiago Macieira2009-04-234-50/+29
|\ \ | |/ | | | | | | Conflicts: tests/auto/qaction/tst_qaction.cpp
| * 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
* | Merge branch '4.5' of git@scm.dev.nokia.troll.no:qt/qtSimon Hausmann2009-04-231-6/+12
|\ \ | |/
| * 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
* | Merge branch '4.5' of git@scm.dev.nokia.troll.no:qt/qtSimon Hausmann2009-04-234-44/+54
|\ \ | |/ | | | | | | | | | | 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-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