[Development] Programmable delegate selection for QML views

[Paolo Angelelli]

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.


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