Re: [Flightgear-devel] Subsystem run-levels
James Turner 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. Erik -- http://www.ehtw.info (Dutch)Future of Enschede Airport Twente http://www.ehofman.com/fgfs FlightGear Flight Simulator --- 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=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Subsystem run-levels
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.HHJamesPS - I have the existing airports dialog box appearing during startup now; I'll send along a screenshot when I get home.
Re: [Flightgear-devel] Subsystem run-levels
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=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Subsystem run-levels
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
