On Tue, Jun 23, 2009 at 11:29:48AM -0400, Jeremy Katz wrote: > On Friday, June 19 2009, Joel Granados said: > > 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 ... > > "Additional configuration" seems like a weird verbage to use here and > especially having it where it's placed. The way we add additional disks > now at least seems to me a little more obvious, although it needs some > different wording if we're putting any sort of filtering there Yep, the actual name is strange-ish. Personally, I don't care much for the it. What is important to me is that we might want to put some addtional stuff into the "thing" (whatever you want to call it). > > > 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. > > dmraid is (at least conceptually) different from LVM, though -- I set up > as one "logical" disk in the BIOS much like I would with a hardware RAID > array. Having the individual disks then show up has been a way that > people have gotten into trouble in the past, especially if they're > dual-booting You are right!. This goes with the different types of scanning issue. Is giving the device scanning some granularity something that we would want to do. Something like `devicetree.py:scan_TYPE_devices` I know we handle the different devices in different ways, but we cannot currently scan a specifi device. > > > 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. > > Yeah, I don't entirely like where it is now but it works pretty well. > And custom currently desensitizes a fair bit of the pre-selecting you > can do now > definitelly something to look at. > > 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. > > We've gone back and forth on this one over time... I'm willing to give > the other way a try. > > The other general comment I have is that the bootable radio button is > likely to be obscured / way off to the far right in the treeview. Plus > having a checkbox and a radio button in the same row is at least a > little odd. Yep, this was one of the thing that I didn't like from the first cycle. But I still think that we can configure it in a different, better way. Regards. > > Jeremy > > _______________________________________________ > Anaconda-devel-list mailing list > Anaconda-devel-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/anaconda-devel-list -- 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
