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.

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.

We don't need to call two times itemChange when an item is deleted.
Previously we were calling two times itemChange on the parent to give
QGraphicsItem::ItemChildAddedChange. We don't need that. One is enough.

Update the text of the About Qt dialog, as directed by Legal. Note that
this change breaks string freeze as the text is translatable, however
Legal has decided that shipping legally correct text has priority over
shipping complete translations. This change includes updated .ts files
to correct the source strings, but no updated translations.

This change also removes out-of-date licensing text from the About
dialogs of Designer, Assistant, Linguist, QtConfig and qdbusviewer.
Those particular changes should not break translations as they only
remove translatable strings and do not modify any others.

Cocoa's font manager uses "first responder" which is a great idea, but
breaks as soon as we change windows. Thankfully we can just set the
target and we are OK. An upshot is that we don't need the delegate, but
I'm not going to push my luck on that.

BT:Stop widgets disappearing in unified when clicking the toolbar button

The comment in the code pretty much says it all, so I'll repeat it:

This is a workaround for NSToolbar. When a widget is hidden by
clicking the toolbar button, Cocoa reparents the widgets to another
window (but Qt doesn't know about it). When we start showing them,
it reparents back, but at this point it's window is nil, but the
window it's being brought into (the Qt one) is for sure created.
This stops the hierarchy moving under our feet.

Doc - Some minor cleanups in the documentation of QInputDialog. Also
marked getInt() as since Qt 4.5 and finally modified the StandardDialogs
example to reflect the fact that getInteger() is deprecated.

This has to do with coalesced updates. The easy fix for now is
to fix QtDemo itself, meaning: always use a steady timer for
redrawing the viewport of the graphics view (as opposed to let
each item on screen calling update whenever they move)

Update the item if the text has changed but the boundingRect is the
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.

The NSOpenGLContext seems to be tied to the window. So if the view
changes from one window to another, the OpenGL context needs to be
cleared. We can do this by hooking into the viewWillChangeWindow and
viewDidChangeWindow events and clear and reset the drawable
respectively. We also found out that QCocoaOpenGLView was not being used
at all, so just remove it to get rid of any confusion.

We did not update initGtkWidgets on theme changes which could
lead to crashes as the contents of the widget hash depend on
certain properties in the style. A simple way to reproduce this would
be to change between the redmond gtk theme and cleanlooks.

BT: Fix a regression to 4.4 in Graphics View's handling of child clippers

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.

QGraphicsView: Rubber Band drag mode not updated correctly when scrolling [regression]
The problem was that we didn't update the new region when we paint the
rubber band and we scroll at the same time
BT:yes
Task-number: 245766Reviewed-by: bnilsenReviewed-by: andreas
(cherry picked from commit 0f6950e11389a3ddf657116a98ee8f4ec0753eb4)

This change shows a limitation in Graphics View caused by QPen's
default width being 0 (cosmetic), while Graphics View actually
does not support cosmetic pens at all. Because items are at risk of
drawing lines that poke 1 pixel outside their bounding rect,
QGraphicsView must look for items that are up to one pixel
larger than their bounding rect mapped to viewport coordinates.

Furthermore, mapToScene(QRect) forces us to adjust the
input rectangle by (0, 0, 1, 1), because it uses QRect::bottomRight()
(etc) when mapping the rectangle to a polygon (which is _wrong_). Since
this behavior has been there since 4.2, we don't want to fix it in
a 4.5 patch release...

The only _proper_ fix to this problem is for the view to know the item's
"adjust" in device coordinates, allowing items to use cosmetic pens
freely. Fex, we could introduce QGraphicsItem::viewportMargins() or so.

RevBy: TrustMe
AutoTest: tst_QGraphicsItem::boundingRegion() pass again
Details: The original code adjusted the QRect version of a mapped bounding rect,
wheras my patch adjusted a mapped bounding rect (QRectF) and then
converted it to a QRect.
(cherry picked from commit 416fd77e653d089b7832002a68d5b7725fa492db)

RevBy: Andreas
AutoTest: Still pass
Details: QRectF::intersects does not work with flat rectangles, so
we cannot intersect the bounding rect without adjusting it
first.
(cherry picked from commit 3dc62362f3380fa653bc1225ce06e5e4cefa745a)

RevBy: Andreas
AutoTest: tst_QGraphicsView::itemAt2 pass again
Details: A QPoint in the view has to be mapped to a pixel in the
scene, otherwise it won't be possible to e.g. click
on items that are smaller than a pixel.

We can shortcut quite some calculations for the common case
by first checking whether the point is contained in the
control point rect.
(cherry picked from commit bc3d96a902d16a9bb358c05de9f6bfede3594731)

AutoTest: Still pass
Details: Get rid of QTransform::inverted()/operator*= and do
nothing if the item clips all its children and the update
rect is outside the bounding rect.
(cherry picked from commit 9ed299a3edba92791e1c5af64b8fd9c9fe74c0ea)

RevBy: Andreas
AutoTest: still pass
Details: Adds emptyClipPath bit, a cut-off to test if the item
has an empty clip path (i.e., is clipped away). Also adds
code for invalidating the cache from inside setPos().
(cherry picked from commit c1909321a486621ef196dd4bb3cf354406d86d46)

RevBy: Alexis
AutoTest: Still pass
Details: findItems() does almost exactly the same as
QGraphicsView::items, the only difference is that it checks
whether we are about to redraw all items. Next step
is to optimize the items_helper functions.

The patch does also include a fix for
::items/childItems_helper(const QPainterPath ...); it didn't
take Qt::Intersects/ContainsItemBoundingRect into account
(in the same fashion as we do in the other helper functions).
(cherry picked from commit f4547b98b52bfc95fb0c14ec58df204cfcec0db2)