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

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 modelling 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.