qubes-issues
qubes-issues copied to clipboard
QubesOS
UX regression with new Devices widget (lacking info about block devices)
Qubes OS release
4.2.1
Brief summary
The "old" Devices widget used to display important info about block devices, such as the identifier (e.g. sda1) and the total size; this is not the case for the new widget, even though it uses much more space on screen, leading to situations as in below screenshot, where the user is the going to have to guess which of a list of identical entries is the correct one.
I've only tested this with my external SSD so far.
Steps to reproduce
(Physically) attach block device with multiple partitions and trigger Devices widget.
Expected behavior
Behaves at least not worse than the previous widget, i.e. displays partition number and size.
Actual behavior
Related post by another user: https://forum.qubes-os.org/t/sneak-peek-of-the-new-qubes-devices-gui/25866/3
A minor change to qui.devices.actionable_widgets.py of qubes-desktop-linux-manager could change the current behaviour and add info on generic notation of block devices (sdX, sdX1, …) within the host VM. I also axed the trailing blank (). This is how I am currently doing it:
--- actionable_widgets.py 2024-04-17 23:56:29.016568722 +0330
+++ /tmp/actionable_widgets.py 2024-04-30 15:58:11.101128803 +0330
@@ -390,7 +390,16 @@
self.device_icon.set_valign(Gtk.Align.CENTER)
self.device_label = Gtk.Label(xalign=0)
- self.device_label.set_markup(device.name)
+
+ devicename = device.name
+ if devicename.endswith(' ()'):
+ devicename = devicename[:-3]
+ if device.device_class == 'block':
+ self.device_label.set_markup("{} - (Host unique ID: {})".format(
+ devicename, device.id_string))
+ else:
+ self.device_label.set_markup(device.name)
+
if self.device.attachments:
self.device_label.get_style_context().add_class("dev_attached")
@UndeadDevel This is an intended regression, I think. Block devices are confusing for novice users and advanced users can use qvm-block. This was talked about in the Qubes summit.
@UndeadDevel This is an intended regression, I think. Block devices are confusing for novice users and advanced users can use qvm-block. This was talked about in the Qubes summit.
Well I certainly hope not; I don't see how adding the info that was there before would make it more confusing. Judging by the attention this is getting in the forum and that the OP here already has two likes (most of my issues don't get likes) it seems I'm not the only one who sees it this way. But thank you @deeplow for providing some context here.
I appreciate the drive to improve UX, which sometimes necessitates simplification, and the new Devices widget does improve in some aspects on the older one (it's just that there's no "well done!" issue type, as that's not an issue), but I think this particular decision (removing that info from the block devices list) was perhaps ill advised.
Edit: another relevant forum thread with confused and frustrated users: https://forum.qubes-os.org/t/qui-devices-how-do-you-attach-only-a-partition/26188
If I plug in a Cruzer-brand USB stick with Qubes R4.2.1, these are the block devices that get exposed:
Cruzer () <- /dev/xvdi3 Cruzer (ANACONDA) <- /dev/xvdi2 Cruzer (QUBES-R4-2-1-X86-64) <- /dev/xvdi Cruzer (QUBES-R4-2-1-X86-64) <- /dev/xvdi1
This is an obvious regression. Qubes own labels are not sufficient to disambiguate the block device which exposes the whole partition table from a specific partition. And what about the labels on something that's not even trusted?
The order is also surprising. The order should be the same as the order on the drive, not an alphabetical order, again set alphabetically potentially by someone untrusted.
Another problem, the block devices in the list are not updated after modifying. For example, attach one disk to VM, modify its partitions, shut down the VM (disk detaches) -- the new partitions are not shown in the menu. This problem was also in 4.1.
@dmoerner said:
This is an obvious regression. Qubes own labels are not sufficient to disambiguate the block device which exposes the whole partition table from a specific partition. And what about the labels on something that's not even trusted?
On the original design proposal, one of the goals was to let the user choose their own label (notice the little :pen: icon):
However that is technically challenging to implement because practically all USB devices do not have a way to authenticate them. But these larger changes will probably not arrive in 4.2. Would this address your concerns @dmoerner?
@deeplow: Not exactly. The underlying concern is that the new change abstracts away too much detail under the assumption that this detail is "confusing" to new users. (I'm not convinced it is, and I think it's obvious that labels are no less confusing, even for Qubes' own media.)
Allowing users to choose their own label is only a meaningful possibility if the GUI already exposes enough information about each device for the user to choose their own label. If the underlying design decision is to not expose this information, then self-labeling is useless. If the design decision is reverted to expose adequate information again, then self-labeling is perhaps useful but only in a few marginal cases.
Then I guess what's needed it:
- a) a better heuristic for the device name
- b) (or) some sort of :information_source: button which shows the labels of all the partitions to help understand what the device is
IMO the best solution is to just go back to the way it was before: display the device or partition name (e.g. sda, sda1 etc.) as well as the total size (if available)...this worked perfectly well to identify what I want to attach to a qube.
Automated announcement from builder-github
The package desktop-linux-manager has been pushed to the r4.3 testing repository for the Debian template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing bookworm-testing (or appropriate equivalent for your template version), then use the standard update command:
sudo apt-get update && sudo apt-get dist-upgrade
Changes included in this update
Automated announcement from builder-github
The component desktop-linux-manager (including package desktop-linux-manager) has been pushed to the r4.3 testing repository for the Fedora template.
To test this update, please install it with the following command:
sudo dnf update --enablerepo=qubes-vm-r4.3-current-testing
Changes included in this update
Automated announcement from builder-github
The package desktop-linux-manager has been pushed to the r4.3 testing repository for the Debian template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing trixie-testing (or appropriate equivalent for your template version), then use the standard update command:
sudo apt-get update && sudo apt-get dist-upgrade
Changes included in this update
Automated announcement from builder-github
The package desktop-linux-manager has been pushed to the r4.2 testing repository for the Debian template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing bookworm-testing (or appropriate equivalent for your template version), then use the standard update command:
sudo apt-get update && sudo apt-get dist-upgrade
Changes included in this update
Automated announcement from builder-github
The component desktop-linux-manager (including package desktop-linux-manager) has been pushed to the r4.3 testing repository for the Fedora template.
To test this update, please install it with the following command:
sudo dnf update --enablerepo=qubes-vm-r4.3-current-testing
Changes included in this update
Automated announcement from builder-github
The package desktop-linux-manager has been pushed to the r4.2 testing repository for the Debian template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing trixie-testing (or appropriate equivalent for your template version), then use the standard update command:
sudo apt-get update && sudo apt-get dist-upgrade
Changes included in this update
Automated announcement from builder-github
The component desktop-linux-manager (including package desktop-linux-manager) has been pushed to the r4.2 testing repository for the Fedora template.
To test this update, please install it with the following command:
sudo dnf update --enablerepo=qubes-vm-r4.2-current-testing
Changes included in this update
Automated announcement from builder-github
The component desktop-linux-manager (including package desktop-linux-manager) has been pushed to the r4.2 testing repository for the Fedora template.
To test this update, please install it with the following command:
sudo dnf update --enablerepo=qubes-vm-r4.2-current-testing
Changes included in this update
Automated announcement from builder-github
The component desktop-linux-manager (including package desktop-linux-manager) has been pushed to the r4.2 testing repository for the Fedora template.
To test this update, please install it with the following command:
sudo dnf update --enablerepo=qubes-vm-r4.2-current-testing
Changes included in this update
Automated announcement from builder-github
The component desktop-linux-manager (including package desktop-linux-manager) has been pushed to the r4.2 testing repository for the Fedora template.
To test this update, please install it with the following command:
sudo dnf update --enablerepo=qubes-vm-r4.2-current-testing
Changes included in this update
Feedback: thank you for these changes! It seems to work without issue; the only nitpick I'd add is that the list entries are neither sorted by size nor device identifier, whereas before they were (by device identifier)...but the important thing is that we see what is what again.
the only nitpick I'd add is that the list entries are neither sorted by size nor device identifier, whereas before they were (by device identifier)
Please open a separate issue for this (if you want).
