Hey list. With the objective on continuing the discussion of UI in anaconda storage, I have made some glade files. Its actually one glad file (you can find it here http://jgranado.fedorapeople.org/anaconda/ui/autopart.glade) with three Window designs: autopart: I hope you guys recognize this screen. Its the initial storage screen. CustomPartittioning{1,2} : These are the screens that are used when the user wants to customize his/her storage setup. The difference is the action section on the left. (I personally prefer 2) Some comments: --- The autopart screen --- 1. I would hold all detection of stuff that would otherwise take anaconda too long to detect [1], until the autopart screen. Where the user can choose to go with the "local" detected storage or to use the additional configuration iscsi, zFCP ... 2. If the user has not used the advanced configuration (not activated any "advanced storage") the refresh will not do a devicetree.py:scan. It will look into the information provided by the kernel /sys/block (maybe) and refresh the view. So if the user inserts a USB during this step, it will probably need to show up in the disk list. The user may also want to filter this list, so the filter should be usable in these cases. 3. Since we are (hopefully) running devicetree.py:scan after this screen [2], the disks that appear in the list are going to be the "base devices" [3]. This would mean that the dmraid stuff will not appear there, which it currently does. But I don't think this is a big deal as VG and LV do not appear there either. 4. I don't know where to put the encrypt checkbox. I really don't like it in the outside window as it is not valid for all the configurations. Custom, for example ignores this checkbox. I could (maybe) placed in Additional configuration, but then it would be quite hidden, something that I would want to avoid. 5. iscsi, zfcp and all the additional configuration elements would change the setup for refresh. So if you activate iscsi and then hit refresh, it should try to activate iscsi and search iscsi devices and filter them according to whatever was defined in filtering. 6. I vote fo also ignoring the devices that the user unchecks in this screen. This would mean that the list would have to be considered with the custom button as well. So when the custom screen pops up, it will only show the selecte disks. --- General Custom Partitioning --- 1. Have a split screen setup where we put the actions in the left and the views on the right. 2. Have two possible ways of seeing the devices: a. a tree view and a bar view. 3. The tree view will have a big tree view that will take most of the space of the right section. It will also have a one bar view that will show the currently selected device. 4. The bar view will show all the storage devices as bars. 5. One can flip the views with a tab or some radiobuttons. The important thing being that one can change the way of viewing the devices. 6. The bar views will include raid and lvm devices. 7. The bar views can have some additional info wehn the users puts the mouse over the bars. Invormation like format type and if its going to be formated or not, can appear in the tooltip. 8. The tree view and the bar view would be creatly enhanced if one could right click on a device and the installer would give the possible actions one might want to perform. --- Custome partitioning1 --- 1. Here the actions are separated by type of storage and each tupe has the three main actions: create, edit, delete. 2. Raid will have create raid device, and create raid partition. This might be confusing and might be a good place to put some help info. 3. LVM will also have create VG and create lvm partition, which means physical volume. This also might need some additional help. --- Custome partitionin2 --- 1. Here the actions are separated by action type rather than by device type. So all the create are grouped into the first section. And the modifiers (edit and delete) are grouped into the other group [4]. --- end --- This are some ideas that have been going through my mind. As with my previous post, I would like anybody interested to comment and criticize these points. Regards. [1] : This would require actually defining what these system are. Some initial filters to be placed in udev or the kernel, to explicitly tell them to ignore these types of systems. And would also require the possibility of turning these things on and off whenever we want to. [2] : In this case the Boot flag that is contained in the glade file is useless. But we can put this flag in the next screen. Note that this flag controls where the bootloader goes, not if the partition has the boot flag (which is sometimes useless) [3] : Basically means whatever represents "real life" HW. This definitely need discussion. [4] : I personally like this one the most. Its very similar to the concept we currently have. -- Joel Andres Granados Brno, Czech Republic, Red Hat. _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
