fly/fgdata
1
0
Fork 0
Code Activity
fgdata/Nasal/canvas/map/route.model

26 lines
1 KiB
Text
Raw Normal View History

Many MapStructure/NavDisplay updates See the clone at https://gitorious.org/fg/canvas-hackers-fgdata/source/topics/canvas-radar:
2014-04-29 02:26:32 +00:00
# WARNING: *.model files will be deprecated, see: http://wiki.flightgear.org/MapStructure
Canvas Navigational Display: - get rid of global variables and use instance variables - identified all important drawing routines and move them into *.draw files - changed to dynamic loading of *.draw *.model and *.layer files - implemented poor-man's controller hash to move use-case specific conditionals out of the draw files, and back into the instantiation, i.e. Gijs' EFIS class - started identifying stuff that is not specific to drawing, but to what is to be drawn, i.e. Model stuff - such as positioned queries, moved those out into *.model files - some more work on supporting more than a single ND MFD instance per aircraft - renamed a handful of SVG identifiers to avoid naming conflicts and to simplify usage of SVG IDs as member fields - moved all of the setlistener setup out of the fdm-initialized stub right into the ctor of the Efis class (actually that's controller stuff...) - initial MapStructure framework - aircraft-agnostic NavDisplay class - preparations for deprecating map.nas - additions to canvas.map - preparations for making NDStyles configurable via XML
2013-12-01 12:29:22 +00:00
var RouteModel = {route_monitor:nil};
RouteModel.new = func make(LayerModel, RouteModel);
RouteModel.init = func {
me._view.reset();
MapStructure work & (partial) integration In time for 3.0. The API is still not fully complete, and not fully cleaned up, but this is good enough for this release cycle (and it should offer benefit longer term, if not now -- hopefully performance as well). Many thanks to Hooray as well, who has helped prepare things while I could not, and often suggested ideas.
2014-01-10 03:04:36 +00:00
if (!getprop("/autopilot/route-manager/active"))
return;
Canvas Navigational Display: - get rid of global variables and use instance variables - identified all important drawing routines and move them into *.draw files - changed to dynamic loading of *.draw *.model and *.layer files - implemented poor-man's controller hash to move use-case specific conditionals out of the draw files, and back into the instantiation, i.e. Gijs' EFIS class - started identifying stuff that is not specific to drawing, but to what is to be drawn, i.e. Model stuff - such as positioned queries, moved those out into *.model files - some more work on supporting more than a single ND MFD instance per aircraft - renamed a handful of SVG identifiers to avoid naming conflicts and to simplify usage of SVG IDs as member fields - moved all of the setlistener setup out of the fdm-initialized stub right into the ctor of the Efis class (actually that's controller stuff...) - initial MapStructure framework - aircraft-agnostic NavDisplay class - preparations for deprecating map.nas - additions to canvas.map - preparations for making NDStyles configurable via XML
2013-12-01 12:29:22 +00:00
## TODO: all the model stuff is still inside the draw file for now, this just ensures that it will be called once
foreach(var t; [nil] )
me.push(t);
me.notifyView();
#FIXME: segfault of the day: use this layer once without a route, and then with a route - and BOOM, need to investigate.
# TODO: should register a route manager listener here to update itself whenever the route/active WPT changes!
# also, if the layer is used in a dialog, the listener should be removed when the dialog is closed
if (me.route_monitor == nil) # FIXME: remove this listener durint reinit
me.route_monitor=setlistener("/autopilot/route-manager/active", func me.init() ); # this can probably be shared (singleton), because all canvases will be displaying same route ???
}
Copy permalink