[Kde-hardware-devel] Review Request 111802: Do not clean the cache in UDisks2 backend
Commit Hook
null at kde.org
Thu Aug 1 19:46:41 UTC 2013
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/111802/
-----------------------------------------------------------
(Updated Aug. 1, 2013, 7:46 p.m.)
Status
------
This change has been marked as submitted.
Review request for Solid, Dan Vrátil and Lukáš Tinkl.
Description
-------
Short: Do we need to clean the cache at all? I have been running my system without it and everything seems to work. Code-wise it looks like everything gets updated properly so there is no reason to refresh the cache. Finally mind that allDevices is public API, it can be called (and it is called) many times, so the cache becomes useless for those cases.
Long vers
By deleting DeviceBackend we are invalidating all UDisks2::Devices that are in libsolid frontend, since their m_backend will be 0. Nothing will crash just those Devices will be dummy generating things like: http://wstaw.org/m/2013/07/30/plasma-desktopnX2345.png
A testcase would be:
//We keep a copy of the Device retruned by UdisksManager::createDevice, this is done internally by libsolid frontend
QList<Solid::Device> all = Solid::Device::allDevices();
//We clean the cache
Solid::Device::allDevices();
QList<Solid::Device> devices = Solid::Device::listFromQuery("IS StorageDrive", "");
qDebug() << devices.isEmpty()
devices.isEmpty will be empty since libsolid won't be able to identify any of the devices as "StorageDrive" since they will be dummy.
Fixes: https://bugs.kde.org/show_bug.cgi?id=314544
https://bugs.kde.org/show_bug.cgi?id=317485
Diffs
-----
solid/solid/backends/udisks2/udisksmanager.cpp e76dfd1
Diff: http://git.reviewboard.kde.org/r/111802/diff/
Testing
-------
Executed Dolphin/KWrite/Amarok/KDevelop all of them:
-Shown the correct list of devices
-Reacted correctly on device added/removed
-Reacted correctly on deviceChanges
Thanks,
Àlex Fiestas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-hardware-devel/attachments/20130801/8f5ae2ee/attachment.html>
More information about the Kde-hardware-devel
mailing list