My plans for Dolphin 4.12

[Frank Reininghaus]

Hi everyone,

in the last days, I thought about a few things that I could work on
for Dolphin 4.12. I also thought it might be a good idea to let other
people know about them, in order to prevent that this overlaps or
conflicts with what others are planning, and to give you the chance to
comment on these ideas, suggest changes, or to shout if anything does
not make sense at all.

When these things are finished, I might add some more things to the
list. Hm, maybe we should set up a wiki page where everyone can list
the things they are working on...



1. KFileItemModelRolesUpdater: Move the counting of items inside a
directory into another thread

There is a bug report about the counting freezing the application on
slow mounts:

https://bugs.kde.org/show_bug.cgi?id=318518

A short freeze is even noticeable with local hard disks if there are
folders with really many files in them.

First I thought that doing that in a separate thread would be too
complex and error-prone, but actually, I believe now that it is not
too hard implementation-wise, and it might even make the code a bit
cleaner. We could do it like this:

(a) Create a new class KDirectoryContentsCounter or something like
that. KFileItemModelRolesUpdater has an instance of this class as a
member and calls a member function of that class when it requests the
count for a path. The result is received asynchronously via a signal.
All KDirWatch-related code is also moved to that class. Maybe that
class should also connect to KFileItemModel’s itemsRemoved() signal to
know when to remove a watched directory.

(b) KDirectoryContentsCounter starts a new thread, creates a ‘Worker’
and moves it to that thread. When a directory contents count is
requested, it sends a signal to the Worker. The result is received in
a slot which forwards the result to KFileItemModelRolesUpdater.


2. KFileItemModel: Lazy-load the ‘values’ member of ItemData

At the moment, we set up the hash ‘values’, which contains all
interesting information about an item, for all items in
createItemDataList(). In very large directories, this requires a lot
of memory and CPU cycles, even though the data of most items will
never be needed.

We could change that by not initializing ‘values’ in
createItemDataList(), but only when it is requested by a call to
KFileItemModel::data(int index). This will require some internal
modifications in KFileItemModel, and also changes in
KStandardItemListWidgetInformant::itemSizeHint(), which currently
requests the full data for every item in the model.


3. KItemListSelectionManager: do not store the selected indexes in a
QSet<int>, but in a more efficient way

Selecting N items (e.g., by pressing Ctrl+A in a directory with N
items) takes O(N) time at the moment. Moreover, toggling the
‘selected’ state of a single item may take O(N) time too.

To see this, open a folder with really many items, press and hold
Shift+down, see how fast everything works, and then press Shift+End
(such that all items are selected) and press and hold Shift+up. This
is much slower because KItemListSelectionManager::selectedItems()
creates a new set with many items every time it's called.

My idea is to do something similar to QItemSelection, and store the
selection in a class KItemSelection or KItemSet, which internally uses
a list of KItemRanges. In the very common case that all selected items
are in one (or a few) ranges, this should greatly reduce the effort required to
update the selection.


Cheers,
Frank