[Development] QTCS2019 Notes from QtQml session

[Robin Burchell]

On Tue, Nov 26, 2019, at 8:56 AM, Ulf Hermann wrote:
> We're also changing the way views and delegate work. If you want to use 
> the "index" in a Repeater's delegate you'll have to declare that in QML 
> 3, using a required property:
> 
> Repeater {
>      model: 10
> 
>      Text {
>          required property int index
>          text: "item " + index
>      }
> }

Can you explain a bit more about what the concrete problem is with model data on delegates? Speaking specifically about inline delegates[1] like the one you give here.

In many cases, like the one you provide, is the additional required statement really required? ;-) - when it's clear that the component is a delegate, it seems rather redundant and annoying to have to specify additional 'required' statements to be able to use the data that is always provided by the model's context.  I don't see why it makes sense to require an inline delegate to say "hello, I am a delegate, please give me a delegate's properties" when you already specified that it is a delegate when you wrote the component a line or two above.

Perhaps I'm missing something, or perhaps this will only apply for external delegates in a different file - but my opinion is that for inline delegates, I think it would be an acceptable limitation to continue to 'hijack' model/modelData/index on a permanent basis without any additional syntax.

Given that such inline delegates are so very, very frequently used, I think that the bar for changing how that works in a user-visible way should be quite high.

[1]: I suppose this would only really apply for inline components, too, where it's clear that the component is used only in conjunction with the view in question, but I think that's fine. Inline delegates are way more common than external delegates (IME) and are also written as throwaways quite frequently during quick prototyping, which should be as easy as possible ideally.

If your delegate gets complicated enough to split out to a separate file for reuse or autotesting purposes, then sure, requiring a specification of what that component uses of course makes a lot of sense, and I would be in full favour of that, having been bitten by a few bugs in those cases.