D24773: kio_trash: Add size, modification, access and create date for trash:/

[David Faure]

dfaure requested changes to this revision.
dfaure added a comment.
This revision now requires changes to proceed.


  I meant in the Dolphin view. RMB / Properties and calculating the size is available for trash:/. See http://www.davidfaure.fr/2019/dolphin_properties_dialog_for_trash.png
  
  I don't like abusing UDS_SIZE for this, because KIO is a virtual filesystem, trying to work like a normal filesystem. When you ::stat() a local directory, you get the size used by the directory entry, NOT the recursive size of all of its contents. There are ways to ask for that, by recursing, but explicitly, not as part of normal directory listing.
  
  There is indeed a fast way to get this particular one, but I'm worried that this creates a precedent where the information panel starts expecting that all kioslaves fill UDS_SIZE with the full recursive size rather than just the size of the directory entry. And users expect to see the full recursive size there. I mean, after this goes in, the user goes to his ~/Music folder, the information panel still says `Size: 4123 items`, they'll report a bug that it should instead show the full disk usage of that folder, right?
  
  I'm also concerned that now UDS_SIZE would have different meanings depending on the URL (sometimes the size of the directory entry, sometimes the full recursive size). This is how bad architecture starts, and unsolvable bugs - or ugly workarounds - tend to appear.
  
  To fix this issue, I would much rather that the information panel uses DirectorySizeJob (possibly on demand, like the Properties dialog); that class could have a fast path for trash: (e.g. making a special() call to the ioslave). Or if you don't want a button in that panel, special-case trash, call DirectorySizeJob only for trash, implement the fast path there - and change the label in the information panel to "Disk space usage" so it's not confused with the usual Size field.

REPOSITORY
  R241 KIO

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

To: meven, #frameworks, ngraham, elvisangelaccio, dfaure
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20191021/6d939a58/attachment.html>