20,741
edits
FlightGear run levels: Difference between revisions
Jump to navigation
Jump to search
m
→Properties and Listeners to the Rescue
m (→Objective) |
|||
| Line 28: | Line 28: | ||
It is worth noting that all startup arguments implemented via properties (--prop:) can be also trivially supported at runtime using listeners or conventional polling, i.e. supporting runtime changes of these properties is comparatively simple and a well-understood task. | It is worth noting that all startup arguments implemented via properties (--prop:) can be also trivially supported at runtime using listeners or conventional polling, i.e. supporting runtime changes of these properties is comparatively simple and a well-understood task. | ||
So looking at the code in fg_init.cxx, the major problem is indeed all the static, hard coded, initialization code which assumes a statically defined initialization order. | So looking at the code in [https://gitorious.org/fg/flightgear/blobs/next/src/Main/fg_init.cxx fg_init.cxx], the major problem is indeed all the static, hard coded, initialization code which assumes a statically defined initialization order. | ||
In other words, our problem is that we have routines which are sequentially called and which call each other. These hard coded init assumptions are exactly what makes runtime re-initialization so difficult and non-deterministic currently (see [[FlightGear Sessions]]. Once we start using properties and listeners to implement '''all''' existing startup arguments, we would ''automatically'' have a fully runtime-configurable system, because callbacks would never be invoked directly at the C++ level, but instead be indirectly invoked by setting properties. | In other words, our problem is that we have routines which are sequentially called and which call each other. Routines that were never designed to be called individually, in a different order. | ||
These hard coded init assumptions are exactly what makes runtime re-initialization so difficult and non-deterministic currently (see [[FlightGear Sessions]] for more info). Once we start using properties and listeners to implement '''all''' existing startup arguments, we would ''automatically'' have a fully runtime-configurable system, because callbacks would never be invoked directly at the C++ level, but instead be indirectly invoked by setting properties. | |||
For example, at the moment we have code in [https://gitorious.org/fg/flightgear/blobs/next/src/Main/options.cxx#line1282 $FG_SRC/Main/options.cxx] which maps the startup parameters to callbacks, which in turn call custom parsers to further process these arguments. What is really needed is a single SGPropertyChangeListener interface class which wraps the concept of a startup/runtime argument, so that all the argument-related code is wrapped inside a single helper class, instead of being spread over many different places in legacy procedural code. | For example, at the moment we have code in [https://gitorious.org/fg/flightgear/blobs/next/src/Main/options.cxx#line1282 $FG_SRC/Main/options.cxx] which maps the startup parameters to callbacks, which in turn call custom parsers to further process these arguments. What is really needed is a single SGPropertyChangeListener interface class which wraps the concept of a startup/runtime argument, so that all the argument-related code is wrapped inside a single helper class, instead of being spread over many different places in legacy procedural code. | ||