[Development] Improving QtQuick internals (was Re: QML engine changes)

Knoll Lars Lars.Knoll at digia.com
Wed Jun 26 20:50:50 CEST 2013


On 6/26/13 8:04 PM, "Alan Alpert" <416365416c at gmail.com> wrote:

>On Wed, Jun 26, 2013 at 10:41 AM, Bubke Marco <Marco.Bubke at digia.com>
>wrote:
>>
>>[...]
>>
>> Better yet, join the discussion if you're interested. As an open
>> project we do need to get better about having the design discussions
>> in the open, and joining those discussions from the tooling side is
>> encouraged. Then you aren't relying on other developers to be 'unsure'
>> about something.
>>
>>
>> Good to hear. So what is the plan for the "PropertyCache"?
>Simon knows better than I, but I think the plan is for it to go away.

Yes, as much as possible, but I'm not sure how fast we can make it happen.
I'm actually looking into related things right now. But first I need to
clean up the QStringHash and related classes.

>> What about a new better list interface(we have prototype here?
>Sounds good! Where's the prototype so I can have a look?
>
>> Maybe add signal compression instead of componentComplete.
>It should remain as a fall-back, but once we have signal compression
>we should consider rewriting all elements to avoid it (so that it's
>just an imperative fall-back method and designer can ignore it).

Yes, I'd agree to this as well.
>
>> Always think about that you need a reverse transformation for direct
>> manipulation(visual to text).
>> Refactor the item code base.
>>   Why do we have parent and parentItem?
>Because we're layering another parent/child hierarchy onto QObject.
>Now that we no longer have the QGraphicsItem implementation detail we
>theoretically could unify them, but we still need to be able to
>traverse the QQuickItem tree efficiently (and provide backwards
>compatibility) and enforce a kind of 'tree-level type safety' where
>QQuickItems are connected to the scene root through QQuickItems. I
>haven't really thought about the possibility of unifying the trees
>before, I'll have to give it some more thought.

I hope that's going to be possible, but I don't think anybody tried yet ;-)

>>   Why do we mix the setParent and child list pattern?
>In the declarative QML you should be using the child list in virtually
>all cases. setParent is more there for imperative code, such as
>creating an object in script (which ideally you'd be doing
>declaratively through the Loader element.

It might also be required for some performance optimisations where I'd
like to create a subtree in a secondary thread and then hook it into the
main QML tree once it's created. But that's certainly 5.3 material :)

Cheers,
Lars




More information about the Development mailing list