20,741
edits
Canvas MapStructure: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 30: | Line 30: | ||
For FlightGear versions <nowiki>>=</nowiki> 3.3+, there will also be a [[Canvas Widgets|Canvas Widget]] to easily add MapStructure-based maps to any Canvas dialog and/or to Canvas MFDs that internally use the Canvas GUI framework. Another novelty that we're currently exploring is extending the framework such that GUI-based creation/editing/customization of layers becomes a first-class concept, e.g. to create a weather or tutorial/missions GUI editor: see [[#Porting the map dialog]].|width=70%}} | For FlightGear versions <nowiki>>=</nowiki> 3.3+, there will also be a [[Canvas Widgets|Canvas Widget]] to easily add MapStructure-based maps to any Canvas dialog and/or to Canvas MFDs that internally use the Canvas GUI framework. Another novelty that we're currently exploring is extending the framework such that GUI-based creation/editing/customization of layers becomes a first-class concept, e.g. to create a weather or tutorial/missions GUI editor: see [[#Porting the map dialog]].|width=70%}} | ||
{{ | == History == | ||
|<nowiki>Today, just the MapStructure framework is under 1k lines of code, and is making roughly 9k-15k lines of C++ code obsolete in FlightGear (agradar,groundradar,wxradar,map dialog), unifying the whole shebang in the process, which also ensures that more modern OSG/OpenGL can be used, i.e. better performance in the long-term. | Basically, the ND/MapStructure frameworks came to be out of a certain degree of disagreement with other MFD/glass cockpit efforts using the Canvas system. | ||
That was primarily because many of those lacked support for: | |||
* truly independent instances | |||
* reuse (other aircraft/use-cases, e.g. sharing common logic between aircraft displays and GUI dialogs) | |||
* customiation (think styling) | |||
Especially, we found it hugely frustrating to see awesome avionics like the Avidyne Entegra R9 being developed for aircraft like the extra500, that were impossible to reuse for other aircraft cockpits, but that also contained features/code that would have been useful elsewhere (think mapping/charting displays). | |||
So that more often than not, copy & paste was the only option to "reuse" useful code elsewhere. | |||
Thus, the idea was to grow a library of generic building blocks that live in $FG_ROOT and that are sufficiently generic and customizable to basically enable people to collaborate more properly by providing a strong incentive via compelling functionality that can be easily maintained/updated in the future. The thinking was that all aircraft/GUI dialogs using a single back-end would automatically benefit from significant updates to the back-end that way (think performance, features etc). | |||
Our strategy was to adopt a MVC (model/view/controller) approach, where the model would represent what is to be rendered, the view would map the Canvas system and its primitives (elements) and underlying APIs, whereas the controller would usually be use-case specific (think cockpit vs. GUI dialog).<ref>{{cite web | |||
|url = https://forum.flightgear.org/viewtopic.php?p=317039#p317039 | |||
|title = <nowiki> my "2c" ;-) </nowiki> | |||
|author = <nowiki> Hooray </nowiki> | |||
|date = Aug 21st, 2017 | |||
|added = Aug 21st, 2017 | |||
|script_version = 0.40 | |||
}}</ref> | |||
Today, just the MapStructure framework is under 1k lines of code, and is making roughly 9k-15k lines of C++ code obsolete in FlightGear (agradar,groundradar,wxradar,map dialog), unifying the whole shebang in the process, which also ensures that more modern OSG/OpenGL can be used, i.e. better performance in the long-term. | |||
This all has taken place in under 24 months actually (MapStructure just being 6 months old now actually) - whereas hard-coded instruments (wxradar, agradar, navdisplay,kln89 etc) are usually 5+ years old, and things like the Map dialog even older - in comparison, these were all "easier" to come up with in the first place, but obviously don't scale as well as a Canvas-based solution. Gijs NavDisplay framework is already better accessible and more feature-rich than the original ND code. | This all has taken place in under 24 months actually (MapStructure just being 6 months old now actually) - whereas hard-coded instruments (wxradar, agradar, navdisplay,kln89 etc) are usually 5+ years old, and things like the Map dialog even older - in comparison, these were all "easier" to come up with in the first place, but obviously don't scale as well as a Canvas-based solution. Gijs NavDisplay framework is already better accessible and more feature-rich than the original ND code. | ||
But this kind of work isn't exactly fun, it comprises lots of refactoring and is more about talking and coordinating things than actually coding stuff - because the implementation may very well just be a fraction the size of all the manifestations that are hopefully replaced over time. | But this kind of work isn't exactly fun, it comprises lots of refactoring and is more about talking and coordinating things than actually coding stuff - because the implementation may very well just be a fraction the size of all the manifestations that are hopefully replaced over time. | ||
We've seen some extremeley skilled contributors making sizable contributions without them ever documenting the internals, so that getting up to scratch with things later on may be next to impossible without spending a huge amount of time, that could be equally spent on re-designing certain features/systems.<br/> | |||
<br/> | <br/> | ||
This is something that we have actively worked to address in the context of Nasal/Canvas and efforts like the ND/MapStructure frameworks, i.e. those are now extensively documented, not just including "roadmaps" and "milestones", but also internal design stuff, including even step-by-step tutorials and coding examples - admittedly, this has taken up quite a bit of spare time, that could have just as well been spent "coding" - but given the wiki stats, we seem to be on the right track here, i.e. most of these articles have seen between 2k-8k views within just ~10-12 weeks, which is kinda impressive (some of our most popular articles "only" have seen 40k views in years!), but this also ensures at the same time that even if some of us were to disappear for a few months, people would still be able to pick up where we (TheTom, Philosopher, Gijs, myself) left off, no matter if this means "maintaining" our existing code - or modernizing/replacing it completely. | This is something that we have actively worked to address in the context of Nasal/Canvas and efforts like the ND/MapStructure frameworks, i.e. those are now extensively documented, not just including "roadmaps" and "milestones", but also internal design stuff, including even step-by-step tutorials and coding examples - admittedly, this has taken up quite a bit of spare time, that could have just as well been spent "coding" - but given the wiki stats, we seem to be on the right track here, i.e. most of these articles have seen between 2k-8k views within just ~10-12 weeks, which is kinda impressive (some of our most popular articles "only" have seen 40k views in years!), but this also ensures at the same time that even if some of us were to disappear for a few months, people would still be able to pick up where we (TheTom, Philosopher, Gijs, myself) left off, no matter if this means "maintaining" our existing code - or modernizing/replacing it completely. | ||
In professional software development circles, writing documentation is a necessary evil, as is writing unit tests - in FlightGear, people prefer to spend their time doing "fun" stuff instead for understandable reasons. Then again, some of the main building blocks and key technologies in FlightGear were developed by people who obviously understood that having sufficient docs is at least as important for a feature to survive than the actual code, just look at architectural pillars contributed by people like David Megginson (property tree) or Andy Ross (Nasal) - those are typically the same guys who were responsible for much of the original documentation targeted at core developers, no matter if it's through extensive use of doxygen comments or through dedicated design articles. | |||
Some of our most active contributors spent little to no time ensuring that future developers will be able to continue their work - and that's a problem that will only really become obvious once someone is too busy with other aspects of their life to contribute (or even just back to answer questions). | |||
== What is it ? == | |||
MapStructure is a scripting-space Nasal framework (designed and maintained by Philosopher) for managing layers of symbols in Nasal/Canvas-based mapping displays, which can be used in both aircraft MFDs/instruments and GUI dialogs, like the airport selection or [[Map]] dialogs. MapStructure is all about separating the visualization of the map from the visualized data itself, and the way it is shown to, and controlled by, the user. MapStructure is designed as a Model/View/Controller (MVC) framework. | MapStructure is a scripting-space Nasal framework (designed and maintained by Philosopher) for managing layers of symbols in Nasal/Canvas-based mapping displays, which can be used in both aircraft MFDs/instruments and GUI dialogs, like the airport selection or [[Map]] dialogs. MapStructure is all about separating the visualization of the map from the visualized data itself, and the way it is shown to, and controlled by, the user. MapStructure is designed as a Model/View/Controller (MVC) framework. | ||