It may be a combination of this change and others. There have been a number of changes to this code since the rc was released.
If you still see QTBUG-13628 I'd suggest getting the qt 4.7 branch from gitorious. If you have problems after that let me know and I'll reopen it. Martin. ________________________________________ From: ext Bartosh Wroblevksy [bart...@live.com] Sent: Saturday, 18 September 2010 3:57 PM To: Jones Martin (Nokia-MS-Qt/Brisbane); qt-qml@trolltech.com Cc: Stephen Kelly Subject: RE: [Qt-qml] emit data on a QAbstracListModel does not update the QML ListView. Hi Guys, I applied the patch to Qt 4.7.0 RC1 here on my computer and it does fix http://bugreports.qt.nokia.com/browse/QTBUG-13664 but it does not seem to fix the other bug that was closed namely http://bugreports.qt.nokia.com/browse/QTBUG-13628. I'll check again to make sure. Thanks, Bartosh > From: martin.jo...@nokia.com > To: qt-qml@trolltech.com > Date: Thu, 16 Sep 2010 11:21:20 +1000 > CC: steve...@gmail.com > Subject: Re: [Qt-qml] emit data on a QAbstracListModel does not update the > QML ListView. > > On Wed, 15 Sep 2010 04:32:37 am ext Stephen Kelly wrote: > > 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 > > This turned out to be another manifestation of the dataChanged() bug also: > > http://bugreports.qt.nokia.com/browse/QTBUG-13664 > > Martin. > > > > > > 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/dyn > > amictreemodel.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#beginMoveRow > > s > > > > 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 > > -- > Martin > _______________________________________________ > Qt-qml mailing list > Qt-qml@trolltech.com > http://lists.trolltech.com/mailman/listinfo/qt-qml _______________________________________________ Qt-qml mailing list Qt-qml@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-qml
