[Development] Programmable delegate selection for QML views

[Mitch Curtis]

> -----Original Message-----
> From: Development <development-bounces+mitch.curtis=qt.io at qt-
> project.org> On Behalf Of Paolo Angelelli
> Sent: Monday, 6 August 2018 1:43 PM
> To: development at qt-project.org
> Subject: [Development] Programmable delegate selection for QML views
> 
> Hi,
> 
> as some of you might have noticed, it's several months that some are trying
> to remove a long-standing limitation of the current QtQuick architecture: the
> inability to dynamically select, at runtime, the delegate to use in a view,
> based on whatever approach, either data-driven (typically using row data,
> index, etc), or else.
> 
> The workaround, so far, has been to use a Loader for this.
> The Loader approach has several notable drawbacks, most importantly
> - performance, under different situations
> - it can only nest (and thus load) QQuickItems, being a QQuickItem itself
> 
> 
> 3 possible solutions to this problem have been suggested in the past few
> months, but it seems that no consensus has been reached on what is the
> way to go.
> So what i want to present, in this message, is an overview of these proposed
> solutions, to:
> - understand what is the general preference among the proposed
> approaches
> - see if anyone has other approaches to suggest, that might have been
> overlooked so far
> 
> Currently suggested solutions are all based on a so-called "delegate chooser"
> (or selector), that would be queried whenever a delegate is required.
> The differences are in how to provide such an element to the view from an
> API perspective:
> 
> 1. Add a new property to all view classes (ListView, TableView, ***View
> etc.), where to specify the chooser.
>    The delegate property would be used as fallback, if chooser not present.
>    ( https://codereview.qt-project.org/206670/ )
> 
> 2. Make the chooser subclass QQmlComponent, and pass it through the
> delegate property in place of a regular delegate
>    ( https://codereview.qt-project.org/228909/ , example usage
> https://github.com/paoletto/MIVQVariant ).
> 
> 3. Do not make the chooser subclass QQmlComponent.
>    Instead, use another separate base class, like some
> QQmlAbstractComponentSet.
>    Then mangle things enough so that it could still be passed through the
> delegate property.
>    Reason for 3. (as alternative to 2.) is that there's one school of thought that
> see such a chooser not as a QQmlComponent subclass, while still trying to
> avoid an additional property.

>From reading the comments of https://codereview.qt-project.org/#/c/228909/, I see that it was Simon that doesn't think it should be a QQmlComponent subclass. It would be good to hear more from him about this.

> 
> Ideally, should there be a clear winner, targeting 5.12 could still be viable.
> Thoughts?

At a quick glance, if we can do it with the existing delegate property (#2), it would be nice. That's less complex than having two delegate properties.

One minor problem with this is what we do when none of the delegates match the data type. #1 seems to cover this (https://codereview.qt-project.org/#/c/206670/8/src/qml/types/qqmldelegatemodel.cpp) by requiring that delegate also be implemented if a delegateChooser is provided. How does #2 account for it? I guess with #2 there should be a way to provide a "default" delegate, by e.g. leaving all properties (indexValue, roleValue) unset so that it acts a sort of wildcard?

> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development