[Development] QtQml Loader API

[Alan Alpert]

On Mon, Dec 10, 2012 at 8:15 PM, Martin Jones
<martin.jones at qinetic.com.au> wrote:
> On Tue, Dec 11, 2012 at 1:32 PM, Alan Alpert <416365416c at gmail.com> wrote:
>> 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. For example, Repeater assigns items to the
>> Item::children property and Loader has visual sizing behavior. We
>> can't just disable that functionality if the delegate is non-visual,
>> because (aside from being a terrible API) we want the functionality in
>> the QtQml import.
>
> It should be noted that since e8206bf6ab6ef62b5dd24bf002aa56edecbcec97
> Loader can instantiate non-Item types, so you do have some of this
> functionality available now, though, as you've noted above not in the
> right place.
>
>> So lets start thinking about the potential API for
>> this functionality. Here's my first thoughts.
>>
>> 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
>> }
>>
>> 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?
>
> I definitely think it's worth two types.  The status property,
> onLoaded handler, etc. of Loader are quite useful, but don't make
> sense for a multi-object loader.

Why don't these make sense for a multi-object loader, and why are they
still useful here? They're needed on loader because they refer to
component status because the component can be specified either through
source (where the component is managed internally) or sourceComponent
(where the component is provided). While I understand the convenience
of specifying the component by a source URL, I don't think that's
really as necessary in the QtQml module where developers are
presumably more comfortable using the Component type explicitly (it is
one of the main types in the QtQml module).  If the component is
always specified through an actual (or implicit) component in the
delegate property, then the QML loading status is available on the
Component in the delegate property. I think the delegate loading
status is just as valuable for the multi-object loader case, it's
exactly the same status and here it's exposed in exactly the same way.

The useful parts are the properties over the status of the
instantiation. The active property (and the existence of anything in
the object/objects properties) are all that are exposed right now, but
perhaps there should be more status information and control over that?
For example the asynchronous property might make sense here (although
it would also need to be added to Component), but I'm thinking that
might be in the second version.

--
Alan Alpert