Canvas GUI

From FlightGear wiki
Jump to: navigation, 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.

Cquote1.png 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


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:

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.

Cquote1.png 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:;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 =[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:

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.