> This is a result of the destination spoke being odd. Clicking "Back"
> doesn't trigger a call to the apply method, so the settings are not made
> permanent. IOW the back button on the storage spoke is currently a
> Cancel button. This is due to everything in storage being opt-in. I'm
> not sure what other approach we can take here without potentially
> modifying someone's disk during OS install without them having
> explicitly told us to do so.
The fact that this Back button works completely differently from all
others is obnoxious, and I don't know what we could do. The button is
in the .c file and is not exposed through to the Python layer, nor do I
want it to be.
> > > - I don't like the progressive disclosure used in custom where I have
> > > to click on at least 3 things to see the details of a partition
> > > (Unknown->partition->custom...). I'd rather see all the details from
> > > the start.
> This brings us to another question: when the user removes the last lv
> from a vg, should we go ahead and remove the vg? How about its pv(s)? If
> we don't, they get dropped down into the "Unused" group, which is not
> ideal. It starts to feel like whack-a-mole.
>From the TODO at the top of pyanaconda/ui/gui/spokes/custom.py:
# - Removing a device is not very smart. It needs to take into account LUKS, LVM, RAID,
# all that kind of stuff. If this is the last device in one of those containers, all
# the containers should be deleted too.
So yeah, I agree - we should go ahead and remove it.
> > Would having the expander expanded by default make things better? I can
> > see that being too busy-looking for the average user, though. Also, it
> > kind of makes having an expander pointless to begin with.
>
> I would personally like to be able to completely remove a specific
> installation with one click.
Code-wise, it should be pretty easy to make the '-' button work when a
Page in the Accordion has the focus. We could hook into that and do the
delete there. I've got the button insensitive right now unless you've
got something displayed on the RHS. Getting rid of that would be a
first step.
Experience-wise, I think if the confirm dialog were sufficiently
helpful, this would be a nice way for people to get through the UI
quickly.
> > I don't know that we can do this, though. The download isn't really
> > interruptable since it's running in yum code and we don't have any way
> > to kill it.
>
> Either we don't do it automatically, forcing users to go in and choose
> closest mirror, or we do it automatically (for those who do not provide
> a repo) and potentially force some waiting while yum grabs metadata.
> People will be complaining whichever way we go here.
>
> Do we punish the procrastinator ("I want a non-default repo, but I
> didn't want to type it at boot time") or the clueless user ("I don't
> know what the hell this even means -- can't you just set it up for
> me?")?
>
> Rawhide metadata download can take a mighty long time, though.
Given that you can provide your repo via command line, kickstart, or
using the DVD I think we have plenty of ways for people to avoid an
unnecessary download. The way we do it now seems nicest to me for the
largest number of users.
- Chris
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
