Review Request 111009: KFileItemModelRolesUpdater polishing, part 2: make sure that the visible items have icons even while sorting

[Commit Hook]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/111009/
-----------------------------------------------------------

(Updated June 20, 2013, 5:17 p.m.)


Status
------

This change has been marked as submitted.


Review request for Dolphin.


Description
-------

This patch depends on https://git.reviewboard.kde.org/r/111008/

One basic idea of my recent changes in KFileItemModelRolesUpdater was to ensure that the items are sorted properly before expensive stuff (like preview loading) is being done for the visible items or items which might become visible soon.

However, we should always try to ensure that the items in the visible area have known icons. I used a rather hackish approach to try and ensure this, but it was rather complicated and did not always work.

I propose to change this by *always* calling startUpdating() when items are inserted, removed, moved, or the visible range changes, and let this function at least determine the visible icons before it checks if we are still determining sort roles (and only continues if that is not the case).

The new function updateVisibleIcons() tries to determine the final icons for 200 ms. If that time is over, it does at least a fast icon loading (i.e., KFileItem::iconName() without known mime type) to ensure that no visible icons are "unknown". Actually, this "fast" icon loading will only be fast for folder when David's patch from http://lists.kde.org/?l=kfm-devel&m=137102348931280&w=2 is in master.


Diffs
-----

  dolphin/src/kitemviews/kfileitemmodelrolesupdater.cpp e539b45 
  dolphin/src/kitemviews/kfileitemmodelrolesupdater.h aa47f17 

Diff: http://git.reviewboard.kde.org/r/111009/diff/


Testing
-------

Works for me - no "unknown" icons even when "sorting by type" in large directories.


Thanks,

Frank Reininghaus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20130620/25941b85/attachment.htm>