[Development] Qt itemmodels in QtQuick context (was: Re: Moving itemmodels classes to QtCore)

[Bart Cerneels]

On Wed, Nov 23, 2011 at 11:04,  <alan.alpert at nokia.com> wrote:
> Bart Cerneels said:
>>I incorrectly assumed that they were already in QtCore along with
>>QAIM. I for one am a big fan of using proxymodels with/from QML and
>>can think of quite a few use-cases.
>
> Note that it doesn't have to be in QtCore to use with QML. QtGui would do just as well, but these QAIM classes have nothing to do with the graphical representation of the data, so QtCore makes more sense. You might use them with a system daemon and CLI interface in theory.
>
>>I also feel there needs to be a brainstorm about how typical GUI
>>elements (icons, images, fonts, etc) interact with models and proxies.
>>Even though it's not a dependency: enum Qt::ItemDataRole is used
>>solely but QAIM and the documentation equates it to QtGui classes like
>>QColor, QIcon and QPixmap. Since we are moving the entire QAIM stack
>>out of QtGui I think the recommended practice of passing data should
>>change to.
>
> GUI is the primary usecase of Qt, and all those classes can be used with the various GUI elements Qt provides already (QtQuick, QWidgets). So it makes sense that even though you can use QAIM without a GUI, you probably will and the recommended practices suggest this.
>
> QAIM helpers are being moved out of QtWidgets, because you might use them without widgets, and I'd be just as happy to see them in QtGui as QtCore (Note: I approve of moving them to QtCore).
>

To clarify: I'm talking specifically about QtGui widgets here, not a
graphical user interface in general. My point was that our
documentation, examples and recommended practices should be adapted to
the use of QAIM and proxies by QtQuick rather then widgets. For
example: rather than passing a QPixmap object via QAIM::data( role =
Qt::DecorationRole ) pass a QString that can be used by
QDeclarativeImageProvider::requestPixmap(). Such a change of practice
is a great way for existing widget based codebases to separate the GUI
and logic on the model level and port to QtQuick with incompatible
changes.

One of the main reasons to use QDeclarativeImageProvider or similar
caches is lazy loading of pixmaps. One of the big problems with QAIM
is using it to pass a blocking resource (like a web-hosted image). If
anything we should be moving away from that if we want to improve Qt
item models.
I'm sure QPixmap, QColor, etc has it's uses in QtQuick 2.0, but that
does not mean they should be used as data delivered by models, unless
the developer knows what  they are doing.