Thorsten (was writing this while Richard responded), I agree - but it seems to have more to do with someone's programming background, i.e. not just "coding", but "software engineering" in the sense of coming up with reusable designs and components - Nasal is just the language, and once you know how to structure code using functions, vectors, hashes and higher level data structures, you can definitely use that without having to be an expert in Canvas or avionics - basically you need to look at your own code and determine if a feature is specific to the instrument, to the kind of avionics (MFD) or if it is aircraft specific - at that point, experienced programmers can tell where to put the code, and how to parameterize it so that it can be reused elsewhere.
Next, one would look at repeated patterns (think for animation handling) and encapsulate such details.
I think it is kinda what the extra500 guys have been doing, but they stopped once their work worked for multiple instances of the MFD on their aircraft - as we can seen in Richard's f15 code, it is definitely possible to go one step further, i.e. come up with a framework that is agnostic to the type of avionics, and even aircraft.
Higher level frameworks would then be built on top of such a MFD framework, whereas common functionality would be moved to the MFD framework itself (think animation logic/heuristics).
This kind of design and partioning makes it possible to easily update all child classes of a MFD, so that native Canvas features are automatically used by those, without having to be manually updated.
But for that, you need to understand not only data structures and algorithms, but also how to create components without adding implicit dependencies, i.e. decoupled modules.
Having a background in design patterns and object-oriented programming sure helps, even without people having to use any of this knowledge - but it helps with the thinking required.
Just look at our discussions on using "hashes" (in the C struct sense) in the AW code, and named parameters in function calls - it took a while to bring the point across, but you ultimately agreed that it would help with the coding. Equally, I probably attempted to demonstrate the benefits of "classes" in non-performance critical AW code a dozen times, but you really only began using, and writing, object oriented code when you were exposed to the concept of inheritance via Tim's effects framework, i.e. property-level inheritance.
Ultimately, you are now in a much better position to judge if/when and where/how certain programming styles may be helpful, and you can reuse those ideas even without having to actually do OOP.
Assuming that Richard's exposure to Nasal and Canvas also started with the f15, I think it is pretty clear that it is more about having a fairly solid general background (and experience) in software engineering than familiarity with Nasal/Canvas per se.
Looking back at how we "refactored" the ND code, it's actually not using any fancy design patterns or classes, it's just dealing with a bunch of symbols that are animated using timers and listeners.
A reusable MFD framework would ideally come up with building blocks in the form of:
- MFDDevice
- MFDScreen
- MFDPage
- MFDPageMode
- MFDPageElement
- MFDPageElementUpdateHandler
- MFDPageElementAnimation
And it would be continuously reviewed/augmented based on coming up with child-frameworks for different purposes (CDU, ND, PFD, EFB), so that common functionality would "move up" within the chain of frameworks, whereas device specific stuff would reside in the corresponding child class.
Equally, that is how different aircraft developers would conduct their development, by looking at features they need and determining upfront if those are specific to the instrument or the aircraft - or shared between different kind of MFDs, and then add this at the corresponding layer.
So it's not rocket science, it's just a different way of thinking and more tedious, because you cannot just add new features anywhere, but need to find the appropriate place first.
http://wiki.flightgear.org/Canvas_MFD_FrameworkBut anything dealing with "animating" Canvas elements, would best be encapsulated, so that it can easily use C++ hooks later on:
http://wiki.flightgear.org/Canvas_Animation_FrameworkLooking at the previous posting, this sums up the whole motivation pretty well, i.e. behind having "frameworks":
http://wiki.flightgear.org/Howto:Coding ... _FrameworkWe did once try to come up with a CDU framework:
http://wiki.flightgear.org/A_standard_C ... FlightGearNone of this may seem relevant at first, but it may become obvious once people try to use their avionics in conjunction with multiplayer (think dual-pilot/multi-crew, and/or multi-instance setups (FSWeekend, LinuxTag) with several screens/computers inter-linked - at that point, you need to have frameworks with interfacing boundaries in place, so that only relevant state needs to be propagated, replicated/synchronized.
And this are not the only features that would show restrictions in any non-framework centric approach, e.g. look at the replay system (flight recorder) and/or the tutorials system - as long as there are clear interfacing boundaries in place, it would even be possible to instantiate a MFD, add it to a GUI dialog and use that for training/familiarization purposes (think tutorials).
Which is how this was possible (these are independent instances, i.e. not linked to the actual main aircraft, but can be hooked up to arbitrary properties, including AI aircraft):