> On May 11, 2012, 2:36 p.m., Marco Martin wrote: > > I think is in the good direction, what would be cool is to insert rows in > > order of descendednt relevancy, even if a more relevant row arrives after > > the already existing ones
I see the advantage of sorting by relevancy, but I am a bit afraid of going that way because: - It changes the way rows are sorted in the model - It is more complicated to get right - From a user point of view, it means new items will get inserted between existing items. Thus existing items will move, making them much more difficult to target with the mouse - A proxy model can be set up to sort the current model by relevancy. If other uses of the model require a different sorting, it feels suboptimal to sort by relevancy only to have another proxy model sort the items using another criteria - Aurélien ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104917/#review13719 ----------------------------------------------------------- On May 11, 2012, 2:13 p.m., Aurélien Gâteau wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/104917/ > ----------------------------------------------------------- > > (Updated May 11, 2012, 2:13 p.m.) > > > Review request for Plasma and Aaron J. Seigo. > > > Description > ------- > > When RunnerModel receives the matchesChanged() from RunnerManager, it resets > itself and replace its copy of matches with the new one. This cause some > flicker when the model is used with a QML ListView because the view clears > itself each time the model is reset. > > Ideally, RunnerManager should provide more fine-grained updates to > RunnerModel, but for now I found the below patch to give good results. It > basically checks if the new match list is equal to the old one plus some new > items. If this is the case, it uses beginInsertRows() and endInsertRows() > instead of resetting the model. > > Note: the code needs a recent version of kdelibs KDE/4.8 branch because it > requires the != operator for Plasma::QueryMatch, which I added earlier today. > > > Diffs > ----- > > plasma/declarativeimports/krunnermodel/runnermodel.cpp 7c5485b > > Diff: http://git.reviewboard.kde.org/r/104917/diff/ > > > Testing > ------- > > Tested with SAL-QML (currently in kde-workspace, in plasma/sreich/sal-qml). > Gets lots of flickering because items created by the SAL-QML view fades in > when added. Flickering goes away after the patch. > > > Thanks, > > Aurélien Gâteau > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
