Anaconda/Features/Rework dispatch

From FedoraProject

< Anaconda | Features(Difference between revisions)
Jump to: navigation, search
 
(One intermediate revision by one user not shown)
Line 1: Line 1:
= Threaded Anaconda GUI =
+
= Rework dispatch =
  
 
== Summary ==
 
== Summary ==
Line 11: Line 11:
 
* Last updated: 08:37, 16 February 2011 (UTC)
 
* Last updated: 08:37, 16 February 2011 (UTC)
 
* Percentage of completion: 20%
 
* 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 ==
 
== Detailed Description ==

Latest revision as of 12:15, 3 November 2011

Contents

[edit] Rework dispatch

[edit] 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.

[edit] Owner

[edit] 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.

[edit] 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.

[edit] Benefit to Fedora

Better maintainability of the installer code.

[edit] Scope

Anaconda.

[edit] Test Plan

[edit] User Experience

[edit] Dependencies

[edit] Contingency Plan

[edit] Documentation

[edit] Release Notes