MER: Add packaging.
Add displayMarginBeginning/End to ListView and GridView.

This allows displaying content outside the visible area of
the view.

[ChangeLog][QtQuick] Add displayMarginBeginning/End to
ListView and GridView.

Change-Id: Idf9b5a0cd34a781c9603a9ad98ea189754972ba1
Reviewed-by: Alan Alpert (Personal) <416365416c@gmail.com>
MER: Remove property versioning from displayMarginBeginning/End.

These properties were upstreamed for Qt Quick 2.3. Allow them to be
used without "import QtQuick 2.3" here, to preserve previous behavior,
and avoid a partial 2.3 environment.

This hack can go away once jolla-store has been updated, which will be possible
sometime after the 5.2 upgrade.
Fix global object handling in worker script JS files.

Task-number: QTBUG-36874
Task-number: QTBUG-36881
Change-Id: Iacf4807dd37862e792ad1ba4ce540a6d48f1e495
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Make SmoothedAnimation and SpringAnimation smoothly transition again.

Fix regression introduced in Qt 5.0 when animation backend was
rewritten.

Task-number: QTBUG-36709
Change-Id: Ib8caa4bc6a38e3bb4c1d1d3961f775fdd2b342c7
Reviewed-by: Martin Jones <martin.jones@jollamobile.com>
Ensure Behavior stops animating when a new value is set while disabled.

Otherwise the Behavior could cause the property value to end up in an
unwanted and inconsistent state. For example, in the following case:

x: myXValue
Behavior on x { NumberAnimation {} }

x could end up *not equal* to myXValue if myXValue was changed while
the Behavior was still animating but currently disabled.

Change-Id: I3826fdc3f48b2722e778638b116546db7e831e87
Reviewed-by: Martin Jones <martin.jones@jollamobile.com>

Conflicts:
	tests/auto/quick/qquickbehaviors/tst_qquickbehaviors.cpp
Ensure that ShaderEffectSource's texture has correct parameters.

The provider is created on demand in textureProvider(), but its
parameters are set in updatePaintNode() so if updatePaintNode() was
called before a consumer asked for the texture provider, they wouldn't
be set until the next time updatePaintNode() was called.

Change-Id: Iff866d50a8fe16f3d371cb8e590528f5f8c5ee61
Fix delivery of QEvents to QQuickItems

Make them go through QObject::event() and comply to filtering
from objects passsed to QObject::installEventFilter()

Task-number: QTBUG-32004
Change-Id: Ib6972e7f5e588bee986ae5f2d69aa6fccb58af95
Reviewed-by: J-P Nurmi <jpnurmi@digia.com>
Reviewed-by: Alan Alpert <aalpert@blackberry.com>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@digia.com>

Conflicts:
	src/quick/items/qquickitem.cpp
Use fuzzy comparison for another Flickable StopAtBounds case.

Be consistent with 268f4615dcf19aad3603833af83ba28eca886aa5, and use
fuzzyLessThanOrEqualTo when checking whether we are at or past the bounds
when dragging. This prevents a condition where:

1. A Flickable with StopAtBounds is at one of the bounds.
2. A quick flick will sometimes (rarely) cause the Flickable to flick
   past the bounds.

Change-Id: I4165fa133f556fb9d47cc691d11b2ecb77746b33
Reviewed-by: Martin Jones <martin.jones@jollamobile.com>
QQuickTimeLine: add missing time checks

The same check is done in QQuickTimeLine::pause(), move() and moveBy(),
where the time is passed as an argument. QQuickTimeLine::accel() and
accelDistance() calculate the time based on velocity and acceleration
or distance. With tiny values this calculation can result to a negative
time due to integer overflow.

Task-number: QTBUG-35046
Change-Id: I000e73d3f787375946e8f87a5d24153ae919bc8d
Reviewed-by: Michael Brasser <michael.brasser@live.com>
Merge pull request #3 from mbrasser-jolla/mer-stable

Use fuzzy comparison for another Flickable StopAtBounds case.
Merge pull request #4 from mbrasser-jolla/timeline-assert

QQuickTimeLine: add missing time checks
Squashed commit of the following:

commit 52b20d12a3593e776433c4f3ec1c6230755f1445
Author: Gunnar Sletta <gunnar.sletta@jollamobile.com>
Date:   Fri Mar 14 15:15:26 2014 +0100

    Fix potential crash during shutdown for QQuickWindows

    The cleanup() function would deregister the render loop from all
    windows the render loop had seen, but the render loop doesn't see
    windows until the window gets a showEvent and for some implementations
    it was removed as a result of hideEvent. So add explicit tracking to
    QSGRenderLoop which is managed by QQuickWindow's constructor and
    destructor. With this, we no longer need the lists from the
    subclasses, so these functions are removed again.

    Change-Id: I05e5507ad57e23c80bacd99752654cc7d0890dc1
    Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>

    Conflicts:
    	src/quick/items/qquickwindow.cpp

commit 60bec30befb6468db79ab2acac6fcc7a389acca8
Author: Gunnar Sletta <gunnar.sletta@jollamobile.com>
Date:   Wed Mar 5 15:38:02 2014 +0100

    Make sure QSGRenderLoop is cleaned up cleanly.

    e13547c595913c58e6bd6a5ed80fdc729fae7d47 used a global static to clean
    up QSGRenderLoop which is triggered very late, potentially after
    SG backend API plugins have been unloaded. This results in crashes
    when used in combination with scenegraph-playgrounds's customcontext.

    Partially revert the change and instead clean up at the time of
    QApp::aboutToQuit and make sure we also disconnect cleanly from
    all QQuickWindows.

    This change also ensures that QSGRenderLoop::windowDestroyed() gets
    called for all QQuickWindows registered with the render loop. This
    ensures that rendering stops and that scene graph nodes and resources
    will be cleaned up regardless of whether the application has
    remembered to delete the window or not. This is a good thing as it
    makes the scene graph shutdown a bit cleaner.

    Change-Id: I9cb9093979f8eac05542f118a6ff9cfe5c84f745
    Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>

    Conflicts:
    	src/quick/items/qquickwindow.cpp
    	src/quick/scenegraph/qsgrenderloop.cpp
    	src/quick/scenegraph/qsgrenderloop_p.h

Change-Id: I14b60be55ed5fde72f38f48a79edc0b49f853a0c
Merge pull request #6 from sletta/next

[qtdeclarative] Fix crash on shutdown
MER: Fix memory corruption bug

(This patch can be removed when QTBUG-37834 is addressed upstream)

In QQmlData::destroyed(), release the compiledData after
destroying the context instead of before. The context
contains bindings which may contain references to the
compiledData. (At least with V4 bindings)

This might cause heap corruption in QV4Bindings::Binding::disconnect()
because it uses values from 'program' (one of the datas[] values
from a QQmlCompiledData) to possibly modify memory via sub->setActive().

The reads from a freed program are easily reproduced (just start
an app under lipstick and then close it; detected with valgrind).
I haven't witnessed any heap corruption from this but it may be
behind the occasional crashes of lipstick.
(cherry picked from commit 3cfbd9d3176cbbc95bdbe3712f4accdc1485ed55)
Revert "Squashed commit of the following:"

This reverts commit 69b5f133c52b0de0de3aba0bed6d727b5b3db00a.

This broke boosted applications.
Revert "Revert "Squashed commit of the following:""

This reverts commit 656155db64eeb770bd929338ef5416b96ca79a13.
Destroy render loop when QCoreApplication is cleaned up.

Doing it on 'aboutToQuit' meant we would clean it up whenever an
application ran QCoreApp::exec() which could be multiple times
per application run.

Change-Id: I59e06398a551ae7979e3832dff811937037fa106
Don't crash when render node doesn't have a batchroot

Change-Id: Ib8f70414eb477b4ec45097c8784a5fe1375cf012
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>

Conflicts:
	src/quick/scenegraph/coreapi/qsgbatchrenderer.cpp
Merge pull request #8 from sletta/rendernode-crash

[qtdeclarative] Don't crash when render node doesn't have a batchroot