20,741
edits
Canvas ND framework: Difference between revisions
Jump to navigation
Jump to search
m
→Development: moved from Talk:MapStructure
m (→Development: moved from Talk:MapStructure) |
|||
| Line 129: | Line 129: | ||
== Development == | == Development == | ||
=== mapping vs. SVG animation === | |||
It would be really nice to have two sides to navdisplay.mfd: a map (your/my area) and svg ui (Gijs' and aircraft devs' responsibility) 0.o. | |||
: am all for supporting the two use-cases you mentioned - then again, the old code is fragile enough, so I wouldn't add to it - the main thing the old code was all about was establishing the MVC separation so that draw routines can be reused - and that's basically done, so no need to keep the old cruft around ... | |||
: Regarding the navdisplay stuff itself - well, it's pretty much the original code still, i.e. the design is only just evolving - algorithmically, it's still not very optimized - MapStructure only helps with mapping aspects obviously. | |||
: I was going to suggest the "SVG/element animation" separation too - but I think Gijs etc already need to handle quite a bit of re-thinking, because things are no longer as straightforward. In the long run, it will probably happen over time - especially once other things are generalized, especially for generic PFD/EICAS/CDU/EFB functionality - these would all benefit from a corresponding "symbol animation" abstraction eventually like TheTom mentioned on the forum: PFD: A common framework in the background | |||
: Honestly, it would have been great to have such a framework to implement MapStructure on top of it - but obviously, it's a chicken/egg issue :-) | |||
: Currently, the main danger here is that people are going to start using copy & paste again to adopt things like Gijs' PFD, like mentioned by Zakalawe: if someone provides a 'system' I'll use it but I'm not interested in writing it myself | |||
: So the real question is if people can be convinced to team up and come up with a generic and reusable design, or follow the original PFD/ND approach instead - interestingly, most of TheTom's work in this area (MCDU/EICAS) seems pretty reusable, also outside aircraft, i.e. usable via the GUI. | |||
After having looked at navdisplay.mfd, I think we only need to separate a few things using io.include() to make this happen automatically over time - all the 747/Boeing-specific stuff would be moved into "config" hashes and factored out of navdisplay.mfd - into something like "boeing747.nd" that would leave us with very little code remaining in navdisplay - basically a single class and a few methods with foreach loops. | |||
So we would end up with a layered design like this: | |||
* boeing.nd (config hashes via io.include) | |||
* navdisplay (down-stripped code, aircraft-agnostic) | |||
* MapStructure (needs no changes) | |||
* Symbol/Animation Layer (shared with PFD, ND, CDU, EFB, would be developed/grown over time) | |||
* canvas APIs (as is) | |||
* canvas subsystem (as is) | |||
* OSG / Shiva (as is) | |||
=== Misc === | |||
* use switches hash to procedurally create a GUI dialog with buttons for each toggle_action (TFC,CTR,WXR etc) {{Not done}} | * use switches hash to procedurally create a GUI dialog with buttons for each toggle_action (TFC,CTR,WXR etc) {{Not done}} | ||
* make sure that the frameworks with properly with time-warp, sim-rate speed-up and replay {{Not done}} | * make sure that the frameworks with properly with time-warp, sim-rate speed-up and replay {{Not done}} | ||