bruns added a comment.
The UDisksDeviceBackend class serves two functions:
- shared data cache for UDisksDevice instances
- static factory of instances
The manager has everything it needs to function as a factory. The
UDisksDeviceBackend would become a representation of the
broulik added a comment.
You mean I kill that entire `DeviceBackend` wrapper and have `Device` do all
the things with all the data stored in the `DeviceManager`?
REPOSITORY
R245 Solid
REVISION DETAIL
https://phabricator.kde.org/D19677
To: broulik, #frameworks, bruns
Cc: apol,
bruns added a comment.
In the old code, the backend was created lazily, as the associated DBus
connection was expensive, this is no longer the case. I am wondering if
creating the backend immediately/always would not solve a number of structural
problems here (though this is already *much*
bruns added inline comments.
INLINE COMMENTS
> udisksdevicebackend.cpp:146
> if (m_propertyCache.contains(key)) {
> return;
> }
not necessary
> udisksdevicebackend.h:74
>
> QDBusInterface *m_device;
>
no longer used
REPOSITORY
R245 Solid
REVISION DETAIL
apol added a comment.
+1 do we know what's stopping this to move forward?
At least the commit message needs addressing.
INLINE COMMENTS
> udisksmanager.h:41
>
> +// interface -> [ {property: key}, {property: key}, ... ]
> +using PropertyMap = QMap;
This comment looks wrong. If this
bruns added a comment.
+10 on porting to ObjectManager
Will do a proper review later
REPOSITORY
R245 Solid
REVISION DETAIL
https://phabricator.kde.org/D19677
To: broulik, #frameworks, bruns
Cc: kde-frameworks-devel, michaelh, ngraham, bruns
broulik retitled this revision from "Port UDisks to using DBus ObjectManager"
to "WIP: Port UDisks to using DBus ObjectManager".
REPOSITORY
R245 Solid
REVISION DETAIL
https://phabricator.kde.org/D19677
To: broulik, #frameworks, bruns
Cc: kde-frameworks-devel, michaelh, ngraham, bruns
