On Tue, 2009-06-16 at 19:37 +0200, Joel Granados wrote: > Hey list. > > Been analyzing the UI partitioning stuff and here is an initial mail to > get the discussion rolling. Before anything I'd like to state that IMO > the UI (in general) does not need a rewrite. What I think should be > done is make the UI better using the current state of the code. I also > know that describing this in a mail could lead to confusion, so I > promise some glade code in my next post. I agree that the current UI is not horrible and could benefit significantly from a few well-chosen tweaks and a new screen or two. A rewrite would be nice, though, at some point in the not-too-distant future. > Ok, here goes: > > 1. Help dialogs: Have a mouse over help functionality for storage stuff > in general. There are a lot of concepts that are in the installation > that might need clarification. Nothing better for the user to have a > way to find out some additional info. Could be a mouse over or a right > click on labels (or something). I would like for it to be invisible > unless the user does something (like move the mouse). Some of these could be very useful. For example, the various check-buttons in the partition dialogs could use a one-sentence explanation. > 9. Maybe (just thinking out loud here). Have a feature that enables the > user to access each action (the same ones from the left), from a right > click in the information view (tree view or bar view). In such a way > that when the user right clicks some device in the bar view, the possible > actions he/she can do with that device appear in a list. Sounds good. Some context-awareness does not seem like too much to ask. > 11. I believe that we should not have such big type names. > Specifically: Physical Volume (LVM) and Software RAID. We can call them > something different (like LVM-PV and SW-RAID) and have a mouse over > functionality that actually explains stuff. I am not a fan of the long names. I prefer names like "lvm" for LVs and "raid" for mdraid. > > 13. Currently, to create a VG, we need partitions formated as PV to be > in the tree. We could easily (I use easily without really knowing what > needs to be done :) use free space partitions as well. And > create the PV format and relate it to the new VG behind the scenes. This seems reasonable and not too tough. > 18. Have the possibility of using the LV screen without having to go > through the VG screen. So when the user selects an LV and clicks on > edit, the LV screen (only) pops up. Consider also putting some VG info > on the LV screen so that that screen does not depend on the VG screen > being in the background for context. Yes! I think we should edit one device at a time whenever possible. You can edit a VG: add/remove PVs, rename, change extent size. You can edit an LV: choose which VG it belongs to, rename, format, &c They do not need to be stacked. These nested dialogs are at the top of my list of things that need to go away as a result of this work. I'm eager to see how the things look after a consult with UI people. Dave _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
