| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
backport of 64d38ba23b4acc46fdb9145f1953315573e3f8dc
Reviewed-by: Anders Bakken<anders.bakken@nokia.com>
|
|
|
|
|
|
| |
The current implementation fails when moving the
widget onto an area that has just been exposed
as a part of a window resize operation.
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
The original approach of modifying the font for QAbstractButtons in
QWindowsMobileStyle::polish broke the autotest
tst_qstylesheetstyle::fontPropagation.
Reviewed-by: thartman
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
[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
|
|
|
|
|
|
|
| |
max_keycode wasn't retrieved.
Merge-request: 1308
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
_HIViewScrollRectWithOptions needs to be declared as a weak-linked
symbol in order to make static linking work.
|
|
|
|
| |
HIViewSetNeedsDisplayInRect was added in 10.4.
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: thartman
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
There's a big outer ifdef and we don't need these inner checks.
Reviewed-by: thartman
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
|
|
|
| |
Ensure that class members are initialized
Moved some value assignment from constructor body into the the constructor's intializer list
Reviewed-by: Jason McDonald
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
We must not retrieve the initial window geometry for
WA_DontShowOnScreen widgets with GetClientRect.
Reviewed-by: thartman
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
That should fix compilation on platforms that do not have xinput
headers installed.
Reviewed-by: Thiago Macieira
(cherry picked from commit 0a13188468997d6c3253db5b29f05a119945f131)
|
|
|
|
|
|
|
|
| |
Widgets with the WA_DontShowOnScreen attribute must not have a window
decoration.
Autotest: tst_QWidget::initialPosForDontShowOnScreenWidgets
Reviewed-by: thartman
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
|
|
|
| |
Task-number: 259143
Merge-request: 1119
Reviewed-by: Denis Dzyubenko <denis.dzyubenko@nokia.com>
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Added the needed macros around the classnames the way it
should be done.
Reviewed-by: Prasanth
|
|
|
|
|
|
|
|
|
| |
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 cocoaport
Reviewed-by: msorvig
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Task: 258895
Reviewed-By: Jens Bache-Wiig
|
|
|
|
|
|
|
|
|
|
| |
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 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Don't know how this got lost in the original submit since I had added
both.
Task-number: 257080
Reviewed-by: nrc
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
The inputContext's focusWidget was not reset when disabling input
methods.
Thanks to Benjamin P.
Task-number: 257832
Reviewed-by: Denis
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
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
|