Rework dispatch
Summary
The dispatch.py code in anaconda is unnecessarily obscured and tied with the UI interface classes. Its implementation doesn't allow us to easily track if a certain step is going to be taken or skipped. Because it does not act as a proper controller, it is unsuitable for a multithreaded UI implementation.
Owner
Current status
- Targeted release: Fedora 16
- Last updated: 08:37, 16 February 2011 (UTC)
- Percentage of completion: 20%
Some of the GUI/dispatch untangling has been done, the dispatcher API has been cleaned up. This work should progress together with the UI redesign from now on, it has also been suggested we could use the GLib loop to dispatch all events.
Detailed Description
Problems with the current implementation:
- it is difficult to be sure whether a particular step is going to be skipped or not in the end
- we are modeling a queue with much more complex structure, that makes the possible interactions (step forward, step backward) difficult to figure out
- the string binding
- intermixing interactive and direct steps at the same place (is this a problem?)
- dispatch.py is too much entangled with gui.py. This results in a couple of architecture flaws:
- for the first few indirect steps are executed when the gtk.main() function is not yet running
- it is actually the gui.py that decides when the steps are changing, not the dispatch!
A solution suggested by msivak is to have every step at its start check it has all necessary information. If not raise an exception that mentions all steps that need to happen before this step in order to collect all needed information: those will be added before the current step in the queue and the queue is re-executed from the start.
Benefit to Fedora
Better maintainability of the installer code.
Scope
Anaconda.