| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| | |
into kinetic-declarativeui
|
| |
| |
| |
| | |
Doesn't seem to hurt anything, and it was ugly API.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
This is probably more correct, but is also the way it used to behave.
|
| |
| |
| |
| |
| | |
Also it should be executed a little later to avoid accidental behaviour
changes.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
createStandardContextMenu should still only cut/copy in normal echo mode
and the Qt3Support function validateAndSet will again only set if it is
validated.
|
| |
| |
| |
| |
| | |
It was accidentally left commented out instead of working with
QLineControl.
|
| |
| |
| |
| |
| |
| | |
QAbstractSpinBox had some code using QLineEdit internals, this had to
be move to use QLineControl as well.
This commit also includes fixing some typos in my last commit.
|
| |
| |
| |
| |
| | |
Didn't notice there were still some TODO markers left. They have now all
been done.
|
| |
| |
| |
| |
| | |
This change to QLineEdit didn't merge, as it needs to be applied to
QLineControl in this case.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Splits out the control logic of QLineEdit into QLineControl, which is
somewhat similar to QTextEdit. This was originally worked on in the
ianws-qt-lineedit-textedit-research repository, and then further
developed in kinetic in the kinetic-declarativeui-qfxlineedit branch.
Note that this also includes a tiny change to qvalidator.h which allows
validators to be used in qml.
|
|\ \
| | |
| | |
| | |
| | | |
Conflicts:
src/gui/graphicsview/qgraphicsscene.cpp
|
| |\ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
src/gui/graphicsview/qgraphicsitem_p.h
tests/auto/qgraphicsproxywidget/tst_qgraphicsproxywidget.cpp
tests/auto/qgraphicsview/tst_qgraphicsview.cpp
|
| | | |
| | | |
| | | |
| | | | |
Task-number: 233342
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
On 64-bit an id (void *) is 64-bit also, so, it really should be a
pointer, but I'll make it a 64-bit int for the time being just so stuff
compiles.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We don't need to draw all the items that are selected. We just need
those whose rect intersects the one from the viewport.
Task-number: 233342
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is basically the Windows version of the bug fixed in change
82e825ed841bce324a6892fcbace03f9936d4f4f
Merge-request: 855
Reviewed-by: Norwegian Rock Cat <qt-info@nokia.com>
|
| | | |
| | | |
| | | |
| | | | |
Task-number: 248688
|
| | | |
| | | |
| | | |
| | | | |
Task-number: 240266
|
| | | |
| | | |
| | | |
| | | | |
The layoutState is already current (ie. already applied).
|
| | | |
| | | |
| | | |
| | | | |
Task-number: 257579
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Maximum number of decimals is DBL_MAX_10_EXP + DBL_DIG
Task-number: 257291
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Most Wacom tablet have a coordinate origin at 0 (Bamboo,Intous), but
some tablet (like DTF 720, which have an integrated screen) have a non
zero coordinate origin. Which lead to an errounous y/a tablet pos
reported by Qt tablet event.
Merge-request: 822
Reviewed-by: Norwegian Rock Cat <qt-info@nokia.com>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Found during manual testing (manualtests/graphicsview/movableitems).
Moving a child item (via its parent) outside the viewport, and then back again
didn't trigger an update on the child. Reason was that we had a cut-off
checking the wrong bit (geometryChanged). This bit means
exactly the same as the paintedViewBoundingRectsNeedRepaint bit, except
that it doesn't propagate to the children (and that's the bug).
We use paintedViewBoundingRectsNeedRepaint instead.
Auto-test included.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Found during manual testing (manualtests/graphicsview/untransformable).
At some point it was not possible to click on an untransformable item.
The problem was that none of the untransformable items were top-levels,
and none of the transformable top-level items were in the same area,
resulting in an empty list of estimated top-level items.
Auto-test included.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Found during manual testing (demos/embeddeddialogs).
The problem was that a full update (right before hiding/deleting an
item) caused the update request made from the destructor to be
discarded.
Auto-test included.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Found during manual testing (dndrobotinproxy). The problem was that the
paintedViewBoundingRect was set to an empty rect because the partial
update area didn't intersect with the viewport. The item itself was
partially inside the viewport. Then, when the item was moved, its old
area was not repainted due to this empty paintedViewBoundingRect.
Auto-test included.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The problem was that update() followed by hide() didn't work as
expected because the update() caused all sub-sequent update requests
to be discareded. This is correct, however, we have to make sure the
ignoreVisible/ignoreOpacity bit is set properly; we won't process a
hidden item otherwise.
Auto-test included.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We can do QRect::intersects/contains/operator| faster than QRect
because we can assume the rects are normalized. Another
important factor is our knowledge about the viewport rect, which is
always QRect(0, 0, viewport->width(), viewport->height()).
Auto-tests included.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Update the scene transform and use it directly in the same fashion as we
do in processDirtyItemsRecursive/drawSubtreeRecursive.
All auto-tests pass
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Use the item's cached scene transform directly instead of always making a copy
of it. Moreover, we don't have to use the transform at all if the scene
transform is a "translate only" transform :-). QTransform already use
the same cut-offs, but it must update the type() before it can find out.
We don't have to check the type() because that is already stored (and we
usually don't call type() when we store the value either).
All auto-tests pass.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This version is easier to read and is slightly faster than the old one.
All auto-tests pass.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
New method: QGraphicsSceneIndex::estimateTopLevelItems.
QGraphicsSceneIndex::estimateItems returns *all* items within the rect,
but we are only interested in the top-levels (those that are within the
rect themselves or have descendants within the rect) when doing
recursive drawing/item-lookup.
All auto-tests pass. Demos/examples/manualtests run fine.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We don't have to do a stable sort anymore because the lessThan operator
now accounts for the insertion order. This also means we don't have to
sort all top-level items to preserve the insertion order in
QGraphicsScenePrivate::topLevelItemsInStackingOrder.
Reviewed-by: Andreas
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This revertes d39a62720ba67a0fa6e4e37519d22f14c7b7404e
(we had to do it with the old implementation, but the new one have
untransformable items included in the indexed list. The only difference
is that untransformable items are also in the untransformable list;
otherwise in the bsp tree).
Auto-test included.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The chip demo was unbelievable slow, so I investigated and found out
the bsp always returned almost all items in the tree (40 000 in this
particular case). It did so because the tree was initialized with
an empty sceneRect. The sceneRect was empty due to a lacking signal-slot
connection, resulting in QGraphicsSceneBspTreeIndex::updateSceneRect
never being invoked.
Auto-test included.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We basically passed an unitialized transform to construct the
styleoptions for items that use the useExtendedStyleOption flag.
We had an auto-test to cover that but for some reason view.show() was
removed by me so the auto-test did nothing. oops.
Reviewed-by:bnilsen
|
| | | | |
|
| |\ \ \ |
|
| |\ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Conflicts:
src/gui/graphicsview/qgraphicsscene.cpp
src/gui/graphicsview/qgraphicsscene_p.h
src/gui/graphicsview/qgraphicsview.cpp
src/gui/graphicsview/qgraphicsview_p.h
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
We have to ensure that the item's top-level is marked as discovered.
This broke the dragandroprobot example after we started using the BSP
from QGraphicsSceneIndex::items()*
(see 6ee3fb750377eeedf161d96fef02c5fa336810e9)
|
| | | | | | |
|