| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
Per http://codereview.qt-project.org/#change,11562, we are trying to remove these
in favour of direct allocation, or (in the case of inline code) specialised
out-of-line wrappers.
Change-Id: I113609c4f97dc5c8020a72cbd398572cdb5b7505
Reviewed-by: Aaron Kennedy <aaron.kennedy@nokia.com>
|
|
|
|
|
| |
Change-Id: I0a8d99909cac867dce72da70b1bbcb649989a51b
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Avoid a linear scan of all cache items and associated accesses by
getting the cache item from an objects vdm attached object instead.
Make the model context property a property of the context object instead
of a separate property on the context object.
Parent the vdm attached object to the delegate object with
QDeclarative_setParent_noEvent instead of passing it in the constructor.
Change-Id: Ib77c5cdb963f3dfe8f2bdef039e010a6bb30140f
Reviewed-by: Martin Jones <martin.jones@nokia.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Add API for inserting data directly into a VisualDataModel which
can be used among other things to create temporary items that are
later resolved to an actual item in the source model.
Task-number: QTBUG-21516
Change-Id: I835f0e8d6c5edfb3a21029687de5b700f7400317
Reviewed-by: Martin Jones <martin.jones@nokia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Derive from QDeclarativeContext and reference count the context object
instead of parenting it to the context. Combined with a weak
persistent v8 handle the allows the context object to be returned by
javascript accessors instead of creating a new instance for every use.
In addition to the efficiency advantages of creating fewer objects,
routing all data access through a single object means that object can
also persist data instead of just acting as a proxy.
Change-Id: I107dc8c901f16f2a4b420ff1cbffa7a6be27de89
Reviewed-by: Martin Jones <martin.jones@nokia.com>
|
|
|
|
|
|
|
|
| |
Update the initial values of the VisualDataModel attached object
when binding to an object.
Change-Id: I2e11c8bf13198e848d11c8cea9885cb64240f941
Reviewed-by: Martin Jones <martin.jones@nokia.com>
|
|
|
|
|
|
|
|
|
| |
The views try and retain their current state as much as possible on
a reset which prevents the current item being set to a valid item as
would happen if the VisualDataModel was completed before the view.
Change-Id: I593a850aeeb58846ab500f193487db4033e26399
Reviewed-by: Bea Lam <bea.lam@nokia.com>
|
|
|
|
|
|
|
|
|
| |
The views parent the delegate items to themselves on creation, before
we delete the package we need to reparent them back to it or they'll
persist indefinately.
Change-Id: I01a36fadb2b0ff1035de46ec2b84a54d73c49bcf
Reviewed-by: Bea Lam <bea.lam@nokia.com>
|
|
|
|
|
|
|
|
| |
Persisted items are still only constructed on demand so we can't
assume the object is non null.
Change-Id: I1ce9563eb3b9fb1ae611e8afcf9c8c74f0563aec
Reviewed-by: Martin Jones <martin.jones@nokia.com>
|
|
This change moves the QtQuick 2 types and C++ API (including
SceneGraph) to a new module (AKA library), QtQuick.
99% of this change is moving files from src/declarative to
src/quick, and from tests/auto/declarative to
tests/auto/qtquick2.
The loading of QtQuick 2 ("import QtQuick 2.0") is now delegated to
a plugin, src/imports/qtquick2, just like it's done for QtQuick 1.
All tools, examples, and tests that use QtQuick C++ API have gotten
"QT += quick" or "QT += quick-private" added to their .pro file.
A few additional internal QtDeclarative classes had to be exported
(via Q_DECLARATIVE_PRIVATE_EXPORT) since they're needed by the
QtQuick 2 implementation.
The old header locations (e.g. QtDeclarative/qquickitem.h) will
still be supported for some time, but will produce compile-time
warnings. (To avoid the QtQuick implementation using the
compatibility headers (since QtDeclarative's includepath comes
first), a few include statements were modified, e.g. from
"#include <qsgnode.h>" to "#include <QtQuick/qsgnode.h>".)
There's a change in qtbase that automatically adds QtQuick to the
module list if QtDeclarative is used. Together with the compatibility
headers, this should help reduce the migration pain for existing
projects.
In theory, simply getting an existing QtDeclarative-based project
to compile and link shouldn't require any changes for now -- but
porting to the new scheme is of course recommended, and will
eventually become mandatory.
Task-number: QTBUG-22889
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Change-Id: Ia52be9373172ba2f37e7623231ecb060316c96a7
Reviewed-by: Kent Hansen <kent.hansen@nokia.com>
Reviewed-by: Sergio Ahumada <sergio.ahumada@nokia.com>
|