Re: [Flightgear-devel] Subsystem run-levels

[James Turner]

On 18 Apr 2006, at 08:56, Erik Hofman wrote: 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. 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. If you can get this working properly then this would be a great contribution. The startup sequence has always proved to be rather tricky to get right, this might solve some of that. Unfortunately, I found a simpler way to get /some/ of what I need - I realized I can use the existing 'group' functionality to get things limping along. There is a classic 'forward looking comment' in that code (simgear/structure/subsystem_mgr.hxx):  * This top-level subsystem will eventually manage all of the  * subsystems in FlightGear: it broadcasts its life-cycle events  * (init, bind, etc.) to all of the subsystems it manages.  Subsystems  * are grouped to guarantee order of initialization and execution --  * currently, the only two groups are INIT and GENERAL, but others  * will appear in the future. Surprise, surprise, the only groups are /still/ INIT and GENERAL. My run-level proposal is very similar to the existing groups, so I need to think a bit more about how to extend the notion of groups to enable the things I mentioned in my original email (particularly the ability to run Nasal scripts when different run-levels are started). Run levels have a well defined ordering, whereas groups don't necessarily have one - except that in the current code, they /do/ have an ordering, from the enum.  I will experiment and see what makes sense without changing too much. If people know of edge-cases that the current code doesn't handle (I know of a few places where people use timers to wait a couple of seconds after sim-startup before doing 'something'), it'd be good to mention those here - I suspect many of them could be handled more directly by a run-level system. H&H James PS - I have the existing airports dialog box appearing during startup now; I'll send along a screenshot when I get home.