> From: 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. >
What if instead of struggling with externally defined levels, subsystems were encapsulated to the extent that they were able to determine when the data they needed (dependencies) were satisfied. Init() functions would be simple, and update() would check for data items it needed and only perform what it could each cycle until everything was up and running. If each subsystem could keep track of its own requirements then it would be possible to make it not matter which order subsystems were loaded. The subsystem superclass could have a "running" flag in order to reduce the code branches in update to a single check once the subsystem knew it had all it needed. I'm not sure how the nasal scripts fit into all of this. While nasal is extremely useful, I can see where these growing bits of code reading and updating on a global property tree could create quite a mess for a project as complex as FlightGear. Best, Jim -- Jim Wilson Kelco Industries PO Box 160 Milbridge, ME 04658 207-546-7989 ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
