summaryrefslogtreecommitdiffstats
path: root/src/gui/kernel
Commit message (Collapse)AuthorAgeFilesLines
* Change copyrights from Nokia to Digia4.5Sergio Ahumada2012-11-28151-2731/+2719
| | | | | | | | Change copyrights and license headers from Nokia to Digia Change-Id: I9f5c8a9135271161e2bce50bc413ea01a08c3a76 Reviewed-by: Akseli Salovaara <akseli.salovaara@digia.com> Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Fixed bug where GL widget was not fully updated on Vista.Kim Motoyoshi Kalland2010-02-043-11/+21
| | | | | | | | | There were cases where the QGLWidget would not be fully updated on screen on Windows Vista and Windows 7 with Aero disabled. Task-number: QTBUG-7865 Reviewed-by: Prasanth
* Fixed uninitialized background artifacts in QWidget::render.Donald Carr2009-12-081-1/+1
| | | | | | backport of 64d38ba23b4acc46fdb9145f1953315573e3f8dc Reviewed-by: Anders Bakken<anders.bakken@nokia.com>
* Disable the move-by-scrolling optimization.Morten Johan Sørvig2009-11-021-3/+3
| | | | | | The current implementation fails when moving the widget onto an area that has just been exposed as a part of a window resize operation.
* Plug some autorelease pool leaks.Norwegian Rock Cat2009-10-291-0/+2
| | | | | | | | Calling QWidget::setCursor() outside of the event loop causes a memory leak in Cocoa. Adding an autorelease pool plugs it. Merge-request: 1791 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@nokia.com>
* QWidget painting regression on Windows.Bjørn Erik Nilsen2009-10-221-1/+1
| | | | | | | | | | | | | | Problem occurred on Windows due to a call to repaint() on a top-level window from setDisabledStyle() in qwidget.cpp. This function is called whenever a window is blocking. In this particular case the children of the repainted window are opaque, and should therefore not be repainted, which also means that the top-level have to subtract the region of the opaque children when filling the background. This region is cached, and the problem was that the cached region was wrong. It was wrong because it was not invalidated properly. Task: QTBUG-4245 Reviewed-by: Paul
* move default QAbstractButton font setup on Win mobile to QApplicationJoerg Bornemann2009-10-221-0/+2
| | | | | | | | The original approach of modifying the font for QAbstractButtons in QWindowsMobileStyle::polish broke the autotest tst_qstylesheetstyle::fontPropagation. Reviewed-by: thartman
* Fix a crash in cocoa when a QMessageBox is destroyed from dropEvent()Prasanth Ullattil2009-10-121-11/+11
| | | | | | | | | The gobal variable which stores the current mouse event can be updated before dragImage() call(blocking) is finished. So make a local copy of the information required by the QDragManager::drag(). Task-number: QTBUG-4814 Reviewed-by: MortenS
* ignore invalid WM_KEYDOWN messages on WindowsJoerg Bornemann2009-10-071-2/+2
| | | | | | | | | | | | | | For some strange reason, I get the following message if I press a non-numerical key on the SIP of a Samsung Omnia device, running Windows mobile 6.1: WM_KEYDOWN wParam == 0 lParam == 1 That message is invalid. We must ignore it. Reviewed-by: mauricek
* Fixed Designer property editor selection bug.Gabriel de Dietrich2009-10-011-1/+1
| | | | | | | | | | | | | | | | When the editor had been created inside the QtPropertyEditorView (inheriting QTreeWidget), the subsequent show sent a synthetic mouse move event down to the QLineEdit, and a new selection was made on the text because the mouse button was marked as pressed in the event. QApplicationPrivate::sendSyntheticEnterLeave() now sends a mouse move event without any button pressed. Auto-test included in tst_QWidget. Task-number: QTBUG-4055 Task-number: 253159 Task-number: QT-659 Task-number: 245398 Reviewed-by: bnilsen
* Fixes clipboard handling on X11.Denis Dzyubenko2009-10-011-1/+3
| | | | | | | | | | | | This fixes handling selection requests for invalid targets - when someone asks for a target that is not supported by the clipboard content we shouldn't do anything (unless it's MULTIPLE). Fixes copying data when using Synergy which tries to get all targets it knows about even if they are not listed in TARGETS. Task-number: QTBUG-4652 Reviewed-by: Bradley T. Hughes
* Calling raise() on a hidden windows makes it visible on Cocoa.Prasanth Ullattil2009-09-231-1/+1
| | | | | | | | | [NSWindow orderFront:] on a hidden window will make it visible. So raise_sys() will now check if window is visible before this method is called. Task-number: 255428 Reviewed-by: Richard Moe Gustavsen
* Fixed off-by-one error in call to XGetKeyboardMapping that meant that ↵Thomas Sondergaard2009-09-141-1/+1
| | | | | | | max_keycode wasn't retrieved. Merge-request: 1308 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
* Fix memory leak when deleteLater is triggered via the main menu bar.Morten Sorvig2009-09-111-0/+2
| | | | | | | | | | The deleteLater was beeing created with loopLevel of 1, causing it to be defferd until QApplication::exec() returned. Add a QScopedLoopLevelCounter to increase the loopLevel while triggering the action. RevBy: Brad
* Run on 10.3.Morten Sorvig2009-09-111-1/+1
| | | | | _HIViewScrollRectWithOptions needs to be declared as a weak-linked symbol in order to make static linking work.
* Run on 10.3 Panther.Morten Sorvig2009-09-111-1/+4
| | | | HIViewSetNeedsDisplayInRect was added in 10.4.
* restoring a minimized window on Windows CE didn't workJoerg Bornemann2009-09-102-5/+12
| | | | | | | | | | After restoring a minimized window we only saw the window decoration. All content was missing. That's because we don't get a WM_SIZE message for restoring the window. We must react on WM_ACTIVATE in this case. This fixes the issue for Windows mobile too. Task-number: 260702 Reviewed-by: thartman
* Update license headers again.Jason McDonald2009-09-08151-604/+604
| | | | Reviewed-by: Trust Me
* Doc: keypad navigation is supported on Windows CEJoerg Bornemann2009-09-081-2/+10
| | | | Reviewed-by: thartman
* restoring a minimized window on Windows CE didn't workJoerg Bornemann2009-09-031-0/+6
| | | | | | | | | After restoring a minimized window we only saw the window decoration. All content was missing. That's because we don't get a WM_SIZE message for restoring the window. We must react on WM_ACTIVATE in this case. Task-number: 260702 Reviewed-by: thartman
* unneeded Q_OS_WINCE checks removedJoerg Bornemann2009-09-031-5/+1
| | | | | | There's a big outer ifdef and we don't need these inner checks. Reviewed-by: thartman
* Update license headers.Jason McDonald2009-09-025-15/+0
| | | | Reviewed-by: Trust Me
* Fix misformatted license headers.Jason McDonald2009-09-011-11/+8
| | | | Reviewed-by: Trust Me
* Update tech preview license header.Jason McDonald2009-08-31151-1963/+1963
| | | | Reviewed-by: Trust Me
* Make assorted constructors follow good coding practiceKeith Isdale2009-08-241-1/+2
| | | | | | | Ensure that class members are initialized Moved some value assignment from constructor body into the the constructor's intializer list Reviewed-by: Jason McDonald
* Fixed usage of the MITSHM extension for 16 bit X servers.Trond Kjernåsen2009-08-191-3/+6
| | | | | | | | The server color layout test was a bit to harsh, since it excluded 16 bit X11 servers with RGB layout. Task-number: 259846 Reviewed-by: Gunnar
* fix WA_DontShowOnScreen bug on Windows CEJoerg Bornemann2009-08-171-1/+1
| | | | | | | We must not retrieve the initial window geometry for WA_DontShowOnScreen widgets with GetClientRect. Reviewed-by: thartman
* Document QAction::MenuRole not working on submenus.Norwegian Rock Cat2009-08-141-0/+5
| | | | | | | We could do it or we couldn't. It's simply a judgement call and I think the comments in the task are a good argument for NOT doing it. Task-number: 227875
* Wrapped the XInput include with an ifdef.Denis Dzyubenko2009-08-121-0/+4
| | | | | | | | That should fix compilation on platforms that do not have xinput headers installed. Reviewed-by: Thiago Macieira (cherry picked from commit 0a13188468997d6c3253db5b29f05a119945f131)
* fix decoration of DontShowOnScreen widgets on Windows CEJoerg Bornemann2009-08-121-1/+1
| | | | | | | | Widgets with the WA_DontShowOnScreen attribute must not have a window decoration. Autotest: tst_QWidget::initialPosForDontShowOnScreenWidgets Reviewed-by: thartman
* Update URL of online documentation.Jason McDonald2009-08-111-1/+1
| | | | Reviewed-by: Trust Me
* Eliminate some mentions of Trolltech.Jason McDonald2009-08-111-1/+1
| | | | Reviewed-by: Trust Me
* Qt's domain name is now qt.nokia.com.Jason McDonald2009-08-111-1/+1
| | | | Reviewed-by: Trust Me
* Update license headers.Jason McDonald2009-08-11151-151/+151
| | | | Reviewed-by: Trust Me
* Fix crash in QX11Data::xdndHandleEnter when XGetWindowProperty failsOctavian Voicu2009-08-061-6/+7
| | | | | | | Task-number: 259143 Merge-request: 1119 Reviewed-by: Denis Dzyubenko <denis.dzyubenko@nokia.com>
* Cocoa: Menus show old selected values.Richard Moe Gustavsen2009-08-051-0/+6
| | | | | | | | | | We never told Cocoa that it needed to redraw the window view when a window was shown. This is implicit if the window is shown for the first time, but needs to be done explicit if you hide and show it again. Task-number: 254672 Reviewed-by: bnilsen
* Cocoa with namespace breaks the buildRichard Moe Gustavsen2009-07-311-2/+2
| | | | | | | Added the needed macros around the classnames the way it should be done. Reviewed-by: Prasanth
* Allow maximize button on the titlebar for a fixed size windowDenis Dzyubenko2009-07-301-0/+5
| | | | | | | | | On Windows we will add maximize button to the titlebar even if the window has a fixed size if the user explicitely asked for it by setting Qt::CustomizeWindowHint | Qt::WindowMaximizeButtonHint. Task-number: 250188 Reviewed-by: Leonardo Sobral Cunha
* Remove mem leak / warning in the cocoaportRichard Moe Gustavsen2009-07-301-0/+1
| | | | | | Remove mem leak / warning in the cocoaport Reviewed-by: msorvig
* Unable to change focus between two line edits on macRichard Moe Gustavsen2009-07-301-37/+12
| | | | | | | | | | | | | | | | | | | | This is because we try to decide whether the window cocoa tells us to be active should be active, and if we desagree, we do nothing. The result is that Qt and Cocoa ends up in different states. I decided to remove a lot of the logic that went on in this case, and the resons is: 1. By checking the callplaces to onApplicationWindowChangedActivation, we know that we always have a valid widget pointer, and we know that the widget always is a window (otherwise Cocoa would never tell us that the widget got active). 2. We can never end up doing nothing in this response. The best we can do is to follow what Cocoa tells us. If this turns out to break something, it would probably be better to check why we get an activation call in the first place for a window that should not be activated (e.g. is canBecomeKeyWindow set correctly?) Task: 253610 RevBy: msorvig
* Doc - Renamed the cursor's images to illustrate splitV and splitH properlyKavindra Devi Palaraja2009-07-291-2/+2
| | | | | | Task: 258895 Reviewed-By: Jens Bache-Wiig
* Roll back the fancy updating of translucent windows.Gunnar Sletta2009-07-271-4/+1
| | | | | | | | | | The problem with the fix, though it produces less flicker when resizing, is that it delays telling windows that the window has moved until after the window has been completely repainted. Problem with this is that functions that rely on windows to be up to date will fail until the backbuffer is flushed. This was the case for mapTo/FromGlobal, and potentially other functions too. Reviewed-By: Eskil
* Prematurely creating a dialog as a sheet causes problemsRichard Moe Gustavsen2009-07-242-21/+34
| | | | | | | | | | | | | | Prematurely creating a dialog as a sheet and then calling exec() on it will show a window w/o decorations. The problem is that first telling a window to be a sheet, and then tell it to exec, is unambigious. Because doing the latter implies application modality (when modality is not set), which again implies not using a sheet. Calling exec (and setting modality) will win over window flags, so in this case, we now recreate the window as a normal app-modal dialog. Task: 254524 Reviewed-by: Trenton Schulz
* Revert "Added a check that X11 timestamp goes forward only."Denis Dzyubenko2009-07-221-20/+15
| | | | | | | | | | | | | | | In some cases we might get an invalid timestamp that is far away in the future, so remembering it will break all consequent X calls that require a timestamp because it just contains junk (for example clipboard will stop working). This happens with XIM+SCIM pair - whenever we start input method and type something to the widget, we get a XKeyPress event with a commited string, however the 'serial' and 'time' members of the XEvent structure are not initialized (according to valgrind) and contain junk. This reverts commit 2ed015b8a0ffad63f0f59b0e2255057f416895fb. Reviewed-By: Brad
* Another fix needed to build in a namespace on Mac with -arch ppcAndy Shaw2009-07-211-1/+2
| | | | | | | | Don't know how this got lost in the original submit since I had added both. Task-number: 257080 Reviewed-by: nrc
* Fix crash when native socket notifiers would send a notification after being ↵Norwegian Rock Cat2009-07-201-4/+8
| | | | | | | | | | | | | | | | disabled. Spend a lot of time looking at this and at the CoreFoundation source code and it seems that we really do get a notification even after the notifier is disabled. I suspect there's a race condition between when we disable the socket notifier, but the kernel flags it as needing a read, then CoreFoundation just sends the notification without checking if the CFSocket has been disabled. No further notifications come of course. Since this breaks the invariant that was set in the assert, I'm replacing it with an if check. Task-number: 258198 Reviewed-by: Bradley T. Hughes
* Fix deadlock in the QWS server when destroying lots of windowsTom Cooksey2009-07-171-2/+6
| | | | | | | | | | | | | | | | | | | First, don't call QWSWindowSurface::winId() in the destructor, as it will actually request a new id if there isn't already one around - which is a bit silly and highlighted the "real" bug. Second, make sure QWSDisplay::Data::takeId() asks for 1 new id before waiting for more ids to arrive. This is because waitForCreation() calls QWSServer::processEventQueue(). If the events in the queue cause takeId() to be called, QWSDisplay::Data::takeId() gets called recursively. Even though there will be a create 15 ids command in the queue, that will only allow 15 QWSDisplay::Data::takeId() calls to return. The 16th call to QWSDisplay::Data::takeId() on the stack will not be able to return because all the IDs have been taken and (because it has been called recursively) no new create id commands have been generated. So the 16th call to takeId() spins in waitForCreate(). Reviewed-by: Paul
* 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