| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| |
| |
| |
| |
| | |
into kinetic-declarativeui
Conflicts:
src/corelib/animation/qanimationgroup.cpp
src/corelib/animation/qvariantanimation.cpp
src/gui/graphicsview/qgraphicsitem.cpp
|
| | |\
| | |
| | |
| | |
| | |
| | |
| | | |
into kinetic-statemachine
Conflicts:
src/gui/graphicsview/qgraphicsitem.cpp
|
| | | | |
|
| | | |\
| | | |
| | | |
| | | |
| | | | |
Conflicts:
src/gui/graphicsview/qgraphicsitem.cpp
|
| | | /
| | |
| | |
| | | |
repository to the new repository
|
| | |\ \
| | | |
| | | |
| | | |
| | | | |
Conflicts:
src/gui/graphicsview/qgraphicsitem.cpp
|
| | / / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
kinetic-declarativeui
Conflicts:
configure.exe
src/gui/graphicsview/qgraphicsscene.cpp
|
| | |\ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Conflicts:
tools/macdeployqt/shared/shared.cpp
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
QGraphicsItem::deviceTransform() returns the item-to-device transform,
provided with the device-to-scene transform, and combining it with the
item's scene transform. This function is meant to handle items that
enable ItemIgnoresTransformations, but it happened to not work properly
for items that _don't_ enable that flag. Unfortunately this bug is
hard to work around for users from the outside, as it requires you to
check if the item or any ancestor enables ItemIgnoresTransformations.
The fix also removes unnecessary branchs inside QGV so that we use the
same function for all items.
Reviewed-by: bnilsen
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The bug report came from the Declarative UI project as part of Kinetic.
In FxFlickable the mouse is explicitly grabbed inside the mouse press
event handler, and it's (explicitly) released in the release handler.
When doing this, lastMouseGrabber is 0, and the double-click is delivered
as a press. The fix is to not convert the double-click to a press if the
receiver is the first and only mouse grabber (i.e., lastMouseGrabber is
0).
The fix isn't entirely correct, as it can in theory allow an item to
receive a double-click event as the first received event. This seems
to only be possible in the case of using explicit mouse grabbing in
combinations with the press and release event handlers so it's quite
a corner case.
Reviewed-by: Alexis
|
| | |\ \ \ \
| | |/ / /
| | | | |
| | | | |
| | | | | |
Conflicts:
tests/auto/qgraphicsview/tst_qgraphicsview.cpp
|
| | | |/ /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In QGraphicsScene::_q_emitUpdated() the slot
QGrpahicsView::updateScene(QList<QRectF>) gets connected and a boolean
(connectedToScene) is set to prevent double connections. The problem is
that this boolean was not reset when the view gets a new scene.
Task-number: 253415
Reviewed-by: andreas
|
| | | | | |
|
| | | | | |
|
| |\ \ \ \
| |/ / /
| | | |
| | | | |
kinetic-declarativeui
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
That code is only executed if the environment varible
QT_GRAPHICSLAYOUT_DEBUG is set to1
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Luckilly, that bug was only there if you had QT_GRAPHICSLAYOUT_DEBUG
set as an environment variable.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
Re-do of dae02071a9e985b3ea847f08af6849ff2daad3c3
|
| |\ \ \ \
| |/ / /
| | | |
| | | | |
kinetic-declarativeui
|
| | |\ \ \
| | |/ /
| | | |
| | | |
| | | |
| | | | |
Conflicts:
src/gui/painting/qbackingstore.cpp
src/gui/painting/qwindowsurface_raster.cpp
|
| | | | |
| | | |
| | | |
| | | | |
Reviewed-by: nrc
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This commit reduces the memory footprint of QGraphicsWidget by
around 40% (from around 663 bytes to around 409 bytes - measured
using /proc/<pid>/statm on Linux - see 'man 5 proc').
The technique used is to lazily allocate (on the heap) certain
data structures (i.e. not allocate them unless they are needed):
- QGraphicsLayoutItemPrivate::userSizeHints
=> used only if the size, width, or height is explicitly set
- QGraphicsWidgetPrivate::margins
=> used only if the contents margins are accessed
- QGraphicsWidgetPrivate::windowFrameMargins
=> used only if the window frame margins are accessed
- QGraphicsWidgetPrivate::windowData
=> used only if the graphics widget is a window
In addition, a few unused data members (and related code) were removed:
- QGraphicsWidgetPrivate::contentsRect
- QGraphicsWidgetPrivate::mouseDelta
- QGraphicsWidgetPrivate::*LayoutItemMargin
Reviewed-by: andreas
Task-number: 251592
|
| |\ \ \ \
| |/ / /
| | | |
| | | | |
kinetic-declarativeui
|
| | |\ \ \
| | |/ /
| | | |
| | | |
| | | |
| | | | |
Conflicts:
src/gui/kernel/qcocoaview_mac_p.h
src/gui/widgets/qmainwindow.cpp
|
| | | |\ \ |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The problem was that we discarded update requests for fully
transparent items, which is correct, but we even did that
when the update was issued from QGraphicsItem::setOpacity.
We don't have to, and shouldn't, consider the opacity in
that case. Whenever we reach the fullUpdateHelper call in
setOpacity it means we have to do an update regardless of
the current opacity (oldOpacity was not 0.0 if the
currentOpacity is 0.0).
Auto-test included.
Task-number: 252913
Reviewed-by: Andreas
|
| | | |/ /
| | | |
| | | |
| | | | |
Task-number: 252287
|
| |\ \ \ \
| |/ / /
| | | |
| | | | |
kinetic-declarativeui
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The problem was that mouse move events were not forwarded to the scene
when mouse tracking was explicitly enabled on the view.
Mouse tracking is disabled by default unless the scene contains
an item that accepts hover events or has a cursor set.
A mouse move event can only occur if:
1) a mouse button is pressed while moving the mouse
2) mouse tracking is enabled
That means the part I've reverted was only hitting when
mouse tracking was explicitly enabled, which is wrong.
We always have to forward mouse move events to the scene if
the view is getting them in the first place.
Auto test included.
Reviewed-by: Andreas
|
| |\ \ \ \
| |/ / /
| | | |
| | | | |
kinetic-declarativeui
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
While working on layering in Graphics View I stumbled over this bug. The
QGraphicsItem::childrenBoundingRect() function had an accumulating error
caused by recursive adding of rectangles that individually were mapped to
the local parent using QGraphicsItem::mapRectToParent() /
QTransform::mapRect. This caused the brect to be way too large for items
with children that are rotated (fex, alternating 45 and -45 degrees).
The new version should be just as fast, but with no loss of precision.
Reviewed-by: bnilsen
|
| |\ \ \ \
| |/ / / |
|
| | |\ \ \
| | |/ /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
src/gui/graphicsview/qgraphicsitem.cpp
tools/qdoc3/test/assistant.qdocconf
tools/qdoc3/test/designer.qdocconf
tools/qdoc3/test/linguist.qdocconf
tools/qdoc3/test/qmake.qdocconf
tools/qdoc3/test/qt-build-docs.qdocconf
tools/qdoc3/test/qt.qdocconf
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
into it."
This reverts commit 0985805ab3c7de5b15c115a98afb15944b6d93b9.
The Elastic Nodes example shows a black background for the cache pixmap
if the call to fill isn't there. Alexis and I both agree that it makes
no sense that we fill the pixmap with transparent pixels instead of
just drawing with QPainter::CompositionMode_Source, but since this
regression was introduced after 4.5.0 was released we must revert before
we investigate further.
Reviewed-by: Alexis
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This fixes a bug in 4.5.0 where cached items that call update() after
they have been moved or transformed failed to get a call to paint(),
so the last cache image was used to draw. The easiest way to reproduce
this bug is in the Elastic Nodes example. If you press, wait, then
release, the nodes will consistently move to sunken state, then back
to normal state. But if you click quickly while moving the mouse, the
nodes will stay sunken.
The bug was that the item was marked as dirty as a result of being moved,
and when the mouse button was released, the node item's call to update()
was discarded, as the item was "already dirty".
The fix is to allow invalidation of the cache even if the item is
marked as dirty.
Reviewed-by: bnilsen
|
| | | |/
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously we were calling two times itemChange on the parent to give
QGraphicsItem::ItemChildAddedChange. We don't need that. One is enough.
BT : yes
Task-number: BT
Reviewed-by: Andreas
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
same.
updateBoudingRect update the item only if the boundingRect change
but if we have 123 as an initial text and then we set 321 as the new
text, then nothing happen because the rect is the same.
In case the boundingRect change then we call update 2 times but
the item is already dirty so the second call will just return.
BT:yes
Reviewed-by: Andreas
|
| | | |
| | |
| | |
| | |
| | | |
Reviewed-by: Joao
Reviewed-by: Kavindra
|
| | | | |
|
| | | | |
|
| |/ / |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The QGraphicsView::mapToScene(QRect) function assumes that QRect and
QRectF share semantics for ::bottomRight(). However, since QRect follows
Qt 3 semantics (the rect is based on viewport pixels and (0,0,1,1) is
equivalent to one pixel, topleft = bottomright), this function gives
unexpected behavior: map(0,0,1,1) gives you an empty polygon! To work
around this, users of the function need to adjust their rectangles
with (0,0,1,1) to get the correct behavior, matching what QRectF does.
QRectF(0,0,1,1).bottomRight() == QPointF(1,1)
QRect(0,0,1,1).bottomRight() == QPoint(0,0)
Reviewed-by: TrustMe
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Change fd4d94df4eb16e9e54f61dd8ee45914e24832ae9 introduced mouse grab
and keyboard grab support to Graphics View (this was as part of 4.4).
The change was missing a large set of autotests that I wrote to test
the behavior of these features. As part of task 245317, which involves
investigating modality in Graphics View, I figured it would be a good
idea to start off but reconstructing these autotests. So this change
is mainly about adding autotests for mouse grabbing. And of course,
as it always is, I found two bugs while writing these tests.
1) Calling QGraphicsItem::grabMouse() while the item is holding the
implicit mouse grab will now upgrade the implicit grab to an
explicit grab.
2) Adding a popup to the scene will automatically grab the mouse.
Before, the popup would get the grab on show(), but if it was
already visible when added to the scene it would not gain the
grab.
Task-number: 245317
Reviewed-by: jasplin
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
same.
updateBoudingRect update the item only if the boundingRect change
but if we have 123 as an initial text and then we set 321 as the new
text, then nothing happen because the rect is the same.
In case the boundingRect change then we call update 2 times but
the item is already dirty so the second call will just return.
BT:yes
Reviewed-by: Andreas
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Make use of QPolygonF::translated and QPainterPath::translated to ensure
all mapToParent functions follow the exact same pattern. This makes it
clear that the functions do the same and do it the same way.
Reviewed-by: bnilsen
|
| |\ \
| |/
| |
| |
| | |
Conflicts:
src/gui/graphicsview/qgraphicsitem.cpp
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Regression caused by optimizations in QGraphicsItem and QGraphicsScene.
The changes in QGraphicsItem fix bugs in QGraphicsItem::mapToParent
functions, which did the translation before applying the transformation,
instead of the other way (transform, then translate). This bug caused
almost all mapToParent and mapRectToParent functions to behave wrongly.
Unfortunately the new helper functions in QGraphicsScene for discovering
items made use of these functions, which introduced a regression. Fixing
these functions also fixes item discovery.
The other part of this change fixes a regression caused by c1909321,
which luckily happened after 4.5.0 and never saw the light of day. The
fix is to also invalidate the cached clip path even if there is no scene,
which is necessary if you build your scene graph outside the scene, and
finish off by adding the root item to the scene.
Task-number: 250680
Reviewed-by: Alexis
|
