On 5/13/20 3:16 PM, Stefan Hundhammer wrote:
On 2020-05-12 17:57, Ancor Gonzalez Sosa wrote:
Crazy idea 1 ============
Sections like "hard disk", "LVM", "RAID", etc. would not longer be the main way to interact with the Partitioner. Their functionality will remain somewhere, maybe slightly hidden compared to the current status.
Instead, the main entry point will be a list of the devices (or free spaces) that are currently usable. Let's see it with an example.
Imagine a system with sda containing two Windows partitions, sdb containing a small partition and a partially used LVM and sdc completely empty. In the classic Partitioner we would navigate through a tree containing all this:
Hard disks - sda - sda1 - sda2 - sdb - sdb1 - sdb2 - sdc RAID Volume Management - vg0 - root - home Bcache
But for such setup, the list that I propose (I'm still not sure if it would be the first section of the left tree or something completely different) will contain something like this:
sda1 (NTFS) sda2 (NTFS) sdb1 (ext3) vg0/root (btrfs) vg0/home (ext4) Free space at vg0 sdc (empty)
Those are the devices (or spaces) that can be used for something immediately.
sda is not displayed because is fully used, so there is not much you can do with it unless you delete/resize its partitions first.
I like the general approach. Think of how we handle software during installation (openSUSE installation, SLES came upon us down from product management): You first see the broader view, the patterns; but you can go deeper down to the individual package level. One important part here is that even on that detailed level you can switch to the patterns view, so both integrate fairly well.
Yes, that idea of "levels" is something I'm trying to use as some kind of principle, but I have still not found a way to turn the kind of vague concept into a clear idea.
So, I like the general idea to not confront the user with the ultimate detail level immediately where most users are intimidated by all the different views and their options. Even as an intermediate user you can get confused quickly; and the more views and technologies we add (and we keep adding them), the more potential there is to get lost.
The challenge now is where and how to begin so users have a feeling of control over what's happening.
Your approach is to start with the results; while this may work for a number of situations, it will fail for a number of common other ones. In your example here, you don't want to display /dev/sda because there is no free space; it is completely consumed by all the partitions.
Which begs the question: What would I do when I decide to start over? "Just get rid of all that stuff and start from scratch?" Since the whole disk is not visible or accessible here, what is the handle to just delete everything on it? Do we really want users to piece together all the stuff and remove each part individually (including LVM stuff!), asking him for confirmation each time? I don't think so.
Don't get me wrong: This view has merits. I see what I am going to get. But I am not so sure if this is a good starting point.
Users know they have disks in their computers; so we should represent them, visualize them. This is the primary handle for users because it corresponds to something from the real world; something they can touch, something they can buy in a shop. You can't buy a partition or an LVM, but you CAN buy a disk. Don't take away from users the few things from the real world that they can make sense of in this context. ;-)
Yes, that's also a good point. The disks are clearly the first level (or the outer level, or the top one, or the bottom... depends on how you look at it).
Driving the general approach one step further, we will probably still end up with very much the traditional view of a (shallow) tree with disks and partitions. But we can and should make clearer which parts the user can easily manipulate and which ones are "locked" by system stuff:
/dev/sda Hitachi 1 TB Disk (GPT) /dev/sda1 10 MB BIOS Boot Partition (required) /dev/sda2 200 MB EFI System Partition (required) /dev/sda3 500 GB Windows Partition NTFS /dev/sda4 200 GB Linux Partition Btrfs / /dev/sda5 300 GB used by Linux LVM free: 0
/dev/sdb Samsung 250 GB SSD /dev/sdb1 250 GB used by Linux BCache free: 0
(all neatly arranged in columns; the order of things in the descriptions is to be discussed, of course)
The current "Hard disks" view is already quite similar to that. The free spaces are not represented and there is no visual indication of the nesting of the partitions into hard disks. But the displayed information is very similar with the column "type" containing descriptions similar to the ones you suggest (maybe slightly more technical, but that can be improved). See this image (with the data of my original example): https://paste.opensuse.org/76536899
This is a view that I'd like to see as a user. I can make sense of this; I can identify what is what, where all my disk space goes, that no disk space is wasted, and that the stuff I can't make sense of are "required". I am one happy user.
In this view, there are no details about the "other" stuff that is already mentioned: LVM and BCache.
We could display that in a separate section below the disks; I am just not sure how. Maybe like this:
Linux LVM: Encrypted logical volume "system" 200 GB ext4 mounted at /home using VG "lv_system" Volume group "lv_system" 300 GB Encrypted physical volume /dev/sda5 300 GB
Linux Bcache: ...
So in the end, that would be kind of similar to the current system view but with a more clear separation of each hard disk, LVM, etc. instead of everything mixed into a single big table. See current big table: https://paste.opensuse.org/view/60993254
The important part here is to not get lost in abbreviations like LV, VG, PV; they mean nothing to the average user, and it's near impossible to Google for them.
Yes, that's something to improve in the current descriptions. As you can see in the two screenshots linked before we use "PV of vg0" instead of "Used by LVM vg0".
[...]
Cheers. -- Ancor González Sosa YaST Team at SUSE Software Solutions -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org