1. It seems that it really can happen that KFileItems that we get from
the dir lister's itemsDeleted signal are not in the model any more,
e.g., if a folder where hidden files are shown is left and a folder
where hidden files are not shown is entered. There is no need to
output warnings then.
2. Remove the emptiness-check for the KFileItemList at the beginning.
Even in the unlikely event that we do get an empty list, we return
just a few lines later in the code.
These crashes were caused by the recent commit
ff3267c6dc. It introduced two problems:
a) A logic error in the code that removes the ItemData pointers from
m_itemData that could cause crashes if multiple item ranges are
removed, and there were un-removed items behind the last one.
b) The implicit assumption that any call of removeItems() will actually
result in items being removed in the model. This is incorrect if
the model is first cleared and then the hidden-files setting is
modified, which happens if "Save view properties for each folder" is
enabled, and a folder where hidden files are shown is left. In that
case, the dir lister emits itemsDeleted for the hidden items after
they have been removed from the model due to the folder change.
I'll add a unit test covering these issues soon.
Many thanks to Romário Rios and Hrvoje Senjan for testing!
BUG: 314046
@info indicates it's rich text and will be added <html> tag by kdelibs,
so just escape the text that will be set to label for KDE/4.10
REVIEW: 108584
BUG: 313992
The performance of this method is improved by:
a) Not removing items one by one, but doing it in a way that minimizes
the number of moves to prevent O(N^2) worst-case complexity.
b) Not sorting the removed items using the potentially extremely slow
KFileItemModel::lessThan. We can get the indexes of the removed items
very easily from the hash m_items, and sorting ints is a lot faster.
c) Preventing repeated rehashing of m_items when removing the deleted
URLs by replacing remove() by erase().
REVIEW: 108540
The benchmark executable must be run manually. It is not run
automatically with the other unit tests to prevent waste of CPU cycles
in the not-so-uncommon situation that only test failures attract
attention.
The Nepomuk ResourceWatcher emits 3 signals - propertyChanged,
propertyAdded and propertyRemoved. We should only listen to either the
propertyChanged signal or the propertyAdded + Removed signals. There is
no point in listening to all 3 signals. That will just result in
unnecessary updates.
Additionally, we do not need to listen to the resourceCreated signal.
That is only emitted when we are watching for a specific types, which we
are not.
REVIEW: 108543
Showing this message in the KMessageWidget above the view, which means
that the view contents are moved down, can be extremely annoying
according to user feedback. Just showing the message in the status bar
is probably enough.
BUG: 313466
REVIEW: 108483
FIXED-IN: 4.10.0
In fact, we could use the sorting functions provided by Qt or the STL.
The reason why we have our own is that we want to support parallel
sorting because sorting many items naturally by name can be expensive.
This might make it easier to reuse the parallel sorting code. Moreover,
some the upperBound/lowerBound functions have been removed because
equivalents are provided by the STL.
