summaryrefslogtreecommitdiffstats
path: root/src/gui/kernel
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'master' of git@scm.dev.nokia.troll.no:qt/qt-s60-publicIain2009-05-1111-39/+31
|\
| * Make autoSipOnMouseFocus non-static.axis2009-05-111-3/+2
| | | | | | | | This way we are consistent with autoSipEnabled.
| * Small doc update.axis2009-05-111-0/+2
| |
| * Make autoSipEnabled available on all platforms.axis2009-05-113-8/+10
| | | | | | | | | | | | This is relevant on S60 too, so it's time to make it cross platform. RevBy: mauricek
| * Merge branch 'master' of git@scm.dev.nokia.troll.no:qt/qt-s60-publicJanne Koskinen2009-05-1134-1446/+2090
| |\ | | | | | | | | | | | | Conflicts: src/gui/widgets/qmenu_symbian.cpp
| * | Fixed namespace issues, now works on Symbian under namespaceJanne Koskinen2009-05-119-28/+17
| | |
* | | A better way of getting the screen's colour depthIain2009-05-111-21/+2
| |/ |/|
* | Merge branch '4.5' of git@scm.dev.nokia.troll.no:qt/qtaxis2009-05-1112-190/+250
|\ \ | | | | | | | | | | | | Conflicts: tests/auto/qtemporaryfile/qtemporaryfile.pro
| * | 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
* | | Moving the handling code for HandleCommandL fromAlessandro Portale2009-05-072-0/+17
| | | | | | | | | | | | | | | | | | | | | CQtS60MainAppUi::HandleCommandL to the new QApplication::s60HandleCommandL so that it is in QtGui rather than in the static app wrapper. RevBy: axis
| | |
| \ \
*-. \ \ Merge branches 'virtualKeyboardAPI' and 'imHintsForS60'axis2009-05-066-1/+112
|\ \ \ \
| * | | | Improved the docs a bit.axis2009-05-061-0/+2
| |/ / /
| * | | Clarified the docs a bit.axis2009-05-061-1/+1
| | | |
| * | | Split ImhNumbersOnly into DigitsOnly and FormattedNumbersOnly.axis2009-05-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | This was discussed with denis, and we found out that PIN codes on phones are a use case where it would be an advantage to have digits only. S60 already supports this mode of operation in their VK.
| * | | Small optimization to input context update.axis2009-05-051-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | Only update the input context if it has already been created. RevBy: denis
| * | | Updated to slightly better docs.axis2009-05-041-1/+4
| | | | | | | | | | | | | | | | RevBy: denis
| * | | Make sure to update input context after switching input method hints.axis2009-05-041-0/+4
| | | | | | | | | | | | | | | | RevBy: denis
| * | | Added inputMethodHints API.axis2009-05-043-1/+38
| | | | | | | | | | | | | | | | RevBy: denis
| * | | Close the input panel when focusing a non-inputmethods aware widget.axis2009-05-041-0/+10
| | | | | | | | | | | | | | | | | | | | AutoTest: Included RevBy: denis
| * | | Added QApplication::autoSipOnMouseFocus.axis2009-05-043-0/+39
| | | | | | | | | | | | | | | | RevBy: denis
| * | | Added an event to request and close software input panel.axis2009-05-041-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is meant to be used by widgets to signal that they want input. The event will then be passed on to QInputContext::filterEvent, which can create an appropriate virtual keyboard on devices with touch interface only. RevBy: denis
* | | | Merge branch '4.5' of git@scm.dev.nokia.troll.no:qt/qtaxis2009-05-0610-50/+106
|\ \ \ \ | | |/ / | |/| |
| * | | 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
* | | | Some code cleanups after review.Jason Barron2009-04-291-3/+3
| | | | | | | | | | | | | | | | | | | | Change these lines of code to either make it more consistent or more readable after review.
* | | | Undo implementation of setWindowOpacity_sys().Jason Barron2009-04-291-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This function was implemented using API from Symbian that will be deprecated. It was never actually suitable anyway since this function cannot be called after the window has been shown and this needs to be a runtime decision for Qt. The solution is to use SetTransparencyAlphaChannel(), but that will come later.
* | | | Fixes crash when setting geometry on an obscured window.Jason Barron2009-04-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Since Qt on Symbian now destroys the backing store when it gets hidden or obscured we need to be careful not to use functions like moveRect() when we don't have a backing store since this function is really a backing store optimization and therefore assumes one exists.
* | | | More work on translucent windows.Jason Barron2009-04-282-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One step closer to semi-transparent windows, but not there yet. This gets the transparent contents into the window, but the previous contents are not cleared so it keeps drawing the backing store on top of itself each time a Draw() is done. SetBackgroundColor() indicates to WSERV that our window is semi-transparent. We also make sure not to use 'EDrawModeWriteAlpha' when the widget is non-opaque since this actually changes the alpha channel on the frame buffer (not the window) so the gives undesired results. It's a faster draw mode though so we should use it where we can.
* | | | Fixes: Add support for translucent windows in Symbian.Jason Barron2009-04-285-2/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Warning, this is completely untested! Details: This should (in theory) get translucent windows working but this hasn't been tested yet. The emulator environment seems to return only 16ColorMU display modes which implies the window is opague so Qt ignores the translucent flag. HW seems to create 16ColorMA windows, but it hasn't been tested there yet either (no time).
* | | | We previously had some hacks in this function to avoid creating aJason Barron2009-04-281-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | backing store with the ARGB32 format (which is slower to draw on), but we actually want this in some cases so let's do this properly and move the hacks somewhere else.
* | | | Fix background painting.Jason Barron2009-04-281-7/+5
| |/ / |/| | | | | | | | | | | | | | | | | This is a reverted patch that has been rebased on to another branch and then caused conflicts so it might contain an error or two. Basically we need to store the background texture from the style into the palette so that it can be replaced by applications that don't want it.
* | | Enable dynamic [de|con]struction of window surfaces based on visibilityJason Barron2009-04-282-13/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | When a window becomes completely obscured either because it has been hidden or another window is completely covering it, the backing store should be deallocated to save memory and then re-allocated when the window is later made visible again. Reviewed-by: Iain <qt-info@nokia.com>
* | | Merge branch '4.5' of git@scm.dev.nokia.troll.no:qt/qtaxis2009-04-2723-1200/+1538
|\ \ \ | |/ / | | / | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Configure.exe recompiled with MSVC6. Conflicts: configure.exe examples/network/network.pro src/gui/dialogs/qfiledialog_p.h src/gui/dialogs/qfilesystemmodel_p.h src/gui/kernel/qapplication.cpp tests/auto/_Categories/qmake.txt tests/auto/qfile/test/test.pro tests/auto/qfile/tst_qfile.cpp tests/auto/qlibrary/tst_qlibrary.cpp tests/auto/qline/tst_qline.cpp tests/auto/qstyle/tst_qstyle.cpp tests/auto/qtextstream/tst_qtextstream.cpp tests/auto/qtranslator/qtranslator.pro tests/auto/qwaitcondition/tst_qwaitcondition.cpp translations/qt_ja_JP.ts
| * 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
generated by cgit v0.12 at 2025-01-24 20:32:37 (GMT)