2018-08-06 14:22 GMT+02:00 Mitch Curtis <mitch.cur...@qt.io>: > > > > -----Original Message----- > > From: Development <development-bounces+mitch.curtis=qt.io@qt- > > project.org> On Behalf Of Paolo Angelelli > > Sent: Monday, 6 August 2018 1:43 PM > > To: development@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@qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development >
> - it can only nest (and thus load) QQuickItems, being a QQuickItem itself Loader can wrap QObject too. This works : Instantiator { Loader { QtObject {} } } http://doc.qt.io/qt-5/qml-qtquick-loader.html#sourceComponent-prop : "Since QtQuick 2.0, Loader is able to load any type of object; it is not restricted to Item types." For me 2 and 3 seem to best fit the QML mentality, it's analogous to the model property of views not necessarly being a QAbstractItemModel; it can also be a QList<QObject*>, an int, a QVariantList, etc. and the magic is done behind the curtains to work with all the different types. > 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? A default delegate looks like the sensible way to go indeed. But should we REQUIRE one ? Why can't we just not instantiate something when no fitting delegate is found ? That's what I believe #1 is actually doing. I've not really followed all the development off this feature, but is there a consensus about the choice mechanism of the delegates (vague syntax, potential choice criteria)? >From what I remember it would be based on either index or a role value. For one of my project I've implemented a property editor with Loader and a c++ helper. Basically my helper was returning a list of properties with some info about it: name, type, some additional info when needed (values of an enum). The loader chose the correct source from the type, but it could chose a different delegate for a specific property name. Basically : if (propIngo.name == "myCustomProp") return myCustomComponent; switch (propInfo.type) { case "int": return intComponent; case "string": return stringComponent; // ... Do we want to support this scenario or should we stick with simpler ones ?
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development