diff options
author | Andreas Aardal Hanssen <andreas.aardal.hanssen@nokia.com> | 2009-09-24 14:25:14 (GMT) |
---|---|---|
committer | Andreas Aardal Hanssen <andreas.aardal.hanssen@nokia.com> | 2009-09-25 08:02:23 (GMT) |
commit | 45bf804ce2feec74bd7787a64d72184da9458254 (patch) | |
tree | c6e454a6c31a626151d3205502dfe8d50a6103f0 /config.tests/unix | |
parent | ed730bf7807bf77714337096d036b101256e7ac6 (diff) | |
download | Qt-45bf804ce2feec74bd7787a64d72184da9458254.zip Qt-45bf804ce2feec74bd7787a64d72184da9458254.tar.gz Qt-45bf804ce2feec74bd7787a64d72184da9458254.tar.bz2 |
Add QGraphicsItem::stackBefore(), and fix Z ordering bugs.
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
Diffstat (limited to 'config.tests/unix')
0 files changed, 0 insertions, 0 deletions