On Mon, 6 Aug 2018 14:22:43 +0200 Mitch Curtis <[email protected]> wrote:
> 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? Correct, in this case it's the chooser element the one in charge of providing the delegate, so it should have a fallback nested inside. That's also the way the patch currently works. However, this approach also lets one define a completely opaque subclass of QQmlAbstractDelegateComponent (private API, mind you) that doesn't require nesting anything inside in QML, and does all the magic internally. For example, imagine having a special use case where you get the delegate QML code (or QQmlComponent*, if one wants to be efficient) from the model itself. The special chooser would just get the QQmlComponent from the model and return it. It may not be present, so in this case it would have to return a plain Item or whatever is situationally required (may have to be some other class). _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
