D24773: kio_trash: Add size, modification, access and create date for trash:/
David Faure
noreply at phabricator.kde.org
Sun Oct 20 16:39:38 BST 2019
dfaure requested changes to this revision.
dfaure added inline comments.
This revision now requires changes to proceed.
INLINE COMMENTS
> kio_trash.cpp:500
> KIO::UDSEntry entry;
> + entry.clear();
> createTopLevelDirEntry(entry);
why?
> trashimpl.cpp:1088
>
> +KIO::UDSEntry TrashImpl::trashUDSEntry()
> +{
This method could be const, right?
> trashimpl.cpp:1104
> + // compute dir size if needed
> + KIO::DirectorySizeJob *job = KIO::directorySize(QUrl::fromLocalFile(info.physicalPath));
> + connect(job, &KIO::DirectorySizeJob::result, this, [&size, job] (){
This looks very slow. We have a cache for the size usage. See `TrashImpl::trashSpaceInfo`.
But anyway, we never return recursive directory size in the UDS_SIZE field, in no ioslave.
If someone wants to know the size of a directory, they can use the properties dialog, which has a calculate button.
> trashimpl.cpp:1111
> + }
> + entry.replace(KIO::UDSEntry::UDS_SIZE, static_cast<long long>(size));
> +
Why `replace`? This is inserting into a fresh new entry, it could use `fastInsert`
(same for the other calls below)
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/20191020/ee797742/attachment.html>
More information about the Kde-frameworks-devel
mailing list