Howto talk:Coding a simple Nasal Framework

Todo: Considerations for creating Canvas Widgets

• benefits of creating widgets
• supporting multiple instances
• creating multiple windows of a widget
• creating a window/dialog with multiple widgets (tabs?)
• all Canvas-based instruments/MFDs should support GUI-based viewing, without requiring a cockpit/aircraft-even if it's just for testing/development purposes (profiling)
• every widget must support rendering to a customizable context/canvas, so that recursion is fully supported, i.e. dialogs showing instruments with GUI elements

--Hooray (talk) 14:25, 29 June 2014 (UTC)

I feel that the whole subject of creating a Nasal framework could become an exercise in futility, and should even be discouraged in favour of writing code within the core framework. Nasal simply does not have the suitable debugging tools which could make it a big winner. A large piece of code could easily become unmaintainable in case the original developer left. Case in point: local weather.

Adrian (talk)

I guess it's a matter of having to make concessions - in an ideal world, you'd be correct obviously. But given the state of affairs, manpower is not where core development is - but where fgdata contributions happen. The degree of Canvas-based developments and related novelties has meanwhile exceeded any related core developments (except for Canvas itself), including stuff like the hard-coded Map dialog, wxradar, agradar, groundradar, kln89 etc - and that was foreseeable even within a few months after the most basic drawing primitives were added and supported.

But what's been happening is a lot of unprecedented "glass" development in various areas, that was basically completely chaotic, disorganized - without any collaboration and coordination taking place. The few cases where this was not the case, we spent a ton of time doing behind-the-scenes networking. But otherwise, we're seeing a number of efforts, with very desirable features, being developed by people who have no clue/interest about collaborating properly, in order not to write redundant -and usually even incompatible/conflicting- code.

However, I am not sure if you've even played with Canvas recently, or if you're aware of the underlying C++ code, and the deprecated code that is made obsolete by Canvas.

But it is obvious that without any further involvement/direction from our side, all this fgdata development is going to continue obviously, without any significant degree of collaboration/coordination going on.

So coming up with frameworks in scripting space is the only sane, and scaleable, way to deal with this - absent some major change in the FlightGear development philosophy.

Also, what you say is not quite spot-on when it comes to "the core framework" though: What we'll certainly need to explore increasingly is extending the Canvas system itself through extended/added elements and primitives - and that's been happening already, Tom has added a huge number of novelties recently - but we cannot be expected to port all existing code that's being written by dozens of aircraft developers and other Canvas adopters.

Thus, localizing and encapsulating functionality in terms of having dedicated frameworks is the right thing to do - because it allows us to define boundaries, while phasing out/re-implementing more native hooks over time, i.e. more optimized code.

But as long as people come up with their own code doing all sorts of things in a heavily redundant fashion, they cannot benefit from such optimizations automatically, because all THEIR existing code will need to be manually ported - which is exactly the whole point of having a framework-centric development model.

If you've been following my Canvas related postings on the forum, you may have seen that I started exploring re-implementing certain parts of MapStructure in C++ space, which is kinda promising - and all code/aircraft/dialogs using the MapStructure framework (such as Gijs' ND) will automatically benefit from those changes if they're merged, because the key functionality is well-encapsulated there.

Which also kinda challenges your whole point about maintenance issues, because frameworks are typically just 500-1000 lines, while separating front-end and back-en code.

Like Thorsten suggested himself, LW is far from being a good example here - despite your point being totally valid (I kept saying that for years ...), but the main challenge there is not "framework-centric" development, but the whole development methodology adopted there - Thorsten recently mentioned that he thinks it could be re-architected within 4-6 weeks by a team of skilled Nasal coders - so we've had the same discussion behind the scenes. But Thorsten also said that the main issue is that he wasn't familiar with certain programming techniques when he started LW, so it very much "evolved" over time, and wasn't refactored in any major way - and Thorsten kept saying that "it works", so there's not much motivation to do something about it, which I kinda share - I am also more interested in other things, despite having tried cleaning up a few things there a while ago.

Overall, when it comes to major Nasal-based contributions like Advanced Weather (or Bombable) the main challenge is not the implementation language, but rather the underlying expertise, i.e. maths, physics, AI, combat etc - the language part is trivial, and good and maintainable Nasal code can definitely be written, just look at any code committed by AndersG, TheTom or Philosopher - the real challenge is that there's no major barrier to entry when it comes to writing Nasal code, and we're seeing a lot of mediocre code committed, often in terms of performance - but almost certainly in structural terms, i.e. stuff like code organization/reuse and refactoring/generalization. Which kinda comes with the territory, i.e. $FG_ROOT/Nasal not being reviewed/maintained any longer. Nasal is not the reason for this, it's just making the underlying problem more prominent, because we 1) have a lot of fgdata-level coding going on and 2) because we're not reviewing/refactoring stuff properly.

Like I said, the core Canvas system will certainly be extended and refined over time, but there's no sane way for us to deal with existing code, unless people adopt a framework-centric development model that would allow us to encapsulate and localize functionality - once that is the case, refining frameworks, re-implementing them and even phasing them out is straightforward - but as long as people continue with the current "method", we'll end up with a huge mess with Nasal code using different parts of the Canvas system is hugely inconsistent ways, without having anybody willing to do the ugly refactoring/porting work to use more recent Canvas APIs. And frankly, I am not going to volunteer cleaning up all that mess - it's like ThorstenB once said about Advanced Weather: it's simply too much to handle for a single person. Then again, we cannot expect non-coders to adopt and honor important concepts like "code reuse", "constant refactoring" and "encapsulation" without also providing working examples. As could be seen in the last few days, doing that actually scales very well - just look at all of omega95's recent postings in the canvas forum.

Extending the Canvas system is happening, and will continue to happen, but it's a process that will take months, and probably even years - until then, it makes sense to encapsulate common functionality in terms of frameworks, and use that come up with requirements for the Canvas system itself. Otherwise, we'd need a time machine ...

Now, debugging and profiling Nasal code is a different issue - and one that's being worked on, Philosopher has created several very promising patches, some of which we've been running to test/profile and debug code - none of this has been merged yet, but it's on the way.--Hooray (talk) 20:00, 24 July 2014 (UTC)