I agree
MechAero wrote in Sat May 29, 2021 12:48 am:I am leaning toward a Canvas solution, and the type of aircraft-agnostic framework described in the current thread is just what I need if provides reusable elements for PFDs, MFDs, NDs, etc. However, the platform-independence of Torsten's approach (
http://forum.flightgear.org/viewtopic.php?p=212632#p212632) is attractive, especially since the group I am working with is using Rasberry Pi computers for displays.
In general, I tend to agree with jsb - you have done a great job searching the forum and digging out this thread, but most recently, it's really jsb's work that's shaping the way Canvas-based avionics are done. To some extent, the shuttle also has interesting routines.
Anyway, there are some underlying issues when it comes to how the Canvas and the Nasal engine are integrated.
Thus, it might be a good idea to share your requirements/goals with us, so that we can discuss the various pros & cons of different approaches.
For instances, there's FGQCanvas - however, that's basically a port/re-implementation of the Canvas engine in FlightGear, as such it also comes with different pros & cons: it has a much more modern code base, requires Qt5 - but is not entirely portable, in the sense that some native Canvas features are unsupported, or only partially implemented - and others don't work entirely like the real thing in FlightGear.
Then, there's Phi - and basically it would make sense to use a SVG based approach if people want to use their Canvas instruments in conjunction with Phi.
We already have working support to "stream" Canvas avionics (textures) to another process over http - and there have been talks about using a tiny subset of both JavaScript and Nasal to extend our SVG parser so that we can create self-contained SVGs that can be interpreted by both, a browser with JavaScript support and FlightGear via the Canvas and Nasal.
At the end of the day, it really all comes down to your specs and requirements.
Also, it will matter whether you're able to patch&rebuild fgfs or if you'd rather stay in fgdata space.
Personally, I consider jsb to be the maintainer of the Nasal/Canvas side of things these days - then again, he keeps stating that he's unfortunately busy with real life. So there's that, too.
There are other aircraft/efforts that do have interesting Nasal/Canvas code that you could look at - but again, it's best to share your goals and requirements with us first, possibly in a new topic. And then different people can provide their feedback.
For the sake of completeness, if you have a professional background in avionics/aviation - we have working ARINC 661 integration in the sense that we have a way to interface the open source J661 CDS with FlightGear. That, too, could also be better linked with the Canvas system, and Thomas Geymayer (creator of the Canvas system) was once contemplating doing just that. James Turner (leading core developer) has also developed some of his native avionics with a focus on A661.
For the FlightGear project it would obviously be very interesting to extend it so that we can run/display actual A661 DF and use FlightGear as the CDS.
If that's a possible venue for you, that will inevitably require some C++ modifications - but those additions could pay off greatly, because you could basically run a standard avionics development suite and hook up those avionics to FlightGear directly. That is one of the reasons why I developed the integration originally - i.e. you can even hook up FlightGear to an actual FTD or FMS.
Again, this will certainly require some tinkering, but you would be able to reuse existing avionics toolkits and could create avionics without having to do so in Nasal space or Inkscape.
You mentioned RPi style hardware, at which point I would definitely consider Phi - again, SVG/XML can be extened using custom elements - and our parser is implemented in scripting space, so it would be possible to create dedicated elements for things like "compass rose", then implement that using jsb's routines, but run the whole thing through a Nasal2JavaScript translator/subset, so that the same SVG file could be interpreted by Nasal/Canvas, but also by a standalone browser - after all, all that's needed is a way to animate such elements by using properties and running fgcommands. None of that would involve any patching/C++ work.