[Flightgear-devel] Subsystem run-levels

[James Turner]

I'm plotting to add support for startup GUIs in FlightGear itself, spurred on by recent issues with Mac GUI. My approach is to twiddle the order of initialisation so that at a critical point during the idle_state progression, the NewGUI subsystem is up, config options have been parsed, and the nav data has been read, but everything else is still 'off'. With the exclusion of nav-data, this point is reached very quickly, and I believe other work can improve the 10-20 seconds it takes to read the nav data. Happily enough, the current idle_state '4' almost corresponds to this; in my test code, at this point, I jump to a new, special idle_state, with the expectation of sitting there, showing some PUI dialogs driven by XML, filling in the property tree with settings for the current aircraft, airport, and so on, and then eventually resuming the idle_state progression.  The only catch is, subsystems are initialised late, but I need a handful to be up before I can use the GUI dialogs; obviously the GUI subsystem itself, but also Nasal and a few others. (There are some issues with initialising nasal early, it is currently deliberately being done very late, but more on that later...) What would simplify this greatly is if subsystem registration was totally separated out from (re-)initialisation, and if sub-systems had run-level or priority associated with them. All the subsystems could be registered via add_subsystem, and then during fgInitSubsystems, the runlevel would gradually advance to the final value. This also means the dependencies between subsystems can be expressed (higher numbers depend on lower numbers), and might make things like reset more simple (lower the run-level back to some determined value, and the bring it back up again). As an additional enhancement, subsystems could be notified of all run-level changes above their threshold. This would solve the Nasal issue; starting up the interpreter (the first part of  FGNasalSys::init) can be done very early (and quickly), and the subsytem would then wait for a relatively high-valued 'init' call before running scripts (the part that needs all other properties to be defined). In the even longer run, we'd actually want to associate the Nasal scripts with run-levels (/etc/rc.d, anyone?), since the frontend GUI might want a few scripts loaded, while I assume most are only relevant when actually flying. Such a change also makes postinit() unnecessary, I think - since the effect can always be achieved by having init() watch for a higher run-level. What do people think? I can have a patch for SimGear that adds support, and one for fg_init that establishes the existing behaviour, done in an hour or two. Feedback appreciated, James