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. For the installer, we have multiple products to support and we need to provide the backend mechanisms to allow for different user experiences. -- David Cantrell <dcantrell@xxxxxxxxxx> Manager, Installer Engineering Team Red Hat, Inc. | Westford, MA | EST5EDT _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
