My plans for Dolphin 4.12

[Jos Poortvliet]

On Aug 2, 2013 5:37 PM, "Frank Reininghaus" <frank78ac at googlemail.com>
wrote:
>
> 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...
http://techbase.kde.org/Schedules/KDE4/4.12_Feature_Plan

:-)

>
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20130909/14057745/attachment.htm>