Aircraft dialogs: Difference between revisions

m
Line 99: Line 99:
   |date  =  Sep 22nd, 2014  
   |date  =  Sep 22nd, 2014  
   |added  =  Sep 22nd, 2014  
   |added  =  Sep 22nd, 2014  
  |script_version = 0.36
  }}</ref>
Using pure SVG files, those would also be easy to support via Phi/mongoose without much work.
For that to succeed, it would make sense to extend svg.nas according to the previous comments in the [[FG1000]] discussion.
But apart from that, there's not much missing to pull that off - you'd end up with pure SVG/XML files that would have script sections, which would basically invoke fgcommands to get/set properties.
Using this approach is really the only logical way forward to prepare aircraft for the future, without having to focus on any single front-end like PUI, Qt5, Canvas or whatever else people may tinker with. In particular, this means the following:
*  use native SVG files
*  use fgcommands only
*  register custom Nasal code as fgcommands
That way, any front-end can trigger the events (callbacks) necessary to get/set values as needed and run fgcommands (RPC).
Note that this advice is not specific to the shuttle - and it is not specific to the Canvas system, it will apply just as well to the Phi/Qt5 or FGQCanvas efforts.
Using SVG/XML is the logical thing to do here, because it can be trivially made to work by all front-ends.
Again, if in doubt, I'd suggest to discuss the details with the people involved in the corresponding efforts.
Such SVG files, if used by fgfs internally (via Canvas/Nasal) would only need to use a wrapper to run the same fgcommands and set/get properties as needed (or simply use the httpd based RPC interface implemented by Torsten).<ref>{{cite web
  |url    =  https://forum.flightgear.org/viewtopic.php?p=326719#p326719
  |title  =  <nowiki> Re: Space Shuttle </nowiki>
  |author =  <nowiki> Hooray </nowiki>
  |date  =  Jan 22nd, 2018
  |added  =  Jan 22nd, 2018
   |script_version = 0.36  
   |script_version = 0.36  
   }}</ref>
   }}</ref>