even just setting the sort/filter roles is not enough. role names must also be set again!
gaaaah. thankfully this seems to be very fast, though would still be nice to avoid it if
possible somehow.
CCBUG:308101
syncRoleNames is fast (and faster now that we check that the role names actually changed)
but it may be nicer to find a more efficient way in future than checking the role names
on all / any data changes. in fact, the documentation for QAbstractItemModel::setRoleNames says:
"This function must be called before the model is used.
Modifying the role names after the model has been set may result in undefined behaviour."
BUG:308101
The noop check m_sortRole == role has to be removed
because the hash table m_roleIds can change between two calls to
setSortRole (as it actually happens when resync the hash table).
Possibly one could perform a more clever check (i.e. adding some
m_invalidated flag which would override the check), but I am not sure it is
really worth it.
This fixes sorting issues in the Plasma Device Notifier
CCMAIL:notmart@gmail.com
Introduces QAbstractItemModel to QDeclarative when setting up
the plasma core components.
This way we don't have to cast to the type ourselves and produce proper
QML errors if the type is not correct. This happened with Plasma::SortProxyModel.
REVIEW: 106267
filter the sources of the dataengine
The sources were not getting filtered due to an
error in the loop that added all the sources
in any case
REVIEW: 105267
It seems QML sets properties to their default value at startup and thus
calls setSortRole(QString()), which causes SortFilterModel to sort by
default.
CCMAIL: mart@kde.org
some dataengines can have a different set of keys for each item (ie metadata dataengine) the whole mapped roles must be the complete superset
this is not very efficient, but unfortunately is necessary.
(another reason why DataContainers should become models)
* possible to connect multiple sources
* use a normal QMap instead of the quirky qdeclarativepropertymap
* DataModel can be connected to multiple sources as well
* possible to use them with dataengines such as activities and tasks where the first level keys are the "roles" themselves
(all examples in playground have to be adapted)
svn path=/trunk/KDE/kdebase/runtime/; revision=1194216
some have many keys one for each item.
bind a new DataModel into QML that will be associated to a specific DataSource and a key pattern
an exact one like "items" of rss
or a partial regexp one like "KnowledgeBase-[\d]*" like the ocs engine
in this way is not necessary to change how those dataengine works and is possible to use them in QML without headaches
svn path=/trunk/KDE/kdebase/runtime/; revision=1189953
make it available as a QAbstractModel, so will be possible to categorize it
(considering to put it behind a qsortfilterproxymodel to make it easy to do filtering)
svn path=/trunk/KDE/kdebase/runtime/; revision=1189920
