Joel Granados wrote:
Feel free to rant, scream, suggest, add (constructively) on each point.
Also add stuff that I have missed and give your point of view.
One thing that might be worth considering is cleanup of editing of existing
partitions. I am inclined to approach that user can always refer to the
original
state, not only to state after last editing. It assumes that
all actions one can want to do with existing partition can be set in
one such edit dialog for the partition, and the flow (resize /
format(encrypt) / migrate)
is unambiguous.
Example I can remember of is when user changes his mind and wants to
migrate existing partition instead of formatting it (as he set in
previous editing).
Then the migration option was related to partition in state after
previous edit
i.e. formatted to some fs, and original filesystem label showed this new fs.
I put some patches to just hide the migration option (as well as
original filesystem
label) after selecting to format in previous edit, as after the editing
we didn't have
information about original fs in UI (the device format had been changed
and the information
about original format had been stored only somewhere in actions).
So in this case, the only way to migrate the partition is after Reset.
Maybe I am not remembering this example exactly, but I think there were
some flaws in editing of existing partitons and it deserves some attention.
And one related idea - what about indicating preexisting partition in
the tree somehow?
Radek
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
