D25335: [Details mode] Allow to fill the column size of directories with actual size

Méven Car noreply at phabricator.kde.org
Fri Jan 24 20:38:53 GMT 2020


meven added a comment.


  In D25335#572208 <https://phabricator.kde.org/D25335#572208>, @ngraham wrote:
  
  > I noticed one more quirk. When sorting by size and expanding a subfolder, the contents are sometimes (not always) not sorted correctly: F7799185: Screenshot_20191204_100210.png <https://phabricator.kde.org/F7799185>
  
  
  This is sorted correctly : by levels (top levels dirs, then within dirs...) with directories first.
  While I recognize this might be confusing.
  
  > What happens if, say, we allow infinite recursion? Will Dolphin freeze on slow hard drive systems?
  
  Infinite recursion -> risk of freeze / huge I/O cost, this will make other apps feel laggy potentially.
  Dolphin will freeze (my current patch runs in main thread, this is a landing-stopper TODO item).
  
  > What's the worst-case scenario if we allow no user-facing configuration of the performance consequences of this feature.
  
  We will have complaints that size counting is not working / imprecise, or that dolphin makes hard disks run a lot, that preview take a while to appear (because of I/O load)...
  It will all depend on the user setup, a nightmare to debug/get bug reports for, and for our users, most users won't ever be concerned.
  
  My desire would be that we have a default that matches 95% of cases : either recursive count, time-based budget by dir, a cache or a combination.
  And a setting for the remaining edge-cases.
  
  I don't know precisely the strategies used here by others DE and OS, and this would be a great source of inspiration for design.
  Either they have their fs caching this sort of data, or some caching at other levels.
  Gnome's nautilus uses a hashmap based cache https://github.com/GNOME/nautilus/blob/bc931dbe746b52584035b797c96e14eb3c4a3f34/src/nautilus-directory-async.c#L935
  This would be a good solution for dolphin as well to minimize disk access and re-computation.
  
  So my todo here, in order :
  
  - Find some consensus what the feature should look like : the setting, the expectancies (phabricator is not a great tool for this).
  - Then
    - Rebase code
    - Update UI
    - Add a cache to store data
    - Add a fast patch to stop the counting process when is not needed.

REPOSITORY
  R318 Dolphin

REVISION DETAIL
  https://phabricator.kde.org/D25335

To: meven, elvisangelaccio, ngraham
Cc: anthonyfieroni, iasensio, kfm-devel, pberestov, fprice, MrPepe, fbampaloukas, alexde, Codezela, feverfew, meven, spoorun, navarromorales, firef, ngraham, andrebarros, emmanuelp, mikesomov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20200124/dd072978/attachment.htm>


More information about the kfm-devel mailing list