On Mon, 6 Aug 2018 15:34:00 +0200
Pierre-Yves Siret wrote:
> > - 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 : "
On 08/06/2018 05:03 PM, Mitch Curtis wrote:
-Original Message-
From: gr3...@gmail.com On Behalf Of Pierre-Yves
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
> -Original Message-
> From: gr3...@gmail.com On Behalf Of Pierre-Yves
> Siret
> Sent: Monday, 6 August 2018 3:34 PM
> To: Mitch Curtis
> Cc: Paolo Angelelli ; development@qt-project.org
> Subject: Re: [Development] Programmable delegate selection for QML views
>
2018-08-06 14:22 GMT+02:00 Mitch Curtis :
>
>
> > -Original Message-
> > From: Development > project.org> On Behalf Of Paolo Angelelli
> > Sent: Monday, 6 August 2018 1:43 PM
> > To: development@qt-project.org
> > Subject: [Development] Pro
On Mon, 6 Aug 2018 14:22:43 +0200
Mitch Curtis 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
> -Original Message-
> From: Development 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 mi
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 usi