From FlightGear wiki
Jump to navigation Jump to search
This article or section contains out-of-date information

Please help improve this article by updating it. There may be additional information on the talk page.

The Canvas-hackers team clone on gitorious is intended to streamline collaboration among FlightGear contributors who are doing Canvas related development intended to be merged into upstream fgdata, especially related to long-term efforts to help Unifying the 2D rendering backend via canvas such as:

Cquote1.png We originally set this up to allow non-fgdata committers to commit canvas related contributions to a single repository - since then, MapStructure development has stalled a bit. These days, it's primarily artix who's been doing most related development.

Originally, the idea was to regularly sync back useful changes so that they appear in the "upstream" fgdata repository. Since then, quite a few things have changed - including the fgdata/fgaddon split, but also gitorious shutting down, which is why we're lagging a bit behind.
Also, gitorious announced that they'd shut down all repos at the end of May IIRC - but it seems quite a few repositories/projects are already no longer reachable unfortunately. So there's that too.

— Hooray (Sat Apr 04). Re: new locatio of Canvas-hackers-fgdata branch?.
(powered by Instant-Cquotes)

While there is a Mailing list, in comparison to the forum, it's fairly inactive these days and it's primarily about C++ level CORE development.

For Canvas related things, we often also discuss core changes on the forum, because we have a dedicated subforum here, and because TheTom, as the main Canvas core developer, is very active on the forum and usually handles support requests or feature requests pretty promptly.

Regarding wiki articles and Canvas related priorities. the focus/manpower is mostly on 1) re-implementing our existing GUI on top of Canvas through custom (scripted) widgets: Canvas Widgets (mostly handled by TheTom & Zakalawe, both of them core devs).

And then, we're busy re-implementing existing hard-coded "glass" instruments using Canvas, i.e. stuff like the ND, PFD etc.

For that, we try to generalize, unify and extend existing code and make it use Canvas, by coming up with custom scripting-space frameworks for the main use-cases. This includes things like having a dedicated Canvas Animation Framework that deals with SVG elements and animations handled via timers and listeners.

But also frameworks for other MFD related purposes, such as: 1) MFDs in general, 2) PFDs, 3) NDs, 4) CDUs and 5) EFBs These are intended to be just tiny wrappers to help localize key functionality (e.g. MFD page/mode handling), so that we can easily update and optimize things, without having to touch a ton of places (aircraft/instruments/dialogs).

The long-term idea is to provide scripted frameworks on top Canvas, e.g. for MFDs - and each kind of MFD would implement the corresponding MFD interface.

Canvas-wise, the main trend is to increasingly modernize and unify our 2D rendering back-end by adopting canvas in several key areas by Unifying the 2D rendering backend via canvas:

  • glass instruments (ND/PFD)
  • 2D panels/instruments
  • HUDs
  • GUI dialogs/widgets

We have 3 core developers and a handful of Nasal/Canvas contributors working towards this - so this is generally considered a useful thing, and several active contributors are working towards the same goal here .

At the Canvas core/C++ level, there are some minor enhancements discussed/planned: Canvas Development. But anything touching the C++ code should really be coordinated with TheTom.

So you can basically "pick your poison" - feel free to ask via the canvas forum for more opinions/pointers and feedback.

Otherwise, there's also an issue tracker - and various wiki articles on getting started contributing/coding.

For the time being there's quite some manpower in Canvas related effort - and it allows us to get rid of a ton of legacy C++ code, while also modernizing FG quite a bit, i.e. to obtain better frame rates, a more modern GUI, better consistency etc.

Should you be interested in working on anything related to Canvas, we have people willing to provide mentoring through custom tutorials etc (get in touch with Hooray).

The priorities are mostly those mentioned above, and there are core developers willing to commit related stuff. We'd just suggest to make sure to release early & often, so that you can gather & implement feedback early on.

Feel free to get in touch via the canvas forum to get more pointers.

We'd suggest to get started with just Nasal/Canvas, because there isn't much of an entry barrier - and we're still looking to port a few layers: Canvas MapStructure Layers: We have a few "old" layers that do not yet use the new system, i.e. they work already, but are not yet ported - which would be good for performance reasons. That is something that we would help with, and also "mentor", because it would be useful for FG as a whole, because all MapStructure layers can be used on all aircraft/dialogs, so not aircraft specific. The MapStructure Layers article should provide a rough overview.

The lowest hanging fruit there would be porting the "tower.draw" file to become a MapStructure layer with a proper lcontroller/symbol file. That one should be even simpler than the AA work. "Parking" would be another simple layer to get started.

  • $FG_ROOT/Nasal/canvas/map/tower.draw
  • $FG_ROOT/Nasal/canvas/map/parking.draw
  • we're also missing an ILS/LOC layer that draws a localizer symbol (see Map)
  • $FG_ROOT/Nasal/canvas/map/runway-nd.draw also hasn't yet been ported to MapStructure

And then there are 3-4 others that will undoubtedly require a little more help from our side (e.g. runways.draw, taxiways.draw), but otherwise it should be straightforward, and a good exercise to learn more about creating your own maps/charts - which should also come in handy for any more sophisticated efforts.

Some of the more sophisticated layers actually make use of customizable styling and caching - depending on the nature of the layer (e.g. static vs. moving objects), it makes sense to keep such things in mind. Another important consideration is LOD handling, i.e. changing the symbol based on the map's range. Another thing we're not currently dealing with is centralized labeling and decluttering.

In the near-term, it would also make sense to better encapsulate properties that may be aircraft specific, or that would break when used with an AI aircraft, i.e. all references to properties provided by the autopilot, route manager, weather system or radios/instrumentation. We really want to support independent instances, no matter how often the framework is used concurrently - for example, see the following forum posting demonstrating how the ND is driven by AI traffic[1].

Also, in the process, we'd like to improve the wiki docs accordingly - because our goal is to provide all the docs to enable newcomers to create their own mapping layers.

But for starters, creating/porting a few MapStructure layers should be a good learning exercise, and the whole experience should help you once you want to get involved in other Canvas areas.

Note  People don't need to have fgdata commit privileges to contribute. However, you should obviously know a little about Nasal scripting, OOP and Canvas.

We're hoping to regularly sync our work with fgdata upstream - realistically, that ones once in 6-8 weeks probably.

Branch Description Status Schedule People Notes
canvas-map-dialog Port the hard-coded Map dialog to Canvas 70}% completed Hopefully 3.2 Philosopher & Hooray ...
topics/fgplot 2D plotting 70}% completed Hopefully 3.2 kuijfe09 ...
canvas-airports-dialog Port the airport-selection dialog to Canvas 10}% completed unknown Philosopher & Hooray ...
yet to come Garmin gpsMap196 ported to Canvas 10}% completed unknown F-JJTH [2], Hooray ...
yet to come Procedurally-created Canvas GUI dialogs for A Failure Management Framework for FlightGear Not done Not done unknown Galvedro, Necolatis, Hooray ...