[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: Partitionint UI stuff...
- From: Hans de Goede <hdegoede redhat com>
- To: Joel Granados <jgranado redhat com>, Anaconda Devel <anaconda-devel-list redhat com>
- Subject: Re: Partitionint UI stuff...
- Date: Tue, 16 Jun 2009 20:43:28 +0200
All in all I like your ideas, but if we stuck with the current UI,
then I'm against showing only the BAR or only the tree, both
have different functions IMHO, one is a pie chart view of things,
where the other one is a table view. The pie chart view gives
a much better idea of how much space each "partition" uses, where
as the table view is much better in showing other information
(like how the partition will be used / formatted, etc).
On 06/16/2009 07:37 PM, Joel Granados wrote:
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.
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).
2. As stated before, my vote is for putting all the partitioning code
together. (since most of the bugs come after partitioning anyways.
Package installation, bootloader, grub installation). This will also
solve the updates problem with isci and zfcp.
3. Gladeafy everything that is gladeafiable.
4. Try to separate the logic from the drawing whenever possible. I had
already started this some time back. It make the code more
understandable and less prone to mistakes.
5. Lets not repeat information. In the customization screen we have a
tree view and a bar view. I vote for keeping both and giving the user a
choice of how he wants to see the disks. With this we would need to
create bars for raid and lvm, but I don't see this being very difficult
as the information is already there.
6. On the bar view, implement a way of getting more information out of
the bar. Maybe a mouse over could expose the format , the type, if its
formatable or not....
7. Change the way we separate the actions from the information. ATM we
have the actions between the bar view and the tree view. Thats OK, but
IMO it could be much better to have an action bar in the left of the
screen with a list of actions (more on this on another point). And have
one way of looking at the disks at the right of the screen. The right
part of the screen will be bigger of course. And will have all the space
to put the disks and partitions and crap. (remember, the user can
choose tree view or bar view) so imagine one big view.
8. The left view, AKA, action view, should be separated by storage
types. So there will be actions for LVM, for partitions for raid VG for
raid LV. We can even have a misc group to put stuff like Shrink current
system. One would be able to expose or hide each group. So when the
user enters all the groups will be hidden. Only the group name will be
visible and the actions will be hidden. When the user hits the group
name, the group actions show. We can have the partition group visible
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.
10. Be helpful. There are situations where we could be a little
more helpful with the user (when the user make a mistake). Say for
example he pushes the RAID button and has not configured any raid
devices. Instead of just telling the user he is wrong and returning to
the main screen, we could offer some partitions that he might use to
create the raid device. In general, if the current work flow is not
possible, try suggesting alternatives that are related.
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.
12: I think the tree view should be organized as follows:
Device - Size - mountpoint - type - format. The idea behind this is to
order them by diversity. The ones that are more diverse are placed
closer to the name of the device. So you can relate size and device in
a better way. The format being the less divers of the group
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.
14. Same goes for Raid devices. We could offer to create a raid device
on top of free space partitions and partitions that have the raid
15. There needs to be a relation between what is chosen in the view (bar
view or tree view) and the actions. In such a way that when you choose
a partition in the view and select "create VG", the VG screen will
appear with all possible drives that could be used to create a VG with
the ones that the user selected(in the view) selected(in the VG screen).
16. We can go a little further than 15 and provide a feature that lets
the user select various devices in the view (bar view or tree view) and
have the same effect when an action is selected. Furthermore if the
user selects an action that only needs one device, then we will select
the last selected device. And if no devices are selected and the user
selects an action, then we should pop up the actions screen with a list
of all devices that are modifiable where each is unselected.
17. Put all the nice RAID explanation in a help dialog. Mouse over or
Note: I like the LVM dialog setup :)
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.
19. Don't use an intermediate step to create raid devices. Put all that
functionality in the action section of the main screen.
These 19 points contain the brain dump of what I have seen from my tests
with rawhide since yesterday. I have more ideas. Mainly concerning the
first screen (before customization), the list of devices (discussed in a
previous mail), the filtering mechanism, and a way to control the
scanning of devices. But I don't have them clear yet.
I do, however, have some sketches I did on a note book that I have
scanned and uploaded to my fedorapeople page for your viewing. Most of
the written stuff I have included in this mail. I posted them because
they contain the UI sketches that I did for the screens (Sorry, I'm not
much of an artist)
I also understand that this might not be enough information (me not
being a great artist and all), so I promise to include glade files on my
next mail :) Hopefully those glade files will contain all the input I
receive from this mail.
Feel free to rant, scream, suggest, add (constructively) on each point.
Also add stuff that I have missed and give your point of view.
[Date Prev][Date Next] [Thread Prev][Thread Next]