[Development] Moving itemmodels classes to QtCore

[shane.kearns at accenture.com]

Hi,

I think moving the item models back into QtGui would be better than QtCore.
* QML and Widgets applications both depend on QtGui
* The item models have no use outside of a GUI application.
* QtGui was the location of these classes in Qt4.


From: development-bounces+shane.kearns=accenture.com at qt-project.org [mailto:development-bounces+shane.kearns=accenture.com at qt-project.org] On Behalf Of Stephen Kelly
Sent: Tuesday, November 22, 2011 16:52
To: development at qt-project.org
Subject: [Development] Moving itemmodels classes to QtCore




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

________________________________
Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy.
______________________________________________________________________________________

www.accenture.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20111123/1cccb553/attachment.html>