20,741
edits
Canvas ND framework: Difference between revisions
Jump to navigation
Jump to search
→Post 3.2
mNo edit summary |
|||
| Line 354: | Line 354: | ||
== Development == | == Development == | ||
=== Encapsulating Properties === | |||
{{FGCquote | |||
| think this and similar problems will be coming up for more or less every aircraft as the properties differ between FDM:s and sometimes even between aircraft. | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=213016#p213016 | |||
|title=<nowiki>Re: NavDisplay & MapStructure discussion (previously via PM)</nowiki> | |||
|author=<nowiki>Johan G</nowiki> | |||
|date=<nowiki>Fri Jun 20</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
|aircraft, which will use NavDisplay must have airspeed-indicator, created as built-in instrument, so I prefer to select airspeed indicator as source (which is close to reality). | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=213018#p213018 | |||
|title=<nowiki>Re: NavDisplay & MapStructure discussion (previously via PM)</nowiki> | |||
|author=<nowiki>Soitanen</nowiki> | |||
|date=<nowiki>Fri Jun 20</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
|We could implement a way for individual aircraft to feed the ND with their own properties. However, standardizing the properties would make more sense, also for other use cases (bindings for input devices, dialogs etc.). That is even more important for the PFD, since there are dozens of different autopilot properties being used in FlightGear. | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=213025#p213025 | |||
|title=<nowiki>Re: NavDisplay & MapStructure discussion (previously via PM)</nowiki> | |||
|author=<nowiki>Gijs</nowiki> | |||
|date=<nowiki>Fri Jun 20</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
|This kind of thing is already done in both, MapStructure and the NavDisplay, it just isn't widely used yet - but we did establish the infrastructure for this. You must be aware of it, because you kept maintaining and fixing the NDSourceDriver logic that encapsulates properties for AI traffic. The same method can be found in aircraftpos.controller to hide aircraft specifics in a "delegate" hash that provides an "abstract interface" without the back-end code having to be aware of the underlying properties.<br/> | |||
<br/> | |||
As long as aircraft developers agree to use, and help maintain, a corresponding hash, we can help enforce this as a "best practice" - but this should obviously be part of navdisplay.mfd itself (or even a separately-included file), so that it can be easily reused by PFD code eventually, without being specific to the MapStructure/ND code.<br/> | |||
<br/> | |||
We reall only need to extend the ND.new() constructor to support such "overrides" and pass them on to the underlying callbacks, which is kinda touching the whole MVC approach already used by the MapStructure framework. | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214377#p214377 | |||
|title=<nowiki>Re: NavDisplay & MapStructure discussion (previously via PM)</nowiki> | |||
|author=<nowiki>Hooray</nowiki> | |||
|date=<nowiki>Tue Jul 08</nowiki> | |||
}} | |||
}} | |||
=== Post 3.2 === | === Post 3.2 === | ||
Gijs has already begun to clean up the update() method, and navdisplay.mfd is now back down to under 800 lines of code. Hooray will need to revisit adding support for '''switches''' (i.e. a helper class) and corresponding display modes. | Gijs has already begun to clean up the update() method, and navdisplay.mfd is now back down to under 800 lines of code. Hooray will need to revisit adding support for '''switches''' (i.e. a helper class) and corresponding display modes. | ||