Please see the inlined comments below. On Thu, 2012-07-12 at 18:33 -0400, Máirín Duffy wrote: > 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. Do we really want to gamble with shrinking windows partitions? > > 9) Storage auto-default if Fedora and if only one non-removable disk > detected > ==================================================================== Sorry, I don't understand this part. Please see questions below. > > 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 means they get to the partitioning screen with the only available drive selected, right? > > 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. And this means that if there is only one drive and enough space on it (shrinking the filesystems as needed), we would automatically let users to go through the hub #1 without any note about such "brutal" auto-partitioning done? And if they go to the Storage spoke, they will find the auto-partitioning based layout of their partitions there? Because if yes (and the following comment seems to be confirming my concern), I would, as a user, strongly dislike such things happening automatically. > 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. This applies to both #10 and #11: I think we should just write a guide (I could write such guide as I'm planning to write my own custom spoke) how to write Anaconda spokes and then help other teams with the development of *their* spokes maintained by them (probably as separate packages installed by lorax?). And replacing firstboot with the second run of the Anaconda UI with unfinished spokes would allow us to use such spokes in both installation and setting up the installed system during the first boot. > > 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 -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
