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