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.
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
