| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/plugins/kbddrivers/usb/main.cpp
tests/auto/qnetworkreply/tst_qnetworkreply.cpp
tests/auto/qwidget/tst_qwidget.cpp
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
The inputContext's focusWidget was not reset when disabling input
methods.
Thanks to Benjamin P.
Task-number: 257832
Reviewed-by: Denis
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In the following configuration, wrect was off-screen and the widget was
not painted:
-scroll area "A"
-contains another scrollarea "B" with 2*WRECT_MAX < size < XCOORD_MAX
-the widget contained in B has size > XCOORD_MAX
-A is scrolled to the the bottom
To fix the issue, wrect is moved to the area where the top level window
is in the widget coordinate.
Task-number: 144779
Reviewed-by: nrc
|
| | |
| |
| |
| |
| | |
Merge-request: 604
Reviewed-by: Marius Storm-Olsen <marius@trolltech.com>
|
| |\ \
| |/ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is mainly a stop-gap solution for 4.5.x. It trades painting performance
for correct painting.
Commit 7988d05da changed the opaque test from q->testAttribute(Qt::WA_OpaquePaintEvent)
to qt_widget_private(w)->isOpaque in qt_mac_update_widget_posisiton. This means
we'll do optimized moves in more cases. Unfortunately it also causes painting errors
in some cases (see the task).
Revert the commit for now to put the 4.5 branch in a god shape.
Task-number: 252295
Reviewed-by: nrc
|
| |\ \
| |/
| |
| |
| | |
Conflicts:
src/sql/drivers/psql/qsql_psql.cpp
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The problem was that we did an accelerated move, i.e. scrolled the
widget's contents in the backing store and repainted the old area. We
cannot do this trick when the widget has been invalidated (show(),
resize()). In this case the widget had never been painted, so we
basically scrolled the content of its parent and the widget itself
appeared as invisible.
Auto-test included.
Task-number: 255117
Reviewed-by: Paul
|
| |\ \
| |/ |
|
| | |
| |
| |
| | |
Reviewed-by: Trust Me
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
QPainter::worldTransform() does not return identity matrix when created
on a redirected widget. It should always be identity by default, and
should only change as a result of QPainter::setWorldTransform. The
reason it didn't return identity for redirected widgets, was that we
translated the shared painter's world matrix directly.
Since we cannot modify the world matrix directly, we have to store
the shared painter's current world transform in a separate matrix
(redirectedMatrix), reset the world transform to identity, and later
combine the redirectedMatrix with world transforms set on the painter.
Note that redirection_offset was in negative coordinates before,
and that redirectionMatrix now is in positive coordinates, hence opposite
signs around.
Auto-test included.
Reviewed-by: lars
Reviewed-by: Samuel
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The fix that was introduced adds regressions, and I don't see a way we
can fix it without breaking someone elses code. So restoring the
original fix that just avoid a crash (autotest by Thierry is included).
Revert "Revert Avoid a crash when setting a focus in a widget
hierarchy containing"
Revert "Setting a focus on a widget hierarchy which contains both
visible and invisible widgets could cause a crash."
This reverts commit be833a4f25a8ec8c3dd7a8ac4fa4b0507c93e7ee.
This partially reverts commit 1a7da7096bbda17197738061902f4489af234bc0
Reviewed-by: Thierry Bastian
Reviewed-by: Prasanth Ullattil
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
invisible widgets could cause a crash.
Also, when there is a widget hierarchy A->B->C and A and C are marked
as visible but B is hidden, when the user gives focus explicitely to
C, we should remember that and respect it when B becomes visible.
Task-number: 254563
Reviewed-by: Thierry Bastian
|
| |\ \
| |/ |
|
| | |
| |
| |
| |
| |
| |
| | |
translucentWidget: On Windows mobile the ColorRedWidget is initially
moved to the taskbar position where it cannot be grabbed.
Reviewed-by: mauricek
|
| |\ \
| |/
| |
| |
| |
| | |
Conflicts:
src/gui/kernel/qcocoaview_mac_p.h
src/gui/widgets/qmainwindow.cpp
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |\ \
| |/ |
|
| | |
| |
| |
| | |
We only want to dump images *if* RENDER_DEBUG is defined.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |\ \
| |/ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The problem was that if you had child widgets of a popup, only child
widgets that had hasMouseTracking() == true received the ToolTip
event. This was because in order for a widget to receive a ToolTip,
it relied on the MouseMove event.
It still relies on the MouseMove event, but the problem with the
previous code was that it did not even *try* to deliver the MouseMove
event to the widget that did not have mousetracking. And it was
the code that "tried" to deliver (QApplication::notify()) the event
that also was responsible of finding which widget it should get the
tooltip from. Unfortunately the previous code did not even enter
QApplication::notify() because of that early cut-off.
The result was that the event was propagated up to the parent widget
(which was the popup) and consumed by the popup. (Nothing would happen
unless the popup itself had a tooltip). This is also how
translateMouseEvent() is implemented in qapplication_x11.cpp.
|
| |\ \
| |/
| |
| |
| | |
Conflicts:
tests/auto/qpainterpath/tst_qpainterpath.cpp
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Each version of Qt has its own set of autotests, therefore
preprocessor directives relating to obsolete QT_VERSION's
are not necessary.
Reviewed-by: Carlos Duclos
|
| |\ \
| |/
| |
| |
| |
| |
| |
| | |
Conflicts:
src/gui/graphicsview/qgraphicsitem.cpp
src/gui/graphicsview/qgraphicsitem_p.h
src/gui/graphicsview/qgraphicsscene.cpp
src/gui/painting/qtransform.cpp
|
| | |
| |
| |
| | |
Reviewed-by: joerg
|
| |/
|
|
|
| |
Task-number: 201649
Reviewed-by: Thierry
|
| |
|
|
|
|
|
|
|
|
| |
When a toplevel window is the widget that can accept keyboard input,
it doesn't get focus when shown. The fix is to check if the toplevel
is activated and noone has focus, then give focus to the toplevel
itself.
Reviewed-by: Brad
Task-number: 244607
|
| |
|
