There was some code in KStandardItemListView::itemSizeHintUpdateRequired
already that was supposed to prevent an expensive re-layouting of all
items when a preview is received. However, it didn't quite work as
intended because also the "iconOverlays" role changed.
The new approach is to only re-layout if text of a visible role changes,
because this is the only way how the space needed by an item might
change (see KStandardItemListWidgetInformant::itemSizeHint()).
BUG: 315315
FIXED-IN: 4.10.1
REVIEW: 108984
The method to make sure that the first item is visible turned out to be
less reliable than I thought. This could make the test hang forever.
Moreover, this commit removes some trailing whitespace that had been
added accidentally.
The opacity of the unhovered pixmap must be gradually reduced while
animating otherwise the alpha channel saturates.
REVIEW: 108858
BUG: 299371
FIXED-IN: 4.10.1
The previous approach, which was based on comparing the URLs as
strings, was not only very complex, but also could lead to
inconsistencies in the model, namely, that not all children were
removed from the model when the dir lister reported the parent as
deleted. Later on, this could even lead to a crash.
BUG: 311947
FIXED-IN: 4.11
REVIEW: 108766
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.
necessary, as actions is only called from the main thread.
Also it wasn't checked consistently; if the lock could not be taken, the
plugin was accessed anyway.
UpdateItemStatesThread, because m_itemStates is only accessed by the
when the thread is done, and set before the thread starts.
Also combine the setData function with the constructor.
UpdateItemStatesThread finishing and the finished() signal being
delivered.
In this case, a new thread was not created, because the old thread
still existed. However, pendingItemStatesUpdate was not set, because the
thread was not running. Instead, the old thread was restarted.
This meant that the finished() signal from the first run could be delivered
while the thread was running for a second time, causing the thread to be
deleted while still running and thus a crash.
Solution: set pendingItemStatesUpdate if the thread is non-null,
even if it is not running, knowing that slotThreadFinished has not yet run,
and will call updateItemStates itself.
BUG: 302264
FIXED-IN: 4.10
REVIEW: 107656
Emmanuel has contributed a lot of useful patches to Dolphin. Thank you
very much for that! The Dolphin community is looking forward to further
contributions from you.
CCMAIL: emmanuelpescosta099@gmail.com
