| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| | |
kinetic-declarativeui
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The opaque children cache was clipped to all the ancestors up to the
top-level, which means whenever a widget changes geometry all the
children must be invalidated. However, the bug was that we didn't
invalidate the children, and that is of course slow so we don't want
to do it either. A better solution is to only clip the children cache to the
widget itself (widget->rect() instead of widget->clipRect()), and we can
perfectly do this because the region we subtract the opaque children from is
already inside the clipRect().
Auto-test included.
Task-number: QTBUG-4245 (related to)
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The test (see 02fbfdbd) previously asserted that changing the parent
of a native widget caused a WinIdChange event on Symbian, but not on
other platforms. The test now asserts that:
1. Changing the parent of a native widget causes a WinIdChange
event on all platforms.
2. Changing the grandparent of a native widget causes a WinIdChange
event only on Symbian.
Reviewed-by: Paul Olav Tvete
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A QPointer was set to point to a QWidget by one of its children, during its
deletion. This happens during the child deletion, and after the call to
QObject::clearGuards(), which means that the QPointer becomes a dangling one.
The fix ensures that qt_x11_enforce_cursor will not be called with a
being-deleted QWidget. The included auto-test doesn't test anything, except
that it doesn't crash.
Reviewed-by: Olivier
|
| | |
|
| |
| |
| |
| |
| |
| | |
WinIdChangeEventWidget::event didn't return a value in all codepaths.
Reviewed-by: thartman
|
|\ \
| |/ |
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
| |
1. Added a new test step, winIdChangeEvent, to test that
QWidget::setWinId correctly sends WinIdChange events.
2. The persistentWinId test step check the following assertion:
re-parenting a native widget causes its own winId to change, but not
those of its (native) descendents. This assertion is not true for
Symbian, so this test step has been replaced, on Symbian, by
reparentCausesChildWinIdChange, which checks the inverse assumption,
i.e. that the native descendents' winIds also change.
Reviewed-by: Bjoern Erik Nilsen
|
|\ |
|
| | |
|
|/
|
|
|
|
| |
Currently Windows has no proper cursor support.
Reviewed-by: Thomas Hartmann
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Reset the mouse position to a known state at the start, instead of
depending on what the previous test did.
Reviewed-by: Jeremy
|
|
|
|
|
|
| |
for the Q3Table one, it sometimes fail with XPASS.
There is no point trying to stabilize a failure on a test for a class
we are not likely to touch anyway.
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| | |
Reviewed-by: Trust Me
|
| |
| |
| |
| |
| | |
Task-number: QT-2243
Reviewed-by: thartman
|
| |
| |
| |
| |
| |
| |
| | |
Test does not really make sense on WinCE as it is.
Lists with items size over 5000 are not useful there.
Reviewed-by: Joerg
|
| | |
|
| |
| |
| |
| | |
Reviewed-by: Sarah Smith
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/gui/kernel/qwidget_p.h
src/gui/kernel/qwidget_s60.cpp
|
| | |
| | |
| | |
| | | |
RevBy: Paul Olav Tvete
|
| | |
| | |
| | |
| | | |
RevBy: Trust me
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit b6377f43410b14125a66ffd02acde69cfb6e455e.
The asynchronous handling caused too many headaches with input
methods, which expect the focus status to be updated immediately.
This may break the test case that was originally fixed by this patch
(I cannot find out which one at the moment), but that will have to be
solved in a different way.
Conflicts:
src/corelib/kernel/qcoreevent.cpp
src/corelib/kernel/qcoreevent.h
src/gui/kernel/qwidget.cpp
src/gui/kernel/qwidget_p.h
src/gui/kernel/qwidget_s60.cpp
|
|\ \ \
| |/ / |
|
| | |
| | |
| | |
| | | |
Reviewed-by: Joerg
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Tests showAndMoveChild and rectOutsideCoordinatesLimit_task144779
were made desktop client area dependent so the screen capturing
targets meaningfull rectangles on Windows CE.
Reviewed-by: Joerg
|
|\ \ \
| |/ / |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
On X11 one needs to wait logner for the reply for the window mabager
All the QWidget tests passes on my X11 in about 30seconds now
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Since WindowManager operation are all assync, and we have no way to know if the window
manager has finished playing with the window geometry, this test can't be reliable.
Reviewed-by: Denis
|
| | |
| | |
| | |
| | |
| | | |
We need to wait for more condition before saving, otherwise what
we save is not accurate (and the test fails)
|
|/ / |
|
| |
| |
| |
| |
| |
| | |
On X11 We have to wait we get the size change from the window manager
Reviewed-by: Jason Barron
|
| |
| |
| |
| |
| |
| |
| | |
The test goes in only almost 30seconds now.
But i still have few failures
Reviewed-by: Denis
|
| |
| |
| |
| | |
Reviewed-by: Jan-Arve
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The widget must be created before calling QInputContext::setFocusWidget.
Otherwise we run into an assertion. Yes, this only occurs in debug
configuration but its still annoying...
Cherry-pick of commit d6b8f81a2440e7a507ecbb1becd90ef284510787 from master.
Reviewed-by: thartman
Conflicts:
tests/auto/qwidget/tst_qwidget.cpp
|
| |
| |
| |
| |
| |
| |
| | |
QWS uses alien widgets too, so we need the same logic as the other
platforms.
Reviewed-by: bnilsen
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
activeWindow documentation says: "active window is a visible
top-level window that has the keyboard input focus" and "If you want to
ensure that the window is stacked on top as well you should also call
raise(). Note that the window must be visible, otherwise activateWindow
has no effect."
What we were doing earlier was basically raise. Now we just set the
keyboard focus to underlying native window.
Task-number: 260685
Reviewed-by: Jason Barron
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Before this commit calling setWindowState(Qt::WindowFullScreen) on
a widget instance affected all new widget instances created after this
method.
This bug happened due to fact that window decorations i.e. statuspane
and softkeys visibility was only changed when switching to or from
fullscreen state. In the reported bug it happened that second widget
was initially in Qt::WindowNoState and it was changed to Maximized.
Since window decorations are global not window specific at the moment,
the default decoration visibility for second window is the one to which
previous window has set them. In this case previous window was in
fullscreen and that's why the decorations were visible also for
second maximized window.
Probably the right fix would be to change the decoration to window
specific but that is quite a big change and for now the bug is fixed
with this commit.
Autotest: Excluding new test case, same results before and after.
Task-number: 261048
Reviewed-by: Jason Barron
|
| |
| |
| |
| | |
Reviewed-by: jbarron
|
| |
| |
| |
| | |
Reviewed-by: Trust Me
|