[Development] QtQml Loader API

[Charley Bay]

Alan spaketh:

> Finally Qt 5 brings better QtQml and QtQuick separation! Better, not

 perfect. The main things I've heard are missing is dynamic
> instantiation of non-Items. What I propose is a new element for the
> QtQml module which provides that functionality. Note that while some
> people have suggested that Repeater and Loader could just accept
> non-Item delegates, they both provide visual item related
> functionality. <snip>,


The big question about this API is whether it's better served with two
> elements. I'm thinking it could be done with just a single element,
> but maybe it's worth duplicating it to have a Loader-like one (with
> just object) and a Repeater-like one (with just objects). Note that
> Repeater and Loader have some GUI functionality that is different for
> groups versus single objects - Repeater visually reparents all
> children (only really useful for groups) and Loader controls the size
> of its one object (only really feasible for one). Is it worth making
> two separate types?


+1 for two elements, and strong support for the concept itself (QML
instantiation of non-visual elements).

It seems like a good idea to be able to do "Loader" and "Repeater" things
on "non-visual" elements (where setting "size" is not appropriate), which
is DIFFERENT for "visual" items  (which visually re-parents, and sets
size), and thus we might want NEW TYPES for "Loader" and "Repeater" of
non-visual things.

This implies the following possibilities:

  - (1) Loader (sets visual item sizing of new thing)
    - (a) for visual things (have this now)
    - (b) for non-visual things (want?)

  - (2) Repeater (re-parents new thing, assigning into Item::children for
parent)
    - (a) for visual things (have this now)
    - (b) for non-visual things (want?)

Alan's proposal seems to be consistent with the current back-end
implementation:

  QObject (NOT-visual-thing, has "QList<QObject*>" children)
     -> QQuickItem (visual thing, has "QList<QQuickItem*>" children)
         -> QItem (visual thing)

Alan's proposed code:

<snip>,Prototype API of the Instantiator element:

 QtObject {
>     property bool active: true
> property

    property model model: 1
>     property Component delegate //Note Component is in the QtQml module
>     property QtObject object //Convenience for objects[0]

    property list<QtObject> objects

}
>

This is interesting in the case where a QML element wants to "dynamically
instantiate" QObject-items (such as from a C++ model), but the QML element
is not a "visual-thing".

For example, a "QML-delegate" (if present) MIGHT NOT be a "visual" thing,
such as providing a delegate that merely exports-bound-properties from the
C++ object specific to the needs of  a given QML application (whereby many
QML applications may "share" the same C++ back-end-model, but each
"renames/translates" or "subsets" the properties specific to the needs of
each QML application).

Another example might be a C++ model of "QAction" instances (with no visual
consideration) which is exposed to QML, where the QML does not show them in
a "view", but rather, "associates" them with a distributed set of items
(like buttons) that may be visually associated with other (visual) parents.

I re-wrote Alan's proposed code quite a few times, but could not improve
upon what he wrote.

My current impression is that if we had this "non-visual-item-Repeater", it
solves a problem whereby the C++ business logic could be "sliced"
arbitrarily, and I'd never need a (future) QML model that was anything
other than a flat-list (as we have now).

--charley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121211/247ed603/attachment.html>