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

[Méven Car]

meven marked 2 inline comments as done.
meven added a comment.


  In D24773#551087 <https://phabricator.kde.org/D24773#551087>, @dfaure wrote:
  
  > 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
  
  
  This works from the folder view, but not from the places context menu where I tried it before.
  This is another issue.
  
  > 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.
  >  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.
  
  Maybe we should add another fileld to UDSEntry like UDS_CONTENT_SIZE for this use case then to keep the two use cases clearly separate ?
  
  > There is indeed a fast way to get this particular one
  
  The way that exists necessitates two clicks and a load ; and it is available from only a particular place as mentioned up but that is not the issue here. But the value is in cache in fact for trash:/ we can shortcut the load.
  It is inconvenient and not what users would expect, some may just not find it.
  
  > , 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?
  
  Concerning recursive dir size, it is already a feature wish, that I would argue we should implement in some way sometimes (not default, not everywhere but still we would need something along this line). This is a legitimate feature in 2019 IMO :
  https://bugs.kde.org/show_bug.cgi?id=48434
  https://forum.kde.org/viewtopic.php?f=22&t=87452
  https://bugs.kde.org/show_bug.cgi?id=158090
  So I would argue that we need a way to surface directories content size to users.
  
  But here this does not concern size of dirs in general but only the size of trash:/ that will only be displayed in the information panel.
  So it might acceptable here.
  
  > 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.
  
  I would argue that "Disk space usage" and "Size" might be confusing to users. A folder size is the size of his content idiomatically.
  That is our current usage of Size field for folders that is weird : My Image folder Size is "42 elements".
  That is a paper cut that all new Plasma users have to learn "Size for folders is a content description" : not very intuitive.
  We may want to in fact rename this field for folders to "Content" and keep Size for actual disk usage size (except in details view Size column of course).
  
  The fast path in the information panel is completely viable here.
  
  I would appreciate some feedback from #vdg <https://phabricator.kde.org/tag/vdg/> as to what course of action is recommendable for a user experience perspective. @ngraham ?

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/ba5aaab9/attachment-0001.html>