map.nas is not really doing very much here - in fact, I am considering of either rewriting it completely, or removing it once PUI got phased out, because it's primary "purpose" for now is that it can re-use those *.draw, *.model and *.layer files to use them in GUI dialogs, like the airport selection dialog, because it handles layer creation etc.
So the main concern back then was to ensure that we don't end up with lots of duplicate code - MFD instruments like the 744 ND still need to call the various ctors directly.
And yes sure, I really don't mind giving access to the repo, all feedback and input is appreciated - I think you even had access previously, but I deleted/re-cloned yesterday, because pushing would take too long otherwise, as I hadn't updated gitorious in months ...
Your points are valid, as I mentioned in the source code comments - but that's a limitation of the original code, I really didn't change anything there (yet) - but I'm completely aware of the FDM signal handler and its issue, as you can tell from the comments:
https://gitorious.org/fg/hoorays-fgdata ... D.nas#L360And yes, the removeAllChildren() stuff is basically still in place, it's just hidden deeper in various abstraction layers - at the moment, we are using .init() calls to update each layer, which will internally talk to the model and trigger a .notifyView() calls - which ends up calling removeAllChildren(). I'm aware of the issue here, but I didn't bother optimizing things there, because the original code did the exact same thing. But I do recall that you had some clever scheme in mind to update things in a more efficient fashion. In the long run, we'll want to use what TheTom and Zakalawe talked about though, i.e. C/C++ level support to optimize this.
If you have a model/controller concept in mind that handles these things, sure go ahead - we really don't have any advanced controller support at the moment, and the Layer/View and model stuff is fairly messy, too - but on the other hand, it's really just 5-10 lines of code per files, so easy to update - without having to touch tons of other places/files.
I would however prefer if I could first of all push my latest changes, so that there's no unnecessary conflict introduced by you working on certain stuff.
re: map.nas being weird, that's an understatement - its whole point was to move Stuart's useful Nasal code out of the airport selection dialog, and build layers procedurally - basically what I'm doing right now with Gijs' code, too - to be honest, I would prefer to yank it completely at some point, but as long as PUI is in use, it does serve a purpose still ... and I'm not overly eager to add tons of Nasal code to each dialog just to show a certain layer. So either we'll wait, or I'll rewrite it with our requirements in mind.
So map.nas is really just the glue code that currently allows us to easily reuse *.draw/*.model files for different purposes - once we've established this as the best practice, it can go away and be replaced with something more appropriate, and something that "deserves" being in the canvas namespace ...
I'll be pushing my latest changes so that you can have a look (ignore map.nas, unless it's impossible) - we really should be focusing on the MVC aspects, to ensure that things are reusable for different aircraft, instruments and GUI dialogs.
PS: Thanks for the comments!
EDIT: Is there possibly a precendece issue I'm unaware of when using a line like this:
me.efis_path ~ me.efis_switches['range']; I'm getting this: Nasal runtime error: non-numeric string in numeric context
Trying parentheses now