[Development] QtQml Loader API

[Alan Alpert]

People seem to be generally in favor, so moving the discussion to
codereview: https://codereview.qt-project.org/#change,43607 .

I'm aware that a lot of people are on holiday break, so these changes
won't be merged for two weeks at the earliest. Gives most people who
want to look the chance to do so.

--
Alan Alpert

On Tue, Dec 11, 2012 at 10:31 AM, Alan Alpert <416365416c at gmail.com> wrote:
> 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