One of the biggest changes introduced with the rewrite of the Anaconda installer was that the new UI (both graphical and textual) uses a hub&spoke model
instead of the wizard model that had been used before. The following diagram shows how hub&spoke works regarding the possible transitions between screens (hubs and spokes).
The screens 2, 3, 5, 8, 10 and others are examples of so called
normal spokes. Those are the screens reachable from hubs. The screens 1 and 14 are examples of a so called
standalone spoke which is a type of screen that should be used only in case it has to be visited before (after) the following (previous) standalone spoke or hub.
The examples of such screens are the language and network configuration screens in the Anaconda installer that are implemented as standalone spokes because actions available on them have to and should, respectively, take place before all the other actions controlled from the user interface.
The reason for the Hub&Spoke model being used in the Anaconda installer's UI is that it has many advantages:
users are not forced to go through the screens in some strictly defined order,
users are not forced to visit every screen no matter if they understand what the options configured in it mean or not,
it is good for the transactional mode where all desired values can be set while nothing is actually happening to the underlying machine until a special button is clicked,
it provides way to show an overview of the configured values,
it has a great support for extensibility, because additional spokes can be put on hubs without need to reorder anything and resolve some complex ordering dependencies and
it can be used for both graphical and textual mode of the installer.
As can be seen in
Figure 1, “Hub&spoke model diagram” central points of the Hub&Spoke model are hubs, so let's focus on hubs in the Anaconda installer for a while. Currently there are two of them:
the Summary hub
that shows a summary of configured options and
the Progress hub
that shows the progress of the installation process and also shows a summary of options that can be configured during the actual installation being done in the background thread.
Every spoke has a few predefined properties that are reflected on the hub. There are: the
ready property stating whether the spoke can be visited or not, the
completed property marking the spoke as completed (all required values are set) or not, the
mandatory property telling whether the spoke has to be completed before allowing user continue to the next hub or standalone spoke and the
status property providing a short summary of the values set in the spoke.
To make the layout of the UI clearer, spokes reachable from these two hubs are grouped together to so called
categories .
A good example of a category used in the Anaconda installer is the
Localization category that groups together spokes for keyboard and timezone settings. So to sum it up there are hubs on the hubs there are categories and in the categories there are spokes. Every spoke contains UI controls that show and allow to modify values from one or more subtrees of the in-memory representation of the kickstart file. As we will see in
Section 6, “Writing an Anaconda addon” the same applies to addons.
