D28745: Skip caching thumbnails on encrypted filesystems

[Méven Car]

meven added a comment.


  In D28745#675033 <https://phabricator.kde.org/D28745#675033>, @marcingu wrote:
  
  > Ok, so, what I want to do now is to create static method `findByPath` which is going to return Solid::StorageVolume instance (is there a case in which we can expect something different than StorageVolume?).
  
  
  I don't think so, Storage Volume is any block device.
  This function may fail if the input path is not valid for instance.
  
  > Should it be `StorageVolume Device::findByPath(QString)` or rather `StorageVolume StorageVolume::findByPath(QString)`?
  
  My preference is `StorageVolume Device::findByPath(QString)`, to keep all entry points to Solid in Device and somewhat similar to the `Device::listFrom*` functions.
  
  > For implementation itself I want to create structure with mountpoints and StorageVolumes which will be updated if new Device is added/removed and we learn this via Solid notifications.
  
  Yeah that's what I imagined as well, but this is already taken care of by the base DeviceManager.
  
  > I am thinking it should either be part of `DeviceManagerStorage` or separate class similar to DeviceManagerStorage. Not sure which.
  
  Either way you can simply wrap the base DeviceManager.
  Your method should only be a utility function not adding new Structures, everything is in Solid already.
  
  > I don't know how to get a mountpoint for StorageVolume.
  
  You make me realize you should filter StorageVolume (any block device) that are also StorageAccess (anything that can be mounted) which has the mountpoints in `filePath()`.
  
  https://api.kde.org/frameworks/solid/html/classSolid_1_1StorageVolume.html 
  https://api.kde.org/frameworks/solid/html/classSolid_1_1StorageAccess.html
  
  > What do you think about it?
  
  I like it

REPOSITORY
  R320 KIO Extras

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

To: marcingu, ivan, broulik, #dolphin, ngraham, meven, bruns
Cc: thiago, bruns, meven, ngraham, kde-frameworks-devel, kfm-devel, waitquietly, azyx, nikolaik, pberestov, iasensio, aprcela, fprice, LeGast00n, cblack, fbampaloukas, alexde, Codezela, feverfew, michaelh, spoorun, navarromorales, firef, andrebarros, emmanuelp, rdieter, mikesomov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20200611/402b84e9/attachment-0001.htm>