[Development] Moving itemmodels classes to QtCore

[Stephen Kelly]

Hi there,

I propose to move the following files into QtCore (along with their 
implementations, omitted for brevity):

* itemviews/qabstractproxymodel.h
* itemviews/qidentityproxymodel.h
* itemviews/qsortfilterproxymodel.h
* itemviews/qitemselectionmodel.h

There are other possible candidates to move (QStandardItemModel, 
QStringListModel), but I wanted to start as small as possible. Any objection 
to this won't center around those classes.

The descision to move them centers around these points:

* Are they useful classes?
* Is it useful to move them?
* Do they have a future or will they be replaced some time in Qt 5.x?

The rationale is that I want to be able to use QSortFilterProxyModel with QML 
guis, and I want to be able to use QItemSelectionModel with QML guis without 
depending on QtWidgets (which has no maintainer). Currently QML has no useful 
way to represent a selection (highlight doesn't cut it. That's kind of close 
to the currentIndex, but there's still no selection). 

Alan keeps stating incorrectly that QItemSelectionModel is only relevant to 
multiple selection, and that multiple selection is not a concern for QML 
(niche usecase apparently...). 

QItemSelectionModel is useful even without considering the multiple selection 
use cases. It notifies when the selection changes (QML and C++ can listen), and 
it allows the selection to be programmatically updated by C++ and by QML. Both 
of these features are essential if eg, you want to restore selection on 
application restart, or you want the content of one view to relate to the 
selection (where that selection might be updated due to a user clicking an 
item in a different view, or programmatically).

These are useful classes.

Because QtWidgets has a bit of an uncertain future (currently not maintained), 
I don't like having these classes in there, because I wish to maintain them. 
With out-of-step releases, QtWidgets might enter an unreleasable state due to 
something unrelated, meaning the maintained classes would not be released.

These classes depend on nothing in QtWidgets, and can be used without the 
QtWidgets views - They can be used in QML views. They only depend on QtCore. 
Having to deploy and link to QtWidgets without concrete reasons to ("I need 
widget stuff") is undesirable.

It is useful to move them to QtCore.

No one seems to have any concrete plans to replace the QAbstractItemModel 
based model framework. QtQuick people have plans regarding representations of 
lists, and consuming those new lists with table-like-views in QML, but have 
apparently no intentions about representing trees with QML, so there is no 
replacement for QAIM. If the QtQuick people put together new public API for 
representing a model of a updating list, that would not be a replacement for 
QAIM, but might be 'easier'.

A replacement API capable of being used for trees would end up just as 'hard' 
as QAIM is if it is to support relevant usecases. The biggest cause of the 
QAIM stuff being hard is the lack of beyond-entry-level documentation on how to 
use it.

There is a good deal of implementations of the QAIM interface in the wild, and 
they are not going to be ported overnight to a replacement API if such a thing 
becomes available.

A replacement API would not work with hybrid applications of QtWidgets and 
QML. Hybrid applications will remain for years.

These classes are relevant, have a future for the lifetime of Qt5 and are 
maintained. It doesn't make sense to have them contained in a module for which 
none of those things are certain.

The options are to move them into QtCore (preferred), or to create a new 
module (not worth the overhead) which QtQuick and QtWidgets would depend on.

Thanks,

-- 
Stephen Kelly <stephen at kdab.com> | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20111122/1a71d058/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20111122/1a71d058/attachment.bin>