| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
Happens for example if a DockWidget is undocked and has a child
whith the WA_StaticContents attribute.
The parent does not change (so newParent is false) but still, the
top level widget change. So staticWidget need to be moved to the
new backingstore.
Reviewed-by: Benjamin Poulain
Task-number: QTBUG-6883
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QWidget
with setGraphicsEffect(0).
The effect was not deleted in that case, problem solved for both QGraphicsItem
and QWidget.
Autotest included.
Task-number: QTBUG-5917
Reviewed-by: bnilsen
|
|
|
|
|
|
|
|
|
|
| |
In Symbian we save memory by deleting widget backingstore from
non-visible windows. 12-key FEP is fullscreen and causes the
backing store to be deleted but still continues to scroll the view
to show current caret position in focused lineedit control.
Task-number: QTBUG-5922
Reviewed-by: Jason Barron
|
|
|
|
|
| |
Task-number: QTBUG-5804
Reviewed-by: denis
|
|
|
|
|
|
|
|
|
| |
When enabling/disabling a widget or changing its InputMethodEnabled attribute,
use the focus proxy widget's input context for reset and for setting the focus
widget on the input context.
Task-number: QTBUG-5781
Reviewed-by: Denis
|
|
|
|
|
| |
Task-number: QTBUG-5396
Reviewed-by: axis
|
|\
| |
| |
| |
| | |
Conflicts:
src/gui/effects/qgraphicseffect.cpp
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This broke after commit: a8e2a457bb7d2fc377c1c65b6a4172974919e055
(Add a new event type, WinIdChange). The first thing that happens in
show() is that the top-level is created, and hence we send WinIdChange.
We therefore have to add this event to list of expected events.
Reviewed-by: TrustMe
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | | |
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
|