Dear plasma-devs, hardware-devs
looking forward to check the validity of a bug regarding the device notifier
and encrypted devices (containers) I noticed several issues with them in the
current implementation of
the dataengines
The imporant thing to know about them is that they show up in solid as a
StorageVolume such that StorageVolume.usage is 'Encrypted'. When they are
"mounted"
solid asks for a password and if the password is correct, then the partitions
which are stored inside the device pop up and are correctly collected by the
hotplug dataengine.
Then the user can use them normally; the encrypted device (container) is closed
(i.e. cannot be used anymore without providing the password again) by
"unmounting" it.
A few issues arise in this situation:
1) Solid cannot provide us with a signal when an encrypted container is
correctly "mounted" or "opened"
2) The encrypted containers are currently shown by the dataengine since they
match the "open with file manager" predicate, however
this action does really nothing, since a container simply contains
partitions, so we can't really open the file manager on unmounted partitions.
Moreover, there is no real static action we can associate with them.
3) The user is (imHo) misled by strings such as "mount/unmount" and icons such
as "mounted/unmounted/eject"
My proposed solutions:
1) A solution (bad, but that's all we can do) to solve issue #1 is to let the
hotplug engine check if a newly added or removed device is inside an
encrypted container and trigger an update of the status of the container
accordingly. If new devices are added it means that the container has been
opened
if they are removed, it means that the container has been closed.
2) Rather than cheating giving a completely fake action we could implement an
exception for the hotplug engine, letting it populate devices with encrypted
devices
even if they have no action associated with them. This of course need
adjustments to the two (that I know) users of the dataengine (device notifier
and solid runner)
to make sure they don't assume the existence of at least one action and in
order for them to properly handle such situation.
A less pervasive solution would be to let the engine add dynamic action
(open/close the container) if it detects an encrypted device. In this case the
adjustments to the
notifier and to the runner would be less pervasive, but still we need to
treat the special action in a different way than the others, unless, we rely on
soliduiserver::showActionsDialog
itself accepting these two as special actions.
3) Nuno already kindly provided emblems/icons for the open/close status
(locked/unlocked); as for the strings I already asked for an exception for
string freeze regarding
solid::Device::description() which should say "encrypted container" instead
of "removable media". I might as well ask for an exception to
add "Lock the container" and "unlock the container" if felt needed. If
string freeze exceptions for these are not granted I'd rather leave
descriptions empty rather than
providing false information..
Awaiting for your comments and suggestions
Thanks
--J
_______________________________________________
Plasma-devel mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/plasma-devel
