| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
The cache was added in 4.5 and was useful at that time. With 4.6
it is not relevant anymore since the only use case for it is item-lookup
releated to mouse events and collision detection, so the overhead of
maintaining the cache is more pain than gain.
All existing auto tests pass.
|
|
|
|
|
|
|
|
|
| |
The problem was that the 'exposed rectangle' passed to the Item's paint() function was rounded to Int values, whereas the one passed to drawBackground and drawForeground was not.
Autotest included.
Task-number: QTBUG-5859
Reviewed-by: bnilsen
|
|
|
|
|
|
|
|
| |
Correctly set the ItemAcceptsInputMethod flag in setTextInteractionFlags.
Reviewed-by: Andreas
Reviewed-by: axis
Reviewed-by: Janne Koskinen
|
|\
| |
| |
| |
| | |
Conflicts:
src/gui/painting/qbrush.cpp
|
| |
| |
| |
| |
| | |
Task-number: QTBUG-5418
Reviewed-by: Gabriel
|
|/
|
|
|
|
|
|
|
|
|
|
| |
* Get rid of QGraphicsEffectSource from the public API, instead add
convenience functions in QGraphicsEffect. This way we commit to less
API, and are free to introduce a customizable QGraphicsEffectSource
in a future release.
* Move PixmapPadMode into QGraphicsEffect and tweak the names of the
enum values.
* Make QGraphicsBlurEffect::BlurHint into a bit flag, for extensibility.
Reviewed-by: Bjørn Erik Nilsen
|
|
|
|
|
|
| |
Declarative tripped these (crashes).
Reviewed-by:Aaron Kennedy
|
|\
| |
| |
| |
| | |
Conflicts:
dist/changes-4.6.0
|
| |
| |
| |
| | |
Reviewed-by: paul
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When scene is not active, returns the item that would get the focus if
the scene became active.
This is more consistant with Qt 4.5 behaviour
Reviewed-by: Andreas
|
|\ \
| |/ |
|
| |\
| | |
| | |
| | |
| | |
| | | |
Conflicts:
dist/changes-4.6.0
src/gui/kernel/qevent.h
|
| | |
| | |
| | |
| | |
| | |
| | | |
Changes to the gesture api after the review.
Reviewed-by: Jasmin Blanchette
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Oops, apparently we forgot to add a function for unsubscribing a
graphics object from a gesture. Fixing it now.
Reviewed-by: trustme
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is required by the QtDeclarative module. As an isolated change,
this is just a noop. It takes effect when somebody reimpements the
private virtual function.
Reviewed-by: Alan Alpert
|
|\ \ \
| |/ / |
|
| |\ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
However, compiling with QT_NO_ICON will still not work :(
Reviewed-by: tom
|
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | | |
QGraphicsItem::ItemScenePositionHasChanged
Merge-Request: 1945
Reviewed-By: Andreas
|
|\ \ \
| |_|/
|/| |
| | |
| | | |
Conflicts:
src/gui/effects/qgraphicseffect.cpp
|
| |\ \
| | |/ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The task provides an example that doesn't gain input focus when started.
The fix contains two parts: one is to allow items with focus scope
ancestors to become focus items even if the scope is inactive. The other
is to fix up the focusItem pointers on reparent. Before, the focus
scopes' focusItem pointers always pointed to itself, or the next scope.
Now these items are treated no differently than other items in that
respect.
The change has a performance impact when reparenting a large subtree
that has a sub focus item onto another item (one more dig).
Task-number: QT-2331
Reviewed-by: Alexis Menard
|
| |\ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This change allows children of QGraphicsObject-derived classes to check
if the parent is being deleted by checking the private flag wasDeleted.
Reverts 37b16d5cbb4e7bc534f690ebf50434d228b5ecfc, p4 change 9681, to
allow QGraphicsItem to set QObjectPrivate's wasDeleted member before
entering QObjectPrivate's destructor. The original code was in there to
let the user know, via the console output, that QObject was
double-deleted (e.g., when placing QObject on the stack, and also giving
it a parent, so that if the parent is deleted first, bang).
Reviewed-by: Aaron Kennedy
Reviewed-by: Bradley T. Hughes
|
| |\ \ \
| | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | | |
git://gitorious.org/~fleury/qt/fleury-openbossa-clone into openbossa-fleury-fixes3
Conflicts:
src/gui/graphicsview/qgraphicsanchorlayout_p.cpp
src/gui/graphicsview/qgraphicsanchorlayout_p.h
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Reported by Alan. The stackBefore() implementation did not alter the
insertion order if the two items' current Z values were different. The
fix is to ensure it is updated, so that the stackBefore() operation
takes effect should the Z values become equal in the future. Example:
Current order: A-B-C-D
A->setZValue(1);
Current order: B-C-D-A (A moves to the end)
D->stackBefore(A);
Current order: B-C-D-A (unchanged, D is already before A)
A->setZValue(0);
Current order: D-A-B-C (now A moves back, and D moves in front)
Reviewed-by: Aaron Kennedy
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
* Use ExpandToTransparentBorderPadMode since we can use GL_CLAMP_TO_EDGE
to clamp to the texture.
* Shrink the bounding rects reported by the blur
and drop shadow filters (expanding by 2 * radius isn't needed).
* Use a single-pass blur for radii <= 3 to avoid the overhead of
rendering to an FBO.
* Made the fast blur setting generate filters for only a predefined set
of radii, and then use the actual blur radius to spread the sample
points outwards.
* Optimized the generated program to rely less on temporary variables,
as those seemed to not be handled very well by certain GLSL compilers.
Reviewed-by: Gunnar Sletta
|
|\ \ \ \
| | |_|/
| |/| | |
|
| | | |
| | | |
| | | |
| | | | |
Reviewed-by: Trust Me
|
|\ \ \ \
| |/ / / |
|
| | |/
| |/|
| | |
| | | |
Reviewed-by: Trust Me
|
|/ /
| |
| |
| |
| |
| | |
Usable for future optimizations.
Reviewed-by: Samuel
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
QGraphicsObject::parent is actually about the QGraphicsItem
hierarchy, not the QObject hierarchy. This is similar to
QGraphicsWidget, where 'QObject::parent() should always return 0'.
Maybe the explanation in QGraphicsWidget class documentation on this topic
should be merged into QGraphicsObject, too?
Reviewed-by: Andreas Aardal Hanssen
|
|\ \ |
|
| |/
| |
| |
| | |
Reviewed-by: Alexis Menard
|
| |
| |
| |
| |
| |
| |
| | |
This function is moved to graphicsitem private because it is needed by
multi-touch event handling and is not specific to bsptreeindex.
Reviewed-by: bnilsen
|
| |
| |
| |
| |
| |
| |
| |
| | |
This was reported for QGraphicsAnchorLayout, but affects all
QGraphicsLayout subclasses. However, since it is not even handled
properly in QGraphicsItem::setParentItem() it should be fine that we
don't try to deal with this issue. Thus, the layouts are "consistent"
with graphics items when it comes to detection of cycles in the tree.
|
|/
|
|
|
|
|
| |
If an effect is applied repeatedly on the same source, just with
varying parameters, we can save a lot by caching the source pixmaps.
Reviewed-by: Bjørn Erik Nilsen
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: trustme
|
|
|
|
|
|
|
| |
Implemented gestures using gesture events and separate
QGesture/QGestureRecognizer classes.
Reviewed-by: trustme
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Remove all references to "elevation" and how items are sorted by their
"z order". Now use "stacking order" and only refer to "z-value" when
discussing sibling order. Move almost all sorting docs from the
QGraphicsItem::setZValue() function to a general overview section in
QGraphicsItem's class documentation.
Reviewed-by: David Boddie
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This add QGraphicsItem::setPanelModality(), panelModality(),
isBlockedByModalPanel() and the QGraphicsItem::PanelModality enum
(enumerators are either SceneModal, PanelModal, or NonModal, which
mirror Qt::ApplicationModal, Qt::WindowModal, and Qt::NonModal).
Reviewed-by: ahanssen
Squashed commit of the following:
commit a980a1b9c2972c676f3a70e8577d4eace54a25b3
Author: Bradley T. Hughes <bradley.hughes@nokia.com>
Date: Wed Sep 30 14:42:01 2009 +0200
Fix tst_QGraphicsItem::modality_hover() test failures
As pointed out by Andreas, QGraphicsScenePrivate::dispatchHoverEvent()
already has all the logic needed to correctly dispatch the hover
events when changing modality. All we need to do is store the last
known mouse position, and call dispatchHoverEvent() when entering,
changing, and leaving the modal state.
commit ba41633c96ece8da3a8bbf9c7491c15b14f83f76
Author: Bradley T. Hughes <bradley.hughes@nokia.com>
Date: Wed Sep 30 14:40:59 2009 +0200
Fix tst_QGraphicsItem::mixedModality() failure
When changing modality from SceneModal to PanelModal, we may need to
send WindowUnblocked events in addition to the WindowBlocked events.
commit d1076e315de10b1b2fb7617ebaee552c14e49c8b
Author: Bradley T. Hughes <bradley.hughes@nokia.com>
Date: Wed Sep 30 14:33:21 2009 +0200
Update the expected events counts in tst_QGraphicsItem::modality_hover()
HoverEnter and HoverMove always come in pairs, and should do so when
entering or leaving modality as well. This means though that changing
modality can cause spurious HoverMove events (as seen in this test).
commit a29b098e4c391651ef61dd4714a66b22654e4628
Author: Bradley T. Hughes <bradley.hughes@nokia.com>
Date: Wed Sep 30 14:20:25 2009 +0200
Update tst_QGraphicsItem::mixedModality() to do more detailed checking
The test looks for unwanted WindowBlocked/WindowUnblocked events now,
making it easier to spot where the failure comes from.
commit c1ae96126ed01d0e662bddf38ff161e50a804b1c
Author: Bradley T. Hughes <bradley.hughes@nokia.com>
Date: Tue Sep 29 12:17:17 2009 +0200
Documentation for QGraphicsItem::PanelModality
Document the behavior of the QGraphicsItem::NonModal, PanelModal, and
SceneModal enumerators. Corrected a qdoc error in the
isBlockedByModalPanel() documentation
commit 02fec999e660180ff65bbbf79c8085e582879ed1
Author: Bradley T. Hughes <bradley.hughes@nokia.com>
Date: Thu Sep 17 10:31:44 2009 +0200
Add bool QGraphicsItem::isBlockedByModalPanel()
This function can be used to figure out 1) if an item is modally
shadowed and 2) which panel is blocking the item in question.
This will make it possible to implement window-manager like behavior
of activating/highlighting/animating modal panels when the user tries
to interact with a blocked item (this will most likely need to be done
by reimplementing QGraphicsScene::event()).
commit eab9a975dcd71b68135325d479374108bd7f3b2a
Author: Bradley T. Hughes <bradley.hughes@nokia.com>
Date: Wed Sep 16 14:38:55 2009 +0200
Block key events to the focus item if it is blocked by a modal panel.
We don't want the event to propagate either, just stop propagating
once we reach an item that is blocked.
commit 038b61a10bb837b353f988cb0d1665dd53656cdb
Author: Bradley T. Hughes <bradley.hughes@nokia.com>
Date: Tue Sep 15 12:40:27 2009 +0200
Add a test for click-to-focus behavior in the presence of modality
Clicking on a widget should neither give it focus nor set it as the
sub-focus item.
commit 3bb3662556efe8d76af5a56e65b1df7a9f4b476a
Author: Bradley T. Hughes <bradley.hughes@nokia.com>
Date: Tue Sep 8 09:08:42 2009 +0200
Newly blocked QGraphicsItem panels should lose implicit grabs when
modality is enabled.
If an item has an implicit grab when blocked by a modal panel, this grab
is lost and no mouse events are sent until the mouse is released and re-
commit 3be51be3da36e782a5a1f282c552064d5d490a71
Author: Bradley T. Hughes <bradley.hughes@nokia.com>
Date: Thu Sep 3 13:39:14 2009 +0200
Support changing modality from PanelModal to SceneModal or vice-versa
Don't leave modality first, and then re-enter... this sends
unnecessary events.
commit bb0aea559ba01a8bbb03c0370a247ab902f561f5
Author: Bradley T. Hughes <bradley.hughes@nokia.com>
Date: Wed Sep 2 16:58:23 2009 +0200
Fix hover event delivery in the presence of modal panels
Panels that are modally shadowed should not get hover events. When
entering and leaving the modal state, GraphicsSceneHoverEnter and
GraphicsSceneHoverLeave event should be send to the widgets that
become or are no longer blocked.
Auto-test included.
commit cad00b1d9da19565e2d7ea2d30d37eb45005b5ae
Author: Bradley T. Hughes <bradley.hughes@nokia.com>
Date: Wed Sep 2 10:45:20 2009 +0200
Fix tst_QGraphicsItem::modality_hover() test
Don't send hover events to items that are modally shadowed.
commit ae15df331901110e19eb2037f37ff7f84cd7cd16
Author: Bradley T. Hughes <bradley.hughes@nokia.com>
Date: Wed Sep 2 10:44:14 2009 +0200
Enable the ItemIsPanel flag in the modality_hover() test
Otherwise the modality settings are ignored.
commit 1580f43c8feabc3a2bf9c1450e1a8916e8940a4c
Author: Andreas Aardal Hanssen <andreas.aardal.hanssen@nokia.com>
Date: Fri Aug 28 15:20:37 2009 +0200
More work on QGraphicsItem::PanelModality. Added many tests.
commit ed2064ad2ec8bc06d62cf1e931b973d5d92c0563
Author: Bradley T. Hughes <bradley.hughes@nokia.com>
Date: Thu Aug 27 13:45:11 2009 +0200
Add support for modality to QGraphicsItem panels.
This add QGraphicsItem::setPanelModality() and the
QGraphicsItem::PanelModality enum (enumerators are either SceneModal,
PanelModal, or NonModal, which mirror Qt::ApplicationModal,
Qt::WindowModal, and Qt::NonModal).
Reviewed-by: ahanssen
|
|\
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
doc/src/platform-notes.qdoc
src/3rdparty/webkit/WebKit/qt/Api/qwebpluginfactory.cpp
src/gui/graphicsview/qgraphicsitem.cpp
tests/auto/qgraphicsitem/tst_qgraphicsitem.cpp
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
updated
When calling QGraphicsItem::update() on a cached item, the cache is
meant to be invalidated.
In the reported bug, the user had a fixed scene rect
set for his scene, and removing an item caused the entire scene to be
updated (marked as "all needs to be updated"). In this case, calling
update() on the cached item did not cause the item's cache to be
invalidated. The item's new appearance didn't show up until the next
invalidation, which was the same call to update(), but this time without
a preceeding full scene update.
The fix is to always invalidate the cache, regardless. But only
schedule a repaint of the item in some cases (e.g., in this case the
whole scene was marked for update, in which case it's unnessary for this
one item to schedule a repaint of itself).
It's worth noting that in 4.6, removing an item be delete does not cause
the whole scene to be updated, and because of that this error was not
exposed. It's there nevertheless.
Reviewed-by: bnilsen
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When we changed the sibling stacking order to be defined (4.5) instead of
undefined (4.2, 4.3, 4.4), the need to control this stacking order
arose. Before we could just say the order was random, but stable,
and the only way people could rely on order was to set Z. Now, when the
default order is defined as "insertion order", people start relying on
this order, and incidentally they want more control.
In QML, the need to have insertion order semantics is very evident as
the order you define the elements in QML more strongly implies a
graphical stacking order than the imperative order they get when added
in C++.
This change adds QGraphicsItem::stackBefore(const QGraphicsItem *), which
works similarily to QWidget::stackUnder(). It moves the item in front of
the sibling item passed as an argument.
While implementing this function, and writing tests for how this
function behaves in combination with Z values, I found that the code
we had for updating siblingIndex was broken in the case where you remove
an item from the middle of the children list. In this case newly added
items would be assigned the same sibling index order as one that's already
in the list.
So in order to get the tests to pass I had to fix this bug as well.. The
approach is to sort the children list by insertion order, so that we can
fix up the sibling indexes.
Performancewise this has little implications. If there are gaps in
the sibling index list, which only occurs if you remove an item from the
middle of the children list, will the sibling index list be adjusted /
corrected before used (for example, by stackBehind()). Multiple calls to
stackBehind will be fast, and the list is flagged for resorting (including
Z order).
Reviewed-by: jasplin
|
| |
| |
| |
| |
| |
| |
| | |
The C++ autotests have been updated to match the expected behavior
of the examples that broke (e.g., listview.qml) in kinetic-declarativeui.
Reviewed-by: Alexis
|
|\ \
| |/
| |
| |
| |
| | |
Conflicts:
src/corelib/kernel/qcoreapplication.cpp
tests/auto/windowsmobile/test/tst_windowsmobile.cpp
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fix QGraphicsItem to clear clip path for items with an ancestor that
clips to shape. Added autotest to demonstrate clipping path problem.
Merge-request: 810
Reviewed-by: Alexis
Reviewed-by: Andreas
|