Howto:Coding a simple Nasal Framework: Difference between revisions

no edit summary
No edit summary
No edit summary
Line 1: Line 1:
{{WIP}}
{{WIP}}


{{FGCquote
== Motivation ==
|1= the whole point of developing frameworks and encapsulating functionality there is to allow people to merely "request" a certain component (think ND, PFD, map, EICAS) and "configure" it as needed (think fonts, colors, symbols, events, images etc). And once you look at the integration "code" that loads a working ND, you will see that it is merely a mark-up dialect sligthly different from XML (in fact, it could be XML just as well, but it doesn't yet make sense to provide an XML dialect currently).
I wish we could share more of our development on these things. Having lots of logic for route management and performance data and autopilot stuff re-implemented in every new "realistic" plane kinda sucks. It would be nice if we could build up the built-in system that covers 90% of the cases and any specialiation can be handled by refining the built-in system. Adding a new aircraft should be throw up a couple of displays and live with the built-in default ND and MFD in the first iteration, and then progressively refine it to match the real deal.
In basic terms, you are merely telling the system that you want a certain component, and how you want it to look - and you are doing that using a "configuration file" that could just as well be in a different  format (it merely happens to be using JSON/hash syntax, because that's easy to support using Nasal hashes): [[Canvas ND Framework]]
<ref> {{cite web
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=277481#p277481
  | title  = <nowiki>Re: FMC</nowiki>
  | author = <nowiki>alge</nowiki>
  | date  = Feb 24th, 2016
  | added  = Feb 24th, 2016
  | script_version = 0.25
  }}
</ref>
 
The whole point of developing frameworks and encapsulating functionality there is to allow people to merely "request" a certain component (think ND, PFD, map, EICAS) and "configure" it as needed (think fonts, colors, symbols, events, images etc). And once you look at the integration "code" that loads a working ND, you will see that it is merely a mark-up dialect sligthly different from XML (in fact, it could be XML just as well, but it doesn't yet make sense to provide an XML dialect currently).
In basic terms, you are merely telling the system that you want a certain component, and how you want it to look - and you are doing that using a "configuration file" that could just as well be in a different  format (it merely happens to be using JSON/hash syntax, because that's easy to support using Nasal hashes): [[Canvas ND Framework]]<ref> {{cite web
   | url    = http://forum.flightgear.org/viewtopic.php?p=250211#p250211
   | url    = http://forum.flightgear.org/viewtopic.php?p=250211#p250211
   | title  = <nowiki>Re: Developing a Canvas Cockpit for the CRJ700</nowiki>
   | title  = <nowiki>Re: Developing a Canvas Cockpit for the CRJ700</nowiki>
Line 10: Line 20:
   | date  = Jul 7th, 2015
   | date  = Jul 7th, 2015
   }}
   }}
}}
</ref>


{{FGCquote
{{FGCquote