On Tue, 28 Apr 2020, josef Reidinger wrote:

On Tue, 28 Apr 2020 17:47:48 +0200 (CEST) Steffen Winterfeldt <snwint@suse.de> wrote:

seeing your pictures, it maybe even make sense to use checkbox frame which can fit ever nicer there. For example how it looks like see https://documentation.suse.com/sles/12-SP4/html/SLES-all/images/yast2_bootlo... ( part with password protection - do not ask me why our style has hidden border )

and mayb also for that keep existing password...change it to reset password checkbox frame and if not checked, it auto disable that password text fields.

Good point. I've rearranged it to: ┌Formatting Options─────────────────┐ │ │ │ ┌[x] Format device──────────────┐ │ │ │ Filesystem: BTRFS │ │ │ │ [Change...] │ │ │ └───────────────────────────────┘ │ │ │ │ ┌[x] Encrypt device─────────────┐ │ │ │ [x] Keep existing encryption │ │ │ │ │ │ │ │ Password │ │ │ │ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ │ │ │ │ Retype password │ │ │ │ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ │ │ │ └───────────────────────────────┘ │ └───────────────────────────────────┘ ┌Mounting Options───────────────────┐ │ │ │ ┌[x] Mount device───────────────┐ │ │ │ Mount point │ │ │ │ /home▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒↓ │ │ │ │ │ │ │ │ [Fstab options...] │ │ │ │ [Crypttab options...] │ │ │ │ [Subvolume options...] │ │ │ └───────────────────────────────┘ │ └───────────────────────────────────┘ Notes: - I've removed the partition id selection from the dialog. IMHO it fits better into the partition role dialog. - There's no file system selection drop-down anymore - that's hidden behind the [Change...] that takes you to the old filesystem option dialog that gets an added filesystem selection drop-down. The rationale is that we advertise a default filesystem and you usually don't change that. - MAYBE: make swap not available here - instead the user would select it in the role dialog (as it is now already) - and then see it here as preselected fs (and not be able to change swap to some other fs). The reason is that swap and 'normal' filesystems are treated differently already (try alternating between swap and xfs, for example and watch the mounting option dialog). And it's inconsistent to have a swap partition id and a btrfs filesystem anyway. But that might be seen as too restrictive and limiting users' choice... Steffen -- Give orange me give eat orange me eat orange give me eat orange give me you. (chimp Nim, using sign language) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

On Thu, 30 Apr 2020, Stefan Hundhammer wrote:

While you are at it, please add an extra check box for the fstab entry (https://bugzilla.suse.com/show_bug.cgi?id=1169811):

...

┌Mounting Options───────────────────┐ │ │ │ ┌[x] Mount device───────────────┐ │ │ │ Mount point │ │ │ │ /home▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒↓ │ │ │ │ [x] Add to /etc/fstab │ │

Even after reading this bug report I can't see a difference between this fstab checkbox and the 'mount device' checkbox. As long as the default is 'on' that user will run into the same issue again. We could, however, set it to 'noauto' for removable devices (and non-vital filesystems). Anyway, here's an updated proposal including some of the sub-menus: ┌Formatting─────────────────────────┐ ┌Mounting───────────────────────────┐ │ │ │ │ │ ┌[x] Format device──────────────┐ │ │ ┌[x] Mount device───────────────┐ │ │ │ Filesystem: BTRFS │ │ │ │ Mount point │ │ │ │ [Format options...] │ │ │ │ /home▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒↓ │ │ │ └───────────────────────────────┘ │ │ │ │ │ │ │ │ │ [Mount options...] │ │ │ ┌[x] Encrypt device─────────────┐ │ │ │ [Subvolume options...] │ │ │ │ [x] Keep existing encryption │ │ │ └───────────────────────────────┘ │ │ │ │ │ └───────────────────────────────────┘ │ │ [Encryption options...] │ │ │ │ │ │ │ │ Password │ │ │ │ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ │ │ │ │ Retype password │ │ │ │ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ │ │ │ └───────────────────────────────┘ │ └───────────────────────────────────┘ ┌Format options─────────────────────┐ ┌Mount options──────────────────────┐ │ │ │ │ │ Filesystem │ │ [x] Mount at System Start-up │ │ XFS▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒↓ │ │ [ ] Mountable by User │ │ │ │ [ ] Mount Read-Only │ │ ┌XFS options────────────────────┐ │ │ [ ] Enable Quota Support │ │ │ Block Size in Bytes │ │ │ │ │ │ auto▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒↓ │ │ │ Mount filesystem by │ │ │ Inode Size in Bytes │ │ │ UUID▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒↓ │ │ │ auto▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒↓ │ │ │ │ │ │ Percentage of Inode Space │ │ │ Volume label │ │ │ auto▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ │ │ │ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ │ │ │ │ │ │ │ │ │ [x] Inodes Aligned │ │ │ Additional Option Values │ │ └───────────────────────────────┘ │ │ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ │ │ │ │ │ │ [OK] [Cancel] [Help] │ │ [OK] [Cancel] [Help] │ └───────────────────────────────────┘ └───────────────────────────────────┘ Steffen -- Give orange me give eat orange me eat orange give me eat orange give me you. (chimp Nim, using sign language) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

On 5/12/20 7:21 PM, josef Reidinger wrote:

On Tue, 12 May 2020 17:57:17 +0200

Well, if you throwing around crazy ideas, then for me in qt ideal way to do partitioning is visual one.

For "domestic" systems (let's say two disks with one LVM), you are likely right and some visual approach is the best. But, apart from the obvious problem with ncurses, I'm not so sure how well the visual approach scales beyond the most simple scenarios. For SLE customers it's relatively common to have systems with 10+ disks, multipath, RAID and LVM on top. On one hand, those users often use the ncurses interface, on the other, a visual approach would be harder to manage in such scenarios than something based in tables or similar widgets.

So for crazy idea ideally new widget that is like UML diagram or current device graph visualization. Ideally you should be able to drag and drop various components around do arrange it as you want. This way you have in one place two important things - 1. you still see how your partitioning looks like 2. you can quickly rearrange it without long set of delete/create as now. And details like partition sizes and so on will be in object details.

Along that line, something relatively similar to the current devicegraph (but simpler) could be useful. Using the example data from my previous mail I have prepared this stripped-down version of the devicegraph: https://paste.opensuse.org/view/19211592 Of course, the final version should display more information at first sight (like the size of each device, the mount path of the file systems, etc.). But the main idea I wanted to reflect was having all the disks at a top level and all the "leaf nodes" at the bottom one. That bottom line would include both the file systems and the free spaces in vg0 and in sdc (although I didn't add the free spaces to this first version of the image).

Of course question is what to do with ncurses, where it is not possible.

Yep, we need either a good idea that works in both UIs (qt and ncurses) or a couple of good ideas, one for each UI.

another crazy idea for a more guided approach is approach that use autodesk inventor for mechanical designs. Where basically you define relations and it models how result looks like visually. So if you are fine with result you use it and if not you add another constrain ( like size here, angle there or hard join of parts ). To be honest this approach was very productive and easy to use when I was on high school as you again always see result and if it is not what you want, you always just define what is important for you. So as example run you open partitioner and see current partitioning ( or current proposal ) and want to change it. So you e.g. add LVM and define that you want root partition on it and not /home partition on it and it shows you how it will look like after this constrain...and if you still do not like it, you add another, like encryption on home mount point, or set size of root partition to something different and proposal has to respect new value you set.

An interesting idea to consider for the proposal or as special wizard, likely not so much as a general approach for the partitioner. Thanks for the input! -- 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

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. 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. ;-) 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) 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: ... 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. This entry view is primarily meant for intermediate users; let's give them a chance to grow into the more technical aspects. But it's also useful for power users because it's an overview; one that you get without switching through all the detail views in our existing tree. Don't get tempted to cram everything into this. Maybe we can still get some common RAID types into this; but if anybody dumps all the dozens of Btrfs subvolumes in there, he will be shot on the spot. We will have to find a solution to refer users to other more detailed views if a system has any really complex technologies. Multipath, iSCSI, FCoE and whatnot come to mind. Think of this as something similar to our proposals (the old ones, not the new ones that are flooded with all kinds of stuff that doesn't belong there): An overview, a starting point to dig deeper into a more detailed level. This is not meant to switch every little detail immediately; it is the main navigation and orientation tool.

displayed because it's the PV of vg0, so you likely don't want to do anything with it, unless you destroy vg0 first. And so on.

In that list, if you select sda1 you could then decide to mount it or reformat it. And of course, you could also decide to delete or resize it, which will result in a new free space appearing in the list.

If you select the free space in vg0, you will have the option to create a new LV.

If you select sdc, you will be able to format it or to create a partition table on it. Maybe even the option to use it as PV for an existing or new volume group.

Do you get the idea? The main point is to get a curated list of devices that you likely want to modify in your next action and to offer the applicable/reasonable options for each of them.

Crazy idea 1. Extension ========================

When you select a device, maybe we could display the actions that are planned for that device, in addition to the possible options to use it or modify it.

This sounds good. GParted does something similar, but not very well. I think we can come up with something better.

Imagine vg0/root already existed in the system but you have decided to reformat it and mount it as root. The screen you see when clicking on it could be something like:

Previous status: formatted as ext4

Chosen action(s): - Format it as Btrfs - Mount it at "/" (see subvolumes)

Possible actions: [Format / mount] [Delete] [Resize]

Yes! And this time let's please not add every possible action on this level right away; let's make liberal use of menu buttons with "More..." or "Expert...". Let's restrict the normal actions to the most common ones. Less is definitely more here.

Just "thinking aloud" but... what do you think? Any useful point in the whole mail?

Yes, a whole lot actually.

Alternatives? Just release your imagination!

Maybe some kind of meeting for further brainstorming?

+1 ...for now: brain / writing overflow, sending before the web app dies on me... Kind regards -- Stefan Hundhammer <shundhammer@suse.de> YaST Developer SUSE Linux GmbH GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

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