Board index FlightGear Development Canvas

Airbus Navigation Display

Canvas is FlightGear's new fully scriptable 2D drawing system that will allow you to easily create new instruments, HUDs and even GUI dialogs and custom GUI widgets, without having to write C++ code and without having to rebuild FlightGear.

Airbus Navigation Display

Postby artix » Wed Oct 01, 2014 6:24 pm

Hello, my implementation of a generic Airbus Navigation Display into the canvas framework is 80% done. Before this summer i created a ND canvas for a fork of the A330-200. You can see it in this post:

http://forum.flightgear.org/viewtopic.php?f=14&t=23736

The code was obviously too aircraft-specific, so, after talking with Hooray, I started to abstract the code in order to have a generic Airbus ND directly into the canvas framework, so that it can be used with many Airbus aircrafts.
Most of the Airbus aircraft share the same ND (A320, A330-200, A330-300,...) and other Airbus aircrafts only have little differences in their ND. So it's a good thing to have a common generic Airbus ND that can be customized with very little effort.

Technically, the ND implementation is based on a new hash declared into navdisplay.style file (having 'Airbus' as key). I've tried to use the same MapStructure files used for Boeing when possible (it means that many MapStructure layer/symbols are shared between the Boeing and the Airbus ND). In some other cases i had to duplicate these files and create an Airbus version (ie. WPT-airbus.symbol) because of too different logics.
The shared symbols/controllers use callbacks, options and styles in order to provide different graphics and sometimes different behaviors for Airbus and Boeing ND.

I had to make some little change to MapStructure and canvas API that i will document here:

- Options are now passed to layers/symbols if they're declared directly inside every layer declared in the navdisplay.style hash.
- Same for style, it can be passed in the layer hash defined in navdisplay.style
- New Symbol methods

    getOption(optname, default = nil) -> gets an option or a default value if passed (default is nil)
    getStyle(optname, default = nil) -> gets a style property value or a default value if passed (default is nil). If the property valueis a func, the func is executed and its return value is used as the property value

- canvas.Group methods

    setColor(color, types = [Path, Text]) -> sets the specified color to all children of the group element (recursively) that match with the types specified by the second argument

- SVGSymbol now checks for an optional svg_path passed in the options hash and uses it if found. This allows to define different SVG files for the same .symbol file so that different ND implementation can share the same .symbol file with different graphics.

- Many .symbol/.lcontroller files now check for optional settings and styles and often use callbacks in order to perform different behaviors or use different graphics for different ND implementations. This is not standardized yet and i have put this checks and callbacks only in the files I needed. But we could think to make this a default behavior for all type of Symbols and Layers.

The work is not yet done, and the code still needs to be documented and cleaned-up.
If you want to try this implementation into your Airbus I can give you some hint on how to do it.
During the next days I will write a more comprehensive documentation for both the new API and the configuration needed to implement the ND on your Airbus aircraft.

You can find this implementation on the fg-canvas-hackers repo (the branch is named topics/airbus_nd):

https://gitorious.org/fg/canvas-hackers-fgdata/source/f58601124ea509e4465191ad084bd15d27da11e7:
artix
 
Posts: 93
Joined: Wed Jun 25, 2014 9:42 pm
OS: Mac OS X

Re: Airbus Navigation Display

Postby Hooray » Wed Oct 01, 2014 8:58 pm

thanks for the heads-up, I've looked at your commits a few days ago - but I am currently basically "offline" so cannot yet comment properly. However, your initial commits and comments look sane to me. I'll probably try to get back to this in a few weeks time.
In the meantime, it would seem like a good idea to document your suggested changes - you don't have to use the wiki for that yet, adding corresponding comments to your code should suffice.
From a review standpoint, it would make sense to let other aircraft developers like Hyde and Gijs review your changes - primarily to ensure that your changes do not break existing implementations (see the wiki), but also to ensure that there is no overlapping/conflicting work going on, Subsequently, I would like to see input from other airbus developers, to ensure that your changes are sufficiently generic - for that, it would indeed help to document your changes so that others can implement your changes - that should also help ensure that other developers can contribute to an airbus-specific implementation.

Once that is the case, Gijs should probably review your structural changes - so that I can take another look with a focus on Nasal - depending on Philosopher's availability, he may also want to review your changes to options/MapStructure handling, because that part was primarily written by him.

I think we can proceed with copies of sufficiently distinct layers, but should probably strive to either make those layers more customizable or allow layers/controllers to be shared/replaced if necessary (eventually).

So far, I've only looked at your first commit yet, I am hoping to provide more specific feedback in a few days - but you should be safe as long as you team up with people doing related work, i.e. to integrate the display on other airbus aircraft, while ensuring that Gijs and Hyde are still happy with your changes - we can then optimize things later. Keep in mind, 3.2 isn't even out yet - so plenty of time to polish things

BTW: It would make sense to also clean up navdisplay.mfd itself, especially the newMFD and update methods contain still too much aircraft specific stuff that should become customizable eventually - the basic roadmap can be found on the wiki (ND article), just be sure to coordinate your work here with Gijs


PS: Let us know if you'd like to see any particular airbus aircraft developers provided with commit access to the team clone, so that things don't get stuck despite our hiatus :-)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Airbus Navigation Display

Postby Hooray » Wed Oct 01, 2014 9:10 pm

Here's a few more comments regarding your commits:

- instead of using hard-coded colors, it would be better to use styling for such things as colors, line width, fonts etc - see existing layers for examples (can be copied & pasted)
- seems like a good idea to use a dedicated sub folder for aircraft specific symbols!
- the airbus integration in navdisplay.styles should be selectable via the constructor call, and not hard-coded there probably?
- removeAllChildren() should be rarely needed now, so be careful when using it
- adding symbols to styling hashes seems like a pretty clever move to me ! :D (WPT-airbus.lcontroller)
- regarding WPT-airbus.symbol, there must be a better way than using the length of the identifier here ??

Overall, this is looking pretty good to me, so once 3.2 is out, it would make sense to get Gijs and Hyde involved, so that they can help review your changes from the Boeing perspective. Also, you have already addressed some of the changes that we've been discussing/documenting on the wiki (see the roadmap section there) - in other words, I am really supportive of the nature of those changes, we will just want to make sure that all existing use-cases are still supported, while also ensuring that our code is getting increasingly generalized and unified to hopefully get rid of special-cases.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Airbus Navigation Display

Postby Gijs » Wed Oct 01, 2014 9:15 pm

Great work, looks very promising! I'll have a closer look at it once you're happy to have it included in fgdata.
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9544
Joined: Tue Jul 03, 2007 3:55 pm
Location: Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: Airbus Navigation Display

Postby Hooray » Wed Oct 01, 2014 9:19 pm

based on the evolution of the Boeing ND it would obviously help to get more eyeballs and contributors involved early on - in other words, it would probably make sense to look up existing Airbus aircraft using the Boeing ND and adapting those already, while looking for other, actively-maintained, candidate aircraft that could be ported by their respective maintainers - once that is the case, things will evolve automatically, because people will start yelling once something breaks somewhere, while everybody will still contribute to a shared, and common, framework behind the scenes.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Airbus Navigation Display

Postby artix » Thu Oct 02, 2014 7:52 am

Hooray wrote in Wed Oct 01, 2014 9:10 pm:- instead of using hard-coded colors, it would be better to use styling for such things as colors, line width, fonts etc - see existing layers for examples (can be copied & pasted)

Yes, you're right. It will be done.

Hooray wrote in Wed Oct 01, 2014 9:10 pm:- seems like a good idea to use a dedicated sub folder for aircraft specific symbols!


Currenty the subfolder is only used for images/svg. I was thinking about moving .symbol and .lcontroller files there too, but the loader should be modified.

Hooray wrote in Wed Oct 01, 2014 9:10 pm:- the airbus integration in navdisplay.styles should be selectable via the constructor call, and not hard-coded there probably?


Isn't it already in the NavDisplay class constructor?

Code: Select all
new : func(prop1, switches=default_switches, style='Boeing')


Hooray wrote in Wed Oct 01, 2014 9:10 pm:- removeAllChildren() should be rarely needed now, so be careful when using it


I will find a better alternative

Hooray wrote in Wed Oct 01, 2014 9:10 pm:- regarding WPT-airbus.symbol, there must be a better way than using the length of the identifier here ??


Maybe yes, i will explore other ways
artix
 
Posts: 93
Joined: Wed Jun 25, 2014 9:42 pm
OS: Mac OS X

Re: Airbus Navigation Display

Postby Hooray » Thu Oct 02, 2014 8:28 am

I would not yet bother moving MapStructure files to separate folders - basically, we want to prevent "copy & paste programming" whenever possible, so if the framework isn't yet sufficiently generic to allow such different use-cases to be implemented through a single set of files, we simply need to investigate what's missing to make this happen - in the meantime, keeping separate files seems straightforward enough to me.
Even though, I would hope that we can explore identifying missing hooks and simply add those over time.
Keep in mind that MapStructure is not about NDs or certain aircraft - it's a generic mapping back-end, and it should be sufficiently customizable through hashes for options, styling, callbacks/behavior etc
Normally, people could get a standard layer and then customize it subsequently - for instance, by extending a sub-class.
Nothing here is set in stone - by adopting and contributing to the framework, you can be the change you want to see.
Also, your changes look pretty good and safe to me for now, because others are using the Boeing ND style currently, and Gijs seems primarily concerned about Boeing features, while you have been adding to the MapStructure/Canvas APIs, which Gijs doesn't touch usually.
My mid-term goal would be to make those MVC classes sufficiently generic to allow custom stuff to be registered directly, without necessarily having to duplicate files manually, i.e. through OOP
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Airbus Navigation Display

Postby artix » Thu Oct 02, 2014 7:21 pm

Here's a sample of my implementation on the A330-200. This implementation just defines some listeners and creates the canvas ND using the fgdata Airbus ND i made (calling the 'Airbus' style on the costructor).

In order to use it you have to create a black ND panel with an object called ND.screen inside (you can find a simple tutorial in the flightgear wiki).
Then create a file called ND.nas or whatever you like and try writing something like this:

http://pastebin.com/pVj1BsuW

Change the properties used in the listeners according to the properties of your own Aircraft.
Remember that many symbols/layers use various hard-coded properties that can be easily customized by overriding the options. Take a look into the various layers declared in the Airbus hash inside Nasal/canvas/map/navdisplay.style file. For example, if you look into 'ALT-profile' layer, you will find these options:

Code: Select all

options:{
     active_node: "/autopilot/route-manager/active",
     vnav_node: "/autopilot/route-manager/vnav/",
     ....
}



It's easy to customize them, jsut write something like this before initializing the ND:

Code: Select all
canvas.NDStyles['Airbus'].layers['ALT-profile'].options.vnav_node = 'my/vnav/node';


Feel free to ask me everything you need to know.
artix
 
Posts: 93
Joined: Wed Jun 25, 2014 9:42 pm
OS: Mac OS X

Re: Airbus Navigation Display

Postby Hooray » Thu Oct 02, 2014 7:42 pm

that's looking pretty good already.
Regarding ND.nas, I was hoping to move all the init logic to navdisplay.mfd itself - so that the ND.nas file only needs to contain the configuration hash, i.e. everything beyond line #60 in your snippet.
That would also help unify things for the 747 and 777 - because everything beyond line 60 is basically identical, so should live outside ND.nas
I think it's only the 777 where Hyde is using some custom construct to allow event handlers to be disabled - but that can also be easily made optional.
Concerning the configuration hash, I would like to encode types there, so that we can create a proper Canvas GUI dialog with buttons/checkboxes for each property, or a combo box for supported ranges.
That way, we can prototype, test & develop additional ND features without having to load any particular aircraft.
For airbus specific features/switches, I'd consider naming the switch accordingly, so that people can directly tell if a switch is generic or manufacturer specific.

Now, your changes beyond line 80+ should probably be discussed - the approach itself looks good to me, but first of all, setlistener() calls need to be wrapped in some way to do resource management, i.e. to keep the listener ID - especially for reset/re-init.

And mode management around line 105 is obviously yet another workaround, like all those workarounds in other Canvas MFDs doing switch/mode management... so this kind of code should hopefully not propagate - it's this kind of code that is making the update() method in navdisplay.mfd a maintenance challenge.

For starters, you can simplify all your listeners by using a foreach() loop and then dealing with the props.Node object that you get in arg[0] - while appending each listener ID to a vector for reset/re-init handling. But in the mid-term, we need a more scaleable method here.

We were discussing solving pretty much the same problem a few months ago when Soitanen wanted to support custom numbers of nav[x] receivers etc.
I think I added the suggested method to the wiki - so you may want to take a look. But it did involve overloading the otpions hash
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Airbus Navigation Display

Postby artix » Sat Jan 03, 2015 3:36 pm

I've updated the topics/airbus_nd branch on the canvas hackers fgdata repo (https://gitorious.org/fg/canvas-hackers ... 3da0331db5: ).

Now the Airbus ND is much more configurable and customizable. Most of the colors are customizable using the style hashes. Furthermore, all the property tree nodes are customizable using the options hashes, so every aircraft developer is free to change them according to the internal logic of their aircraft.
Also the code is much more documented via internal comments. I will provide a complete documentation for Airbus developers as soon as possible.
I've made some test with the Boeing ND and it seems that everything is working, so i assume that none of my modifications did break the existing implementation.
I'd also like to know if some Airbus developer has tried to implement the canvas ND in order to see if something has to be improved.

Do you think that the Airbus ND could be shipped with the next FlightGear release planned for February?

Let me know.

Happy new year.
artix
 
Posts: 93
Joined: Wed Jun 25, 2014 9:42 pm
OS: Mac OS X

Re: Airbus Navigation Display

Postby Hooray » Sat Jan 03, 2015 4:32 pm

Just briefly:

  • have you checked that this still supports multiple independent instances ?
  • have you implemented the instrument on a an airbus aircraft (sry, cannot run FG at the moment, and some commits are too big to view them on gitorious) ?
  • for testing purposes, I would extend the map-canvas.xml dialog and add you new features there - hopefully, they are not aircraft specific, but also available to be used on the map ?
  • the td/tc handling I would like to see unified with the work Gijs and Hyde have recently been doing - i.e. made aircraft/manufacturer agnostic
  • it would be great if you could help update/main the wiki accordingly, you will find that aircraft devs will start adopting your changes once you add more docs/integration examples
  • equally, adding an announcement to the newsletter (wiki), including a few screen shots will be helpful (you can reuse those screen shots on the MapStructure/Layers article)
  • I don't see any problems with getting this committed, as it shouldn't break existing stuff - but Gijs & Hyde need to review things first, to ensure that this is indeed the case (Boeing still working)
  • you did a really job with all those comments in there (I reviewed the 2nd commit, and it's looking pretty good to me)
  • things like "instrumentation/efis/nd/managed-spd" I would hope to also make configurable ?
  • I don't think you should be adding the non-MapStructure layers (storms, mp-traffic), because those should go sooner or later - so I would just remove those unless you happen to be using the, anywhere ?
  • overall, your new layers (HOLD etc) are looking really good - but I would prefer those to be also available/integrated on the map-canvas dialog for regression testing purposes (i.e. no need for actually starting an airliner and/or being familiar with all its internals)
  • the way you use styling looks good to me - but Philosopher is the real authority here - keep in mind though, that we used to add styling to lcontroller files, and were contemplating to make it part of the symbol files to keep things neatly organized/encapsulated (but plz wait for P. to report back)


Overall, you really did a terrific job here, and I am considering you to be more familiar with MapStructure/Canvas internals than myself meanwhile (I haven't done any related coding in months....). So I am really impressed, and would like to add you to the list of MapStructure/ND maintainers - you've basically demonstrated a really good understanding of the system, and its concepts, so it would be a pity not to have you involved to help refactor/maintain the system to ensure that it is sufficiently generic - honestly, I haven't seen any other contributors around here able to pick up Nasal, Canvas and MapStructure/ND concepts so quickly, and properly.


Personally, I would hope that we could clean up navdisplay.mfd and remove aircraft specific stuff - while reducing update() accordingly.
equally, there's some dead code, as well as redundant code - especially aircraftpos.contoller should be used in more places (we have identical code in quite a few places, lacking encapsulation)

Again, the commit is looking really good and I am pretty impressed with your work, good job ! :D
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Airbus Navigation Display

Postby artix » Sun Jan 04, 2015 8:29 pm

Hooray wrote in Sat Jan 03, 2015 4:32 pm: have you checked that this still supports multiple independent instances ?

Not yet honestly, i have to test it.
Hooray wrote in Sat Jan 03, 2015 4:32 pm: have you implemented the instrument on a an airbus aircraft (sry, cannot run FG at the moment, and some commits are too big to view them on gitorious) ?

Yes, on the same Airbus A330-200 i used in my implementation: i simply replaced the old aircraft-specific implementation with the generic fgdata one, and everything is working fine.
Hooray wrote in Sat Jan 03, 2015 4:32 pm: for testing purposes, I would extend the map-canvas.xml dialog and add you new features there - hopefully, they are not aircraft specific, but also available to be used on the map ?

Which features are you thinking about?
Hooray wrote in Sat Jan 03, 2015 4:32 pm: the td/tc handling I would like to see unified with the work Gijs and Hyde have recently been doing - i.e. made aircraft/manufacturer agnostic

Where can i find their work?
Hooray wrote in Sat Jan 03, 2015 4:32 pm: it would be great if you could help update/main the wiki accordingly, you will find that aircraft devs will start adopting your changes once you add more docs/integration examples

I will do it in the next days, i hope
Hooray wrote in Sat Jan 03, 2015 4:32 pm: equally, adding an announcement to the newsletter (wiki), including a few screen shots will be helpful (you can reuse those screen shots on the MapStructure/Layers article)

How can i add an announcement to the newsletter? Do i need some special account?
Hooray wrote in Sat Jan 03, 2015 4:32 pm: things like "instrumentation/efis/nd/managed-spd" I would hope to also make configurable ?

Sure, i forgot it :P
Hooray wrote in Sat Jan 03, 2015 4:32 pm:overall, your new layers (HOLD etc) are looking really good - but I would prefer those to be also available/integrated on the map-canvas dialog for regression testing purposes (i.e. no need for actually starting an airliner and/or being familiar with all its internals)

The main difficulty here is that i didn't find any generic/built-in way to manage hold patterns in FlightGear: while navaids, routes, waypoints are builtin feature of FG and it's easy to implement them following an "aircraft-agnostic" pattern, i built the HOLD layer upon the property tree structure that was used on the A330-200 by Omega95.
Despite the fact that I made those properties customizable, every aircraft developer should conform to that logic in order to use the HOLD layer on their aircraft.
It's easily re-usable on every aircraft (also non Airbus-aircrafts) because now both the property nodes and the color/style are customizable, but every developer has to implement the Hold pattern in their flight-management scripts.
I think at this implementation as a temporary one and i would like to make something more standardized in the future.
So at the moment i cannot figure how to add this layer to the map canvas dialog without having a built-in support for hold patterns.
There's also another limit in the hold pattern ATM: i didn't find how to create circular/arc paths based on geographic coordinates (latitude/longitude). It's possibile with paths made of lines but i cannot find how to obtain it with arcs (maybe i'm missing something but i've searched in the API and couldn't find something like this).
So the HOLD pattern currently is a non-geographic path (made of arcs and lines, but based on pixel coordinates and not geo-coordinates) that is scaled according to the current range of the map.

Hooray wrote in Sat Jan 03, 2015 4:32 pm: the way you use styling looks good to me - but Philosopher is the real authority here - keep in mind though, that we used to add styling to lcontroller files, and were contemplating to make it part of the symbol files to keep things neatly organized/encapsulated (but plz wait for P. to report back)


IMHO the lcontroller/symbol files should only contain default style definition. In order to make the layers generics and customizable i made a little change to navdisplay.mfd that makes possible to pass style hashes taken from the navdisplay.style file to the layers. This allows to override default styles. All things coded into lcontroller/symbol files should be considered "hard-coded" IMHO.
However, i will wait for Philosofer's verdict :)
artix
 
Posts: 93
Joined: Wed Jun 25, 2014 9:42 pm
OS: Mac OS X

Re: Airbus Navigation Display

Postby Hooray » Sun Jan 04, 2015 8:59 pm

Regarding the Td/Tc stuff, I suggest to check out Hyde's summary at: T/C and T/D mark display on ND (from PM)

Regarding your workaround involving holding patterns, I'd suggest to refer to Gijs' explanation below:
Canvas ND performance issues with route-manager
Gijs wrote:I believe the old ND code only displays the waypoints and then draws a straight line between them. The new ND uses the actual route-manager paths, which allows it to draw holdings, flyby waypoints (thanks to James recent work) etc. But we'll need the azimuthal projection anyway, so I'll bump my todo list ;-)

PS: With segments I meant that a single path between two waypoints consists of multiple segments/lines/sections.


Regarding most of the other points:

  • yes, please do make sure that independent instances still work
  • equally, any new/modified MapStructure layers should also still work on the standalone map-canvas.xml dialog
  • ideally, new/modified MapStructure layers would also maintain encapsulation for aircraft specific stuff (position/lat,lon,alt etc) - e.g. so that layers are aircraft/FDM-agnostic, and would even work for AI traffic (this helps keeping things truly generic and portable)
  • if you can, please feel free to upload screen shots to the wiki (you only need a wiki account)
  • equally, your wiki account will suffice to add to the wiki-based newsletter (see my signature for details)
  • once you're satisfied with your work, it would be great if you could help review the MapStructure/ND articles to add anything you consider missing/useful - i.e. stuff we forgot
  • stuff like instrumentation/efis/nd/managed-spd would ideally be moved to a delegate inside aircraftpos.controller, which would then be used by the MS/ND files, so that anything that is aircraft specific can be easily configured/overridden there
  • good point on ND styling (I missed that ...)

PS: like I mentioned in my PM, I'd suggest to closely coordinate your Airbus related MapStructure/ND efforts with omega95, especially because of his WXR/VSD work, which should be ideally integrated properly - and you seem to be in a good position to help with that given you recent work. So I would hope that you could help omega95 with his work, so that Gijs and Hyde can review those changes with a focus on maintaining a working Boeing ND - once that's the case, I'll review/refactor those changes and let Philosopher have a final look to get the stuff committed. That way, we're lowering our workload and end up with a chain of reviewers who are more familiar with different aspects of the MapStructure/ND work. However, if you are planning to add any other features, please say so here - so that Gijs and others are aware of your work. For instance, it would seem your HOLD work is overlapping with Gijs' plans (see above, not sure if those will make it into 3.4 tho).

EDIT: If I am not mistaken, your modified WPT/VOR layers are no longer using the built-in caching framework, is that correct ? If that's due to styling support, you should know that Philosopher came up with a fairly clever scheme to support styling+caching (see the FIX/DME layers for details). I am just mentioning this here, because NOT using caching may impact performance significantly.

https://gitorious.org/fg/canvas-hackers ... bus.symbol
https://gitorious.org/fg/canvas-hackers ... bus.symbol

In the mid-term, it would make sense to look at these files and merge those implementation to ensure that there's a single "generic" file which satisfies all main use cases
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Airbus Navigation Display

Postby Philosopher » Sun Jan 04, 2015 10:03 pm

looking at the diff for a few minutes, here are a few comments:
  • be careful with tabs vs 2 spaces vs 4 spaces – my version of MapStructure.nas only has tabs, api.nas uses 2 spaces, etc. while most of what I see added is 4-spaced ;-) It's not "bad", it just looks ugly on different editors...
  • do you have a use case for your getChildrenOfType/setColor? I would want to make sure Tom reviews those... also var children = array is unecessary – just call the argument children.... and I think it could be optimized a bit (no need to call regular .getChildren IMO)
  • is there a reason for making the argument to Map.addLayer be _options not options? personally, since the argument name is public-facing, I would make it named without the underscore. (looks like you just assign it back anyways, right?)
  • overall the changes to the layers look pretty good, I like the fact that they all support SVG now!
  • thanks for the comments and helpers and such, I'll take a deeper look at it later (sorry for being so inactive, I'm just really busy this year... got a little break over the holidays though ^^)
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: Airbus Navigation Display

Postby Hooray » Mon Jan 05, 2015 2:22 pm

I'd also to suggest make the colors here configurable: https://gitorious.org/fg/canvas-hackers ... symbol#L25
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Next

Return to Canvas

Who is online

Users browsing this forum: No registered users and 6 guests