Yeah, I kinda agree with that, and without meaning to discourage anybody - but it is extremely difficult to write "proper" Nasal/Canvas code (in terms of structuring things according to performance/modularization and reuse requirements) - usually, the few people able to do so have a significant background, either in fgfs Nasal/core development or in software development/engineering in general, i.e. holding multiple degrees (and often enough, in both).
The few exceptions to this rule are usually people with professional backgrounds in related fields (maths, physics, aeronautics or engineering in general) who can quickly pick up the corresponding concepts by working through a few tutorials, examples and code snippets and then just take it from there.
The most recent example for well-structured avionics based on Nasal/Canvas is actually Richard's MFD framework and Stuart's FG1000.
Most other code floating around here is hardly reusable/modular at all, and often enough not structured with performance considerations in mind. That way, we ended up with awesome-looking avionics/cockpits that end up causing a significant performance hit for many users, and that have come to use a structure/design that cannot be easily refactored to benefit from certain optimizations.
The challenge here is that by their very nature, Nasal and Canvas are primarily being used by people who may not have had much previous coding exposure/experience (especially people using primarily artwork created by editors like Inkscape), so that people end up "learning as they go" (which is obviously fine, but causing certain issues over time for other contributors/end-users wanting better, more reusable, and faster code or frame rates).
Thus, speaking in general, depending on the kind of avionics you are having in mind, it may be best to reach out to people who have previously already succeeded creating such avionics, and meeting the corresponding performance requirements.
For instance, if you are interested in PFD/EICAS-like avionics, it would seem like a really good idea to reach out to jsb, who is currently aggregating GPL'ed Nasal/Canvas code to incrementally grow a procedural 2D drawing library (for the time being, this is largely based on code written by rleibner originally):
http://wiki.flightgear.org/Canvas_draw_libraryBottom line, even if someone is able to create a proper set of avionics using Inkscape and Nasal/Canvas, there is a certain structure required to avoid redundant code, and to use efficient coding patterns - e.g. to reduce the amount of property I/O and unnecessary Canvas updates/redrawing.
More often than not, this structure is likely to look similar regardless of the aircraft/cockpit that is being modeled - i.e. a coding pattern that helps the shuttle perform faster by being more selective about updates and data I/O is likely to also work for complex airliners, and vice versa.
In other words, if you don't mind reinventing the wheel and solving problems that have already been solved by others, you are obviously free to ignore such advice (that also applies if you have a corresponding coding background), but if you'd like to benefit from certain lessons learnt over time, it would definitely be a good idea to stop coding for a while, and simply do a bit of research to see what we've got already in terms of similar avionics/aircraft, and how these perform for most people - so that you can at least look at the various approaches and concepts being used by different folks.
Personally, I would definitely suggest to look at Richard's MFD framework, and at Stuart's FG1000.
For moving-map purposes, I would suggest to look at Philosopher's MFD framework.
And for anything involving PFD/EICAS-like avionics, I would suggest to look at jsb/rleibner's groundwork respectively.
It is very unfortunate that the Canvas system is not exposing the sc::Element class itself to scripting space, so that this could be used by people to implement new elements by sub-classing existing ones - but for the time being, the cleanest approach to deal with these challenges is indeed coming up with a layered set of scripting space frameworks that encapsulate higher level concepts.
Anybody creating Nasal/Canvas- avionics from scratch not looking at the aforementioned efforts is very likely to do tons of redundant work, with the outcome almost certainly being less flexible and more of a resource hog than what we currently have. As a matter of fact, even the current "state of the art" will not easily support certain multi-instance use-cases, but at least Richard's MFD framework is prepared to do so (via Emesary).
Originally, D-LEON summed up the issue quite well when he presented the awesome Extra500 avionics suite on the forum, saying:
extra500 - Avidyne Entegra 9 IFD - approachD-Leon wrote:NOTE: This sounds like a reusable framework but the encapsulation isn't as far and its optimised for the internal need.
There are some calls going over parents where no interface is "rechable" or defined.
There is a more detailed summary of the issues surrounding most Nasal/Canvas avionics we have come to see over the years:
http://wiki.flightgear.org/Canvas_Devel ... FlightGear