D28745: Skip caching thumbnails on encrypted filesystems
Méven Car
noreply at phabricator.kde.org
Thu Jun 11 11:00:52 BST 2020
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: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20200611/402b84e9/attachment.htm>
More information about the kfm-devel
mailing list