[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

UI status braindump, part II



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]