As promised, here's part II of the UI status braindump, starting from where we left off with #6.... 6) Show passwords checkbox for password fields ============================================== Sort of like this screenshot from network manager: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/images/netconfig/network-connections-802.1x.png See the 'show password' checkbox? This would be useful to have on password fields before hub #1 in case authentication to an access point fails - it will allow you to make sure the password isn't wrong because you have the wrong keyboard layout set. Ryan verified that we already have a 'show key' box on the wep key dialog in the mockups now. When we're closer to a complete / integrated set (right now each of us is working on our own copy of the mockups and haven't merged them yet) he'll do a run-through to make sure all of the fields that need this feature are noted in the mockups. 7) Fedora Software Selection ============================ For Fedora, we talked about: - Left column, your option of desktop spins as well as a minimal "no desktop" option equivalent to @core - Right column, functional spins package groups (e.g., electronic lab, security spin, design suite, etc.), normal package groups without language support groups. - adding extra repos - still needs to be worked out, we forgot to talk about this. 8) Partition Shrinking ====================== Eg http://blog.linuxgrrl.com/2012/04/18/rough-thoughts-on-reclaiming-space-from-partitions-during-installation/ This is waiting on me producing a mockup. I talked to dlehman in IRC about this last week. I had a conversation with Garrett Lesage (another open source designer) showing him our mockups so far and he gave the feedback that we should just have one slider per device. The slider might have various 'sticky points' where more drastic actions happen the more you shrink. E.g., say you need 4 gb to do the install. Say you have a pre-existing windows installation on the device with three partitions: - partition A: windows_c with 2 GB free on filesystem - empty space: 2 GB between parts A & B - partition B: windows_d with 0MB free on filesystem - partition C: windows_e with 2 GB free on filesystem You'll have 2 points on the slider maybe: - slide to point 1 and you'll meet the 4gb requirement. You'll resize partition A to free the 2 GB, which is adjacent to the 2 GB empty space between partitions A & B. - slide to point 2 and you'll free up an additional 2 gb by resizing partition C down 2 GB. lvm or btr could be used to make it part of the same logical volume as the chunk of space on the other side of partition b. So there's a preference for resizing partitions that have bigger potential chunks of space to free (so we use partition A first rather than partition C, because even though they are the same size, partition A has a bigger potential being adjacent to a large free space than partition C does.) If you want more space for the filesystem though, moving the slider further does the more drastic action of using a logical volume to chain the two physically disparate chunks together into one for your fedora install. 9) Storage auto-default if Fedora and if only one non-removable disk detected ==================================================================== This is an idea Ryan had when he first reviewed the Anaconda mockups and got started on the project. Right now, no matter what, you can't click past the hub #1 - you have to fill out information in the storage hub. However, a big chunk of Fedora users are setting up single-user Fedora installations on laptops that have a single hard drive. So, if we auto-detect that there is only one non-removable hard drive on a system, we could allow these users to click past the storage screen by automatically selecting the single laptop drive for install. This doesn't mean we wipe that single disk. Instead, we autopart any pre-existing free space on the disk. If that isn't enough space, we automatically shrinkany filesystems as needed. If that isn't enough, we dump 'em in hub #1 with the 'attention' ! icon on the storage part and the user can sort it. :) 9) Icons for specialized disks =============================== All the advanced / network storage disks have the same network storage icon. It might be good to be able to distinguish between raid devices, sans, dasd/zfcp, etc. So we could find and as necessary develop new icons and hook them into the different types of storage when they're displayed. 10) Subscription stuff ====================== This is something that has to be sorted out with the subscriptions team, as well as the folks working on the F18 Initial Experience feature. :( One point that Ryan made was that the GNOME first experience mockups are very user-centric while firstboot is very system-centric and not particular to a specific user much. 11) Bug-reporting / Debug opt-in ================================ Jiri Moskovcak brought this up in a recent email thread with me and Chris - the main ide ahere is that it would be nice to let the user set various debugging options at install time. So they could opt in to ABRT and installing debuginfo packages, for example. I need to talk to Jiri more and get more information about this because I'm still a bit confused about the details. Some things that came up when Chris, Ryan, Mackenzie, and I talked about it today: - opt-in should be someone off hub #1 because it affects whether or not abrt gets installed and particular debuginfo packages get installed - what if it was in firstboot, and abrt / debuginfo was installed in a post-script? or queued up in packagekit? - could they be queued up in the offline updates system? - is there any mechanism to autoclean debuginfo packages when they are stale and useless? - smolt has a new name... this might change the smolt mockups we have - for oem usages of firstboot, there is a reconfig option in the old firstboot, it should carry on to the new one. 12) Random point ================ - How are we handling pre-existing LUKS passwords in the new ui? I gotta go home so no time to do the to-do list summary, maybe tomorrow. :) ~m _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
