> > Tab works as I expect it both on the initial welcome language screen, as > > well as the language spoke off the first hub. All UI elements are > > focusable. > > <Tab> did not move focus for me; or perhaps it did, but the newly-focused > button was not highlighted. I'll file a bug. I can't reproduce it, though, so I don't know what I can possibly do. I tried with both a locally built image and with the TC3 one up for download. > There is a 5-second deadline. Anything longer requires a progress bar > (or at least some changing indicator "I'm still alive"), else it's equivalent > to a "hang". It is much more pleasant to have a progress bar. I'll wait > patiently much longer if I have some reasonable indication of how close > it is to being done, and if I can estimate the completion time. What I'm saying, though, is that we can't provide a reasonable indication of things. We've played the pervasive progress bar game in the past, and it just didn't work. A lot of our progress bars weren't even progress, they just bounced back and forth. This is because for a lot of things we can't make good guesses about how long it's going to take (network troubles), and a lot of things make it extremely difficult (screen scraping mkfs output). > There needs to be a margin, else it looks like something was cut off. > Also, it's really hard to read when the first character of a line > has less than 0.5 'n' of space to the left. Can you take a screenshot? I'm definitely seeing a good amount of margin on both the left and right sides that make it easy to read. I wonder if this is an artifact of screensize. > The box scrolls with the mouse, but there are only 2 drives visible at > any time. An ordinary table of text, with columns of attributes and rows > of drives (including a small icon for the type of drive) would be better. > Such a table could list 12 drives easily before vertical scrolling > would become necessary. Horizontal scrolling would allow more > attributes at once, there could be 6 or 7 columns of attributes > (icon, make, model, size, serial, MSDOS/GPT/Apple) before scrolling. This makes for a wall of text UI which isn't really very pleasing at all. We can make minor changes, of course, but this big grid of overwhelming data is really something we're trying to get away from. I'd love to get mizmo's take on this. > If I can't see it, and am not told it's there, then it isn't there. > Requiring hover is also bad for those who use assisting technologies. We can work on making information more discoverable, but the answer is not to generate a giant table of data. > >> There was no message "No LVM2 structures were found" which is > >> required in order to increase my confidence and help detect errors. > > > > What? > > If disk discovery gets something wrong. then there is a moderate chance > of data loss, and that would be catastrophic. The GUI tells me if LVM2 > was discovered. It also should tell me if LVM2 was _not_ discovered. Should we also tell you that RAID was not discovered? Multipath was not discovered? What else do you want to know wasn't there? We can't read your mind as to what you think should be on a disk and then tell you that we didn't find it correctly. You are doing an installation, please make backups. That's the first advice you get everywhere. - Chris _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
