Does anyone feel that the devices widget would be easier if the USB block devices were listed as children of their parent USB device?
Maybe this could help both new and experienced users to quickly see the relationships, when it is necessary to use the parent not the child, like in this case.
Displaying that relationship is a bit tricky, because we don’t recommend passing the whole device, just the block devices when it is storage. If displaying parent device, you either have to duplicate information or to list the parent as the first item, before block devices, which means that users would be more likely to click on that entry.
Yes, I agree that sharing the device should be averted when possible, but maybe a different method could solve that: maybe a right click with a “blurb” and a "Do you really…?
Having the partitions look like a disk might also help.
I feel there could be other advantages to keeping the Device as parent, like maybe:
helping to avoid a physical unplugging with an fs still mounted, because I missed that another partition was in use.
Making other multifunction device relationships clear.
For USB, I think the port/socket information is also available. I think this might also be useful, for spotting Bad devices, and for understanding good ones which happen to change type/id/etc.
I’m feeling that the confusion seen in this thread might be worse that the cure provided by the segregated categories we have now.
If this involves a significant amount of work (which I am unable to assess), it may be worth considering how often this scenario is likely to occur. As users, we would prefer Qubes to be updated to the new Qubes 4.5, for example, while still running, just like Fedora. Once we have reached this stage, the program will also be usable for ordinary end users. Even if not every “gimmick” works yet. Then very few people will think of reinstalling Qubes on a Qubes computer. If you switch from another operating system, this problem does not occur at all.
Perhaps it would be better to invest the considerable effort in automating the update to Qubes 4.5 and, in the meantime, just include a note in the user manual.
It’s always more work than one imagines, but most programming/gui toolkits are good at displaying trees of objects, and building a tree out of objects should be quite simple. Maybe the current view is even already a treeview.
Right now, I find it irritating and error prone to have my USB partitions mixed up with my SATA devices, and their parent -with its cryptic name- down with assorted other USB bits and pieces. It feels unintuitive - too close to a particular kernel view.
But that’s probably just me.
I’m curious to know other users’ views, not demanding that anyone change it.
(Anyway, there may be other things to consider, like the possibility and risks of multiple/switchable views, access to other device operations, should actions be (able to be) inhibited in some cases, etc, etc.)
I think it is worth a request on qubes-issues. Make a summary of the advantages, disadvantages and how you imagine it working, even making a drawing, would help understand what you expect. You can also use pure markdown with indented lists.
I think I will have a closer look at the existing code and behaviour first… especially for other types of device and use cases, just to make sure it can all coherent.