[Development] Models for QML (was Re: The future of smart pointers in Qt API)

[Shawn Rutledge]

> On 3 Feb 2020, at 10:26, Ola Røer Thorsen <ola at silentwings.no> wrote:
> 
> - The biggest struggle I have with Qt currently regarding pointers is when you share a dynamic model of QObject* to qml. Here it would actually be useful to have shared_ptr, and I've solved this with some Q_GADGET-based wrappers. (One could argue I should not share QObject* stuff in a model, but putting everything in model roles does not scale well when the objects have properties that change often, or have properties to other objects. Hard to maintain, redundant code, no error handling in qml if a role is mistyped, and QVariant's performance is not good.) 

Yes QVariant gets in the way.  But AFAIK there is no plan to change it, because QAIM is too entrenched.  (How else can you write one model that will work for views in both widgets and Quick?)

What do you see as the argument against putting QObjects in models then?  I tend to think if you are creating a model for a table or a list, you can probably store your data more compactly as an implementation detail of a model rather than as a vector of QObject*; but OTOH if you already have QObjects for some other reason, it’s OK to expose them, isn’t it?  Or if your data set is bounded, not too big, maybe there could even be reasons to prefer a vector of objects?  (Apropos https://codereview.qt-project.org/c/qt/qtwebengine/+/286972 : I’m not sure that should really be a QALM.  I started thinking that it is not how I will choose to expose a list of links to a widget-based view, so maybe I can reconsider how to expose it to Qt Quick too.  But the usual argument is that it’s wasteful to create QObjects just for the sake of it: not items, not widgets; and in this case they have no other reason to be QObjects.  But what else could they be?  Gadgets?)

I’m also curious about your solution with Q_GADGET, since gadgets have some shortcomings in QML (some of which I hope we will improve in Qt 6).  If we continue with the existing restriction that a gadget is always passed between QML and C++ by value, never by pointer, then any gadget that stores “too much” data to copy every time should have a d-pointer, right?