Canvas GUI

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.

Canvas - the FlightGear 2D drawing API
Canvas - Main Page Canvas News - for the latest developments Shiva Alternatives - ongoing work for Core Profile support Canvas FAQs - frequently asked questions Canvas - Getting started Canvas Development (core) Canvas Troubleshooting (core) Canvas Sandbox (core) PUI2Canvas (PUI/XML Parser) Canvas GUI Canvas Widgets Canvas Maps Canvas Snippets
RFC
Canvas Instancing Howto:New Canvas Execution Model Canvas SVG Canvas Popout Windows Canvas Scenery Overlays
Frameworks
Canvas Map API (soon deprecated!) Canvas MapStructure Canvas MapStructure Layers MapStructure Snippets Canvas Radar Canvas Animation Framework (WIP) Canvas Plotting Framework (WIP) Canvas MFD Framework Canvas ND Framework Canvas PFD Framework Canvas MCDU Framework Canvas EFB Framework Canvas Wrappers Canvas Glass Cockpit Efforts
Tutorials
Howto: Canvas Troubleshooting Howto:Adding a canvas to a GUI dialog (PUI!) Howto:Creating a Canvas GUI dialog file (New) Howto:Dynamic Liveries via Canvas (new) Howto:Creating a Canvas GUI Widget Howto:Add a 2D canvas instrument to your aircraft Howto:Parsing 2D Instruments using the Canvas Howto:Creating fullscreen Canvas applications Howto:Use SVG inside a Canvas Howto:Extend the Canvas SVG module Howto:Serializing a Canvas to SVG Howto:Canvas applications as Nasal submodules Howto:Using raster images and nested canvases Canvas HUD Howto:Project 3D to 2D coordinates on desktop canvas
Reference
Canvas Element Group Image Map Path Text Canvas Nasal API MessageBox Layout System Canvas GUI API Canvas draw library Event Handling
Related
Canvas Properties Unifying the 2D rendering backend via canvas Howto:Use a Camera View in an Instrument Howto:Extending Canvas to support rendering 3D models Howto:Extending Canvas to support MathGL
To be ported
Navigation display Map FGCanvas Canvas Nasal/JavaScript Subset
Deprecated by Canvas
Complex Glass Cockpit Avionics
(click on headings to toggle)

I'd love for FlightGear to be runtime configurable through a GUI -- just drag and drop a property onto a drop-down menu, a keyboard diagram, etc., and build new dialogs while the plane is flying. — David Megginson ( Fri, 08 Nov 2002 17:15:38 -0800). starting the XML GUI; early implementors needed.

Note  the GUI API documentation can be found here: Canvas GUI API

Background

It has been suggested that this article or section be merged into Howto:Creating a Canvas GUI Widget.

In order to eventually phase out PUI completely, we need to stop adding PUI dependencies to the source tree. We now have the Canvas system, and there’s a formal decision to modernize the GUI using the Canvas, and completely replace PUI sooner rather than later.

The shortcomings of our GUI, and PUI in particular, have been repeatedly brought up on the devel list over the years.

It was a lot of work to get rid of hard-coded PUI dialogs, and we still have a bunch of hard-coded PUI widgets – as long as we have those, getting totally rid of PUI will be increasingly difficult, because each hard-coded widget will either need to be phased out or manually ported.

Which is exactly the reason why adding additional PUI widgets to the source tree is a really bad idea and counter-constructive to accomplish our long-term goal of phasing out PUI completely.

We should really work out a plan to get rid of hard-coded PUI widgets and re-implement them using canvas-driven widgets, and extend the canvas as we go. Once that is accomplished, completely replacing PUI will become much more straightforward, because it will basically boil down to writing a parser in Nasal to turn our existing dialogs into canvas widgets.

Adding more and more hard-coded PUI widgets to the mix will make our work increasingly difficult, especially if they implement important and useful features that we really want.

We really need to keep the total picture in mind, or we are growing our todo lists with stuff that wasn’t really necessary in the first place.

This discussion is solely focussed on providing a sane migration path, with the ultimate goal of getting totally rid of PUI.

Given that we have agreed to depreciate PUI, there's simply no reasonable reason to keep on adding PUI widgets/dependencies to the source tree - we need to stop doing that right now. Instead, we need to identify required Nasal/Canvas enhancements, in order to allow these widgets to be implemented outside C++ space.

Status 04/2014

Note  As of 04/2014, we have several people independently interested in working on Canvas/GUI features: owenpsmith & macnab (via Aircraft Generation Wizard) Philosopher working on an Interactive Nasal Console using Canvas kuifje09 working on Canvas/GUI widgets (for FGPlot) galvedro & Necolatis working on a Canvas-based procedurally created failure management dialog A Failure Management Framework for FlightGear punkedpanda interested in helping with GUI improvements also, one user mentioned being interested in working on an integrated GUI launcher in ticket #1295 It would make sense to coordinate all these efforts a little, so if you're working on anything related, please get in touch via the Canvas subforum.

So far, Canvas/MapStructure have helped make 2D maps available for all needs in FlightGear, and a canvas/Nasal-based parser that processes our existing GUI dialogs/HUDs or 2D panels code would have the same benefits (GUI: 10k, HUD:3k, 2D panels:4k). Generic canvas/Nasal framework for each of those would probably also be under 4k in total. But it is so much easier being NOT consistent. — Hooray (Wed May 14). Re: scaling instruments in xml.

Before creating new widgets please have a look at Tom's fgdata branch: https://gitorious.org/fg/toms-fgdata?p=fg:toms-fgdata.git;a=shortlog;h=refs/heads/canvas-gui-demo Tom is currently working on creating a standard widget and layout system (similar to eg. Qt). At the moment there only exists a button widget (but already with focus, and hover/press effects) [1]. Specifically, see $FG_ROOT/Nasal/canvas/gui.

Before we can replace PUI with a Canvas based GUI a lot work has to be done. Tom is currently working on extending the current canvas windows manager to also become a simple decorator engine which will allow creating unified window decorations and handling like dragging/resizing/closing windows. When this is done we can think of creating simple dialogs. And then we can start creating different widgets and see how to implement a layouting engine. And only then we can start thinking about replacing PUI dialogs with Canvas dialogs. (We may also need a fallback for older hardware as render-to-texture probably won't be supported).

So in the current state it would bring us much benefit to create a separate canvas dialog showing log messages without being able to show it in normal PUI dialogs. Later if we have got a list widgets it will be very easy to just print the log messages to this list widget.

Creating new Widgets

• text label
• checkbox
• radio buttons
• text field
• edit box

PUI Widgets

Canvas dialogs are definitely the way to go, as they are far more flexible and will replace PUI in the future. Since I think FG 2.11 you can create canvas dialogs with window decoration, including a title bar allowing to drag the window around and a close icon:

var dlg = canvas.Window.new([400,300], "dialog")
    .set("title", "My Canvas Dialog");

The existing XML dialogs can still be used and will also be usable in the future (by a backwards compatibility layer or some migration path).

Implementing all our existing PUI/XML-based dialogs is almost certainly going to be more work than providing a Nasal-space migration path/wrapper that reads the old dialogs and turns them into "modern" canvas windows, possibly by just overwriting the dialog-show fgcommand via the new removecommand/addcommand APIs. And phasing out canvas widget should be fairly straightforward too, because those can be directly mapped to embedded/nested canvas textures, so I wouldn't worry too much ...

All standard widgets (textbox, label, radio button, checkbox etc) can be provided by a Nasal parser that turns the existing GUI XML into canvas widgets — our hard-coded widgets however, need to be separately re-implemented. Here's a list of custom, hardcoded, PUI widgets which we will need to re-implement using the Canvas, usually located in flightgear/src/GUI:

• map widget (see MapStructure)
  • FlightGear commit 433af2 (expose the flight recorder/replay buffers via cppbind)
  • FlightGear commit 11c00a (add support for helipads from apt.dat 850+)
  • FlightGear commit 6bf47c (MapWidget: make use of the new POI system and display cities on the map. This is meant as a preview.)
  • FlightGear commit 658bda (MapWidget: Show counties and towns as well, depending on the zoom. Some colors added.)
  • FlightGear commit 38a373 (Display AI traffic route in map. Add some helpers so MapWidget can show the origin and destination of AIAircraft with a FlightPlan.)
• loglist
  • Required APIs: logbuffer needs to be exposed to Nasal via cppbind
• waypoint list
  • FlightGear commit 7afedb
  • FlightGear commit 846fd2
• airport list
  • Required APIs: extended NasalPositioned API
• waypoint list
  • Required APIs: extended NasalPositioned API
• property list
• file dialog
• menubar (see Howto:Making a Canvas Menubar)

In order to re-implement these using the Canvas system, we need to identify Nasal APIs that are currently missing, and which need to be provided via the cppbind framework.

This way, C++ developers can concentrate on providing the missing Nasal/C++ hooks, whereas Nasal developers can provide the required widgets.