On Fri, 2015-11-06 at 04:35 -0500, David Cantrell wrote: > On Thu, Nov 05, 2015 at 11:33:57AM -0600, Michael Catanzaro wrote: > > On Thu, 2015-11-05 at 16:59 +0100, Martin Kolman wrote: > > > The idea is that we should not show configuration screens the > > > users > > > has > > > already visited during the installation in post-installation > > > tools, > > > such as Initial Setup and Gnome Initial Setup. > > > > > > An example of such a screen is the timezone spoke - if the user > > > already > > > visited the timezone spoke during the installation it is unlikely > > > to > > > be > > > useful showing it again in IS or GIS. So there should be a way > > > for > > > Anaconda to tell the post-installation tools what screens have > > > been > > > visited by a user during the installation, so that the tools can > > > hide > > > or skip the given screen. > > > > > > While Anaconda already produces a kickstart file after successful > > > installation, the resulting commands in the file don't really map > > > to > > > individual screens and there is no information about what > > > commands > > > have > > > been generated automatically, based on user action or which were > > > part > > > of an initial kickstart file used for the installation. Also > > > parsing > > > a > > > kickstart file in a robust way really requires Pykickstart, which > > > might > > > not be straightforward to use (at least without wrappers) from > > > post > > > -install utilities not written in Python, such as Gnome Initial > > > Setup. > > > > > > Therefore a separate simple configuration file forwarding the > > > needed > > > information about visited screens to post-installation tools is > > > needed. > > > > > > > > > Manual installation description file proposal > > > > > > * use the "INI file like" config file format > > > - can be easily parsed from Python using the configparser module > > > - should be also easy to parse from C and other programming > > > languages > > > due to widespread use of INI files > > > * stored in /etc/anaconda/manual_installation.ini > > > - other name/path suggestions welcome! :) > > > * header sections corresponding to spokes > > > * sections for now only contain a visited=1 key/value pair > > > * could be easily extended in the future to include more > > > information > > > about what user did in the spoke if needed > > > * example config file snippet: > > > > > > [DatetimeSpoke] > > > visited=1 > > > > > > * it seems sensible to write sections only for spokes that the > > > user > > > visited, not all spokes > > > * all sub-classes of the Spoke class should be recorder if they > > > are > > > visited, including addons > > > * Initial Setup will also need to record spoke visits as there > > > might > > > be > > > another setup tool chained behind it > > > (and GIS indeed runs after IS on RHEL7) > > > * should we also report hubs the user has visited ? at least for > > > now > > > > > > the number of hubs and their order are fixed > > > > > > Looking forward to your feedback! :) > > > > Hi, > > > > I note that your proposal is basically the opposite of the proposal > > from the Workstation WG. You're hoping to reduce the number of > > panels > > shown by g-i-s, whereas we hope to reduce the panels shown by > > Anaconda. > > Our original proposal is given at: > > https://www.redhat.com/archives/anac > > onda-devel-list/2015-June/msg00002.html > > > > On top of that original proposal, we are now additionally planning > > to > > run language selection and keyboard layout selection as soon as the > > live media starts, so those will be done before Anaconda is ever > > started. This is because it's much too difficult for users to > > figure > > out how to change these currently, unless they already know where > > to > > look in System Settings. There's been some debate about whether > > time > > has to be set prior to installation as well, but that would be > > handled > > by g-i-s either way. This is currently targeted for F24, but nobody > > is > > currently working on it, so it might slip. > > > > But your proposal would work too. Both proposals eliminate the > > duplication between Anaconda and g-i-s, and that is the most > > important > > goal here. Do keep in mind the move of language/keyboard selection; > > with your proposal, we'd need to separately hide those in Anaconda. > > > > (Our secondary goal is to reduce complexity in Anaconda, since we > > fear > > having so many spokes is quite confusing to users who don't > > understand > > computers.) > > The two proposals should be viewed separately. The Workstation WG > installation experience can and should be customized for the > Workstation > product, but anaconda still should have a way to ensure that > duplicate > screens are avoided in instances where both codepaths are run. That's also the way I see it - as a complementary mechanism meant to assure that screens shown to the user in Anaconda are not needlessly shown in tools running *after* Anaconda. So if a given screen is skipped in Anaconda, it can't be visited and therefore also can't be marked as visited. Also theoretically if any tools showing configuration screens before Anaconda starts (as in the example above) could record these screens as visited in the config file, Anaconda could then parse the file on startup and hide screens marked as visited. > > For the installer, we have multiple products to support and we need > to > provide the backend mechanisms to allow for different user > experiences. > _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
