[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Glade files for anaconda UI (storage)

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

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

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.


[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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]