Indeed, this is something that David Megginson (property tree/SGSubsystem*) originally was planning according to the structure of SGSubsystem - ideally, many more subsystems would use this structure, while also becoming optional during initialization.
A while ago, James Turner was contemplating to introduce "run-levels", that was prior to his reset/re-init work:
http://wiki.flightgear.org/FlightGear_Run_Levelshttp://wiki.flightgear.org/FlightGear_R ... te_note-11James Turner wrote: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.
Since then, he began implementing reset/-reinit and the subsystemFactory, which could be considered to be the foundation for "run-levels", i.e. by making subsystems better configurable and optional.
As you can see by the pointers on the wiki (quotes...), all this was originally motivated by the need for having an integrated UI - in fact, originally, the idea was Nasal, and later on Canvas, for that - which caused the creation of the Aircraft Center:
http://wiki.flightgear.org/Aircraft_CenterAs you know, quite a few things have changed since then, i.e. the addition of Qt5, so that Nasal/Canvas are no longer favored for this sort of thing - however, the reset/re-init, and the related subsystemFactory work remain relevant even if Qt5 were to be accepted as a mandatory build time depencency.
Sometime later, we discussed the idea of adopting Torsten's FGPanel approach, by coming up with something like "FGCanvas", i.e. a minimal subset of FlightGear subsystems and Nasal obviously, which was also inspired by James, with the difference of being a custom fgfs startup mode instead of a different/downstripped codebase:
http://wiki.flightgear.org/FGCanvasSubject: FGPanel: standalone panel renderingzakalawe wrote:Torsten wrote:fgpanel is the 2d-panel code from flightgear wrapped into a simple standalone application being able to display 2d instruments on very simple hardware with basic OpenGL support. Find my sources dropped here:
http://www.gitorious.org/flightgear-pmpt/panel
Off-topic, but I am going to be overhauls the 2D panels / displays code in the near future, and was planning to create exactly the same idea - a standalone app that can run a single panel - good to know the idea works! (I'm also planning to internally port the 2D panel code to the new system, but that should be invisible to most people)
James Turner wrote:http://www.mail-archive.com/flightgear- ... 17266.htmlIf we're rendering each display as an OSG sub-camera, extracting that logic and wrapping it in a stand-alone OSG viewer should be simplicity itself - and so long as it's driven by properties, those can be sent over a socket. That's an approach which seems a lot more bearable to me than sending per-frame pixel surfaces over shared memory or sockets / pipes.
http://www.mail-archive.com/flightgear- ... 37441.htmlCreating a 'fgcanvas' client analogous to 'FGPanel' should be doable too, since the canvas simply renders to a single osg-Camera. Unlike fgpanel this will require OSG instead of raw GL of course, but that's the price we pay for unifying the rendering backend.
http://sourceforge.net/p/flightgear/mai ... /31380390/more useful would be to get ARM working so we can run parts of the stack on Pis, Pandaboards and so on. This would be materially useful for various add-on functions, especially the canvas and fgcom. (I spend an increasing amount of my work time on OpenGL on ARM platforms, they have plenty of power to run graphics, depending on which GPU is on the SoC)
As you can see now, there's some kind of "holistic vision" that some people have been having for the better part of the last decade ... much/most of this never made it onto the "update project roadmap", but it's obviously been consistently worked towards over time, and given the degree of activity by those involved, it used to be pretty safe to "bet" on these developments.
these are exactly the same types of changes I was thinking of for fully decoupling all the various parts of FlightGear for use in a CppUnit-based test suite
Something for the future though.
James and others are definitely also interested in this sort of thing, for a collection of relevant pointers, see:
http://wiki.flightgear.org/FlightGear_HeadlessJames Turner wrote:The position init code is a little complex, to allow for starting on a carrier and some other cases, and ideally we would do it from script, but unfortunately there's some technical limitations on doing that. (Not insurmountable, but not quick either). Adding more cases to the position-init code is certainly doable - one suggestion I made some time ago, is when MP is active, to default to starting at a free parking position instead of on a runway. (When no startup position is provided at all).
The remarks on using scripted initialization (rather than hard-coded logic in fg_init.cxx) is obviously in line with efforts to have better regression testing in FlightGear, making more subsystems optional/restartable (reset/re-init), and to make scripting available much earlier:
http://wiki.flightgear.org/Initializing_Nasal_earlyThus, I think that none of this would necessarily be specific to just FGPythonSys (or FGNasalSys), it is definitely in line with long-standing ideas/wishes of some of the key contributors behind the project, e.g. referring to:
http://sourceforge.net/p/flightgear/mai ... /33226290/I am wishing I could easily add tests for the route-path / GPS code, but anything that needs ‘globals’ is hard to test in isolation.
If done properly, you would ultimately end up with a codebase where "fgpanel", "fgviewer" (and possibly fgcanvas) would merely be "startup modes" of the same underlying fgfs binary using a combination of different subsystems - not unlike a Linux system with different "run-levels"
PS: I fixed up the patch on the wiki, but tested it only briefly at KSFO...