Talk:ATC-FS

Porting ATC-FS to use the new Canvas system

You can see for yourself how the canvas/maps system works by looking at Tom's branch: http://gitorious.org/~tomprogs/fg/toms-fgdata/blobs/canvas/gui/dialogs/map-canvas.xml Currently, all the code is embedded inline - in the long run, it would probably make sense to create some new "map.nas" module and generalize things there, so that the code in the XML file becomes more compact.

Yes thanks, I already copied the canvas-map stuff and started trying some modification and so on to get familiar with the canvas system. I definetely want to create a map.nas module with seperated drawing commands for different layers like traffic, fixes, airports and some other. Unfortunately the limiting factor is the time. So it may take a while to get it done.

That's really no problem, remember, it will take another 6+ months until FG 3.0 is out, which will contain all the C++ code for the new canvas system, so there's plenty of time for experiments. The map.nas module is definitely a good idea and it should be added to the canvas folder in $FG_ROOT/Nasal/canvas then, so that more complex applications can be built on top of it, not just dialogs but also MFDs like a typical NavDisplay.

My plan is to create that module to operate on generic canvas groups, so you can embed it everywhere. As far as I understood the canvas system, that's the most generic component.

Yes, you are right - canvas is the lowest layer, but it makes sense to not only support api.nas but also the svg.nas module so that map symbols can be loaded from the file system, which means much less Nasal code - and very simple styling, just by exchanging the vector images ...Your idea sounds good to me: canvas groups can also be easily enabled/disabled so that map "layers" can be easily created, i.e. for "fixes", "airports", "navaids" or even the route from the route manager. Basically, the map.nas module can then be used for glass cockpit displays, but also for ATC screens - and it will be very easy to customize it, i.e. by disabling modules or by changing colors. Also the vector drawing functions (OpenVG based) make it possible to reuse and load vector data from other ATC sims, so that you could show real ATC sectors, too

This really just requires writing a parser for the file format so that it turns the vector data to canvas properties, the svg parser is already doing that for example. We are also planning to add another parser for vector data from ESRI files, so that your ATC screen can even show borders, rivers and road networks, too. None of this will require C++ changes, it can all be done in scripting space. It would be great if the ATC-developers (like you and jomo) could work together on this, so that we get a single useful system and a powerful API. It will probably take another 6-12 months, but ultimately the idea is that it will be possible to start up FG without aircraft, in a different "ATC only" mode ... Like I said earlier, it will even be possible to implement custom GUI widgets, e.g. for flightstrips [1]

Yep, that totally conviced me. Changing flightstrips by just clicking in them and writing is the way to go. Just to be clear about it: the svg.nas module also just parses the XML/SVG file and then puts the geometry into a "canvas group", so your method is definitely correct. Basically, using the svg.nas module means that you don't need to draw anything, you can just load an XML file and transform/rotate it as needed, so that other people can provide the symbols (fixes, runways, airports, ILS)

Also see Howto:Creating fullscreen Canvas applications.