Bartosh Wroblevksy wrote: > > Hello Steve, > Thank you for filing the BR. I have a few questions. > > 1) What's the number of the bug?
http://bugreports.qt.nokia.com/browse/QTBUG-13628 > > 2) I have trouble seeing how in this case, moving rows and changing data > is not equivalent. In fact,unless my morning coffee was not caffeinated. > If I write > > m_elements[1] ="x"; emit dataChanged(index(1,0), index(1,0)); > Should I not expect to see the QML listview change? Yes, you are right. Indeed that is another bug. What you are doing WorksFromMe, but I don't have a plugin for the model like you do, but I create the QDeclarativeMainView in an application and use setContextProperty(myModel). Maybe if loaded through a plugin qml doesn't handle that signal somehow? It's worth another bug report. > 3) beginResetModel() and endResetModel() is clearly not what I want. My > application flickers horribly. In fact I hadinitially tried an emit > modelReset() which also made my application flick horribly. I was hoping > to avoid the flickerwith an emit dataChanged. Until this bug gets fixed, > is there any better alternative? I don't think so, sorry. > 4) You mention >*plus* updating > persistent indexes in between.>Sorry, can you elaborate on this? doMove() { layoutAboutToBeChanged(); // do the move m_items.move(0, 1); QModelIndexList pers = persistentIndexList(); foreach(const QModelIndex &idx, pers) { if ( idx.row() == 0 ) { const QModelIndex newIdx = createIndex(1, 0); changePersistentIndex(idx, newIdx); } if ( idx.row() == 1 ) { const QModelIndex newIdx = createIndex(0, 0); changePersistentIndex(idx, newIdx); } } layoutChanged(); } I hardcoded the 0 and 1 for clarity, but you can imagine that if you're moving an arbitrary range of items an arbitrary distance the implementation gets difficult. Avoid doing it yourself where possible and use beginMoveRows etc instead. If you want to see an implementation implementing a move in a tree using just the layout change stuff see ModelMoveLayoutChangeCommand::emitPreSignal and ModelMoveLayoutChangeCommand::emitPostSignal here: http://websvn.kde.org/trunk/KDE/kdelibs/kdeui/tests/proxymodeltestsuite/dynamictreemodel.cpp?view=markup Compare to ModelMoveCommand::emitPreSignal and ModelMoveCommand::emitPostSignal Updating those is needed for selections, tree expansion proxy models etc to work properly and not crash. > 5) You > wrote >> + beginMoveRows(QModelIndex(), 0, 0, QModelIndex(), 2);> >> m_elements.move(0,1);> + endMoveRows(); > Since the destination child is 1, I would have expected to write >> + beginMoveRows(QModelIndex(), 0, 0, QModelIndex(), 1);> >> m_elements.move(0,1);> + endMoveRows(); > but then again, my coffee may be decaffeinated. It's common for people to think that. I improved the docs with diagrams for 4.7: http://doc.trolltech.com/main-snapshot/qabstractitemmodel.html#beginMoveRows It's consistent with other model api where you identify the 'gap' you want to move the item to. Item at position 0 can't be moved to gap 0 or 1 because it is already in between them. It can be moved to position 2 though. Unfortunately the QList::move API is not the same. It's also easier to implement dropMimeData like this. All the best, Steve. _______________________________________________ Qt-qml mailing list Qt-qml@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-qml
