FlightGear wiki - User contributions [en]

Template:Canvas Widget Matrix

2023-10-02T06:30:07Z

Hooray: /* Status */

{{Note|If you'd like to get involved in working on widgets or creating new ones, please get in touch via the devel-mailing list to coordinate related efforts with James Turner first.}}
The following tablet represents a list of Canvas GUI widgets, with the goal being to implement a sufficient number of widgets to re-implement/emulate basic [[PUI]] functionality by using the new {{Fgdata file|Nasal/gui/XMLDialog.nas}} module that translates existing PUI/XML dialogs into Canvas dialogs dynamically (i.e. at runtime). To learn more about the rationale, please see [[PUI#Replacement status]], [[Unifying the 2D rendering backend via canvas]] and [[Hackathon Proposal:Canvas Widgets]].

For a (somewhat outdated) overview of PUI widgets used by FlightGear, see {{Readme file|gui}}.
To learn more about undocumented widgets, see: [[Template:PUI widget]]

For an authoritative list of PUI based widgets used by FlightGear, please refer to {{Flightgear source|src/GUI/FGPUIDialog.cxx|line=882}}.

== Status ==
{{See also|PUI#Status}}
'''Last updated: 10/2023
'''
* The upcoming Hackathon might provide another opportunity to revisit some Canvas todo items: [[Hackathon Proposal:Canvas Widgets]]
* The lack of the menubar being implemented in Canvas was raised on the devel-list <ref>https://sourceforge.net/p/flightgear/mailman/message/37884138/</ref>
* The Canvas GUI Camera needs additional work in Core Profile mode <ref>https://forum.flightgear.org/viewtopic.php?f=19&t=41377&p=414781&hilit=#p414781</ref>
* Implementation of missing widgets to emulate [[PUI]] {{Progressbar|70}} (7/20 missing)
* add the menubar to the widget factory dialog {{Done}}
* Once the menubar widget is working properly and once we can parse/translate menubar.xml, we should consider using a separate dialog to show the fully translated menubar {{Not done}}
* Introduce a dialog to preview dialogs generated by XMLDialog.nas, so that more contributors can get involved in previewing/testing existing dialogs (including those outside fgdata) {{Not done}}
* C++ additions:
** expose [[SG_LOG]] stream for the loglist widget {{Not done}}
** expose translations for the menubar {{not done}}
** before porting the [[Map dialog|mapWidget]] (and before phasing it out), we need to revisit a long standing issue, i.e. not having back-ported the projection handling fix to the Canvas system: {{Issue|550}} and {{Issue|454}} (for details see [[Canvas_development#Projections]] and [[Howto:Adding new projections to Canvas Map]]) <ref>https://forum.flightgear.org/search.php?st=0&sk=t&sd=d&sr=posts&keywords=canvas+projection+map</ref>
** when opening 3+ concurrent instances of the new propertyTree dialog, fgfs will be massively slowed down, and that seems due to how labels are dynamically updated in Nasal space - we should probably extend label properties to optionally be based on on an sprintf-style string, and a list of properties to be read, and handle updates directly in C++ space rather than in Nasal space. Also, it might make sense to only update visible items? (for now, it's a really good stress test!)
** there seems to be a rather serious memory leak when using the Canvas GUI subsystem: the number of refs/objs and the size of Nasal memory pools never reduces upon closing said dialogs/windows (unlike PUI!), this applies to any Canvas GUI dialog/window, including tooltips
* Introduce meta information at the PropertyList/XML level to be able to version dialogs, for future changes to the underlying format
* Clean up the existing UI:
** especially the introduction of submenu support will make it possible to declutter the menubar (debug menu etc) {{Not done}}
** furthermore, introducing proper {{tag|tab}} support will make it possible to simplify a few existing dialogs {{Not done}}
* Optimizing and simplifying existing dialogs by introducing new layouting/widget primitives {{Not done}}

== Widgets ==

The majority of missing widgets can be implemented/approximated by using existing ones or adapting/extending those as needed. To get started with widget development, it's a good idea to look at some of the really simple ones first, and then take it from there - for instance, the Label widget is a comparatively simple widget:

{| class="wikitable"
! Status !!PUI widget {{Flightgear source|src/GUI/FGPUIDialog.cxx|line=882}} !! Complexity (0-10) !! Priority !! Canvas widget !! Remarks
|-
| {{Done}} || {{tag|frame}} || 1 || not critical || {{Canvas Widget|widget=Frame}} || see {{Fgdata commit|459dea77e5ceac592d0d5d58a059ccad1fce6daa}}
|-
| {{Done}} || {{tag|hrule}}/{{tag|vrule}}|| 1 || not critical || {{Canvas Widget|widget=Rule}} || {{Fgdata commit|459dea77e5ceac592d0d5d58a059ccad1fce6daa}}
|-
| {{Done}} || {{tag|list}} || 5|| high || {{Canvas Widget|widget=List}} || list, combo and select should probably be tackled together, there's plenty of common/similar functionality - these could all be based on the same superclass internally, which should probably be structured so that specific list types (airport list, property list, waypoint list, log list) can be implemented on top of the existing list widget.
|-
| {{Not done}} || {{tag|airport-list}} || 5|| || {{N/a|Not implemented}} ||trivial using navdb APIs and ScrollArea with buttons/labels for each entry and a corresponding event handler [[Howto:Processing_legacy_PUI_dialogs_using_Canvas#Use_Case:_airports.xml]]
|-
| {{Done}} || {{tag|property-list}} || 5|| || {{N/a|Not implemented}} || [[Property Browser]], [[Howto:Processing_legacy_PUI_dialogs_using_Canvas#Coming_up_with_a_property-list|rough prototype]] exists already, basically mapping 3 props.nas APIs to a ScrollArea with buttons for each property/node, allowing the tree to be travsersed interactively. Could be also implemented by using text labels and ASCII art, analogous to [[Nasal_Browser]] or using the new ListView widget
|-
| {{Not done}} || {{tag|waypointlist}} || 6|| || {{N/a|Not implemented}} || trivial using navdb APIs and ScrollArea with buttons
|-
| {{Not done}} || {{tag|loglist}} || 4|| || {{N/a|Not implemented}} || needs [[SG_LOG]] logstream exposed via [[Nasal/CppBind]]
|-
| {{Done}} || {{tag|input}} || 3 || || {{fgdata file|Nasal/canvas/gui/widgets/LineEdit.nas|t=LineEdit}} ||
|-
| {{Done}} || {{tag|text}} || 6|| || {{fgdata file|Nasal/canvas/gui/widgets/Label.nas|t=Label}} ||
|-
| {{Done}} || {{tag|checkbox}} || 4|| || {{fgdata file|Nasal/canvas/gui/widgets/Checkbox.nas|t=Checkbox}} ||
|-
| {{Done}} || {{tag|radio}} || 2|| || {{Canvas Widget|widget=RadioButton}} ||
|-
| {{Done}} || {{tag|button}} || 2|| || {{fgdata file|Nasal/canvas/gui/widgets/Button.nas|t=Button}} ||
|-
| {{Not done}} || {{tag|canvas}} || 4|| || should be implemented prior to {{tag|map}} || While we don't necessarily need a proper canvas widget, we need to map the PUI widget to a corresponding equivalent, i.e. an embedded Canvas with its own scripting block to animate the whole thing. The original pui2canvas parser simply set up an embedded Canvas via a Label with the raster image set up to show the Canvas instead: [[Howto:Processing_legacy_PUI_dialogs_using_Canvas#Embedded_Canvas]]
|-
| {{Not done}} || {{tag|map}} || 5|| || should honor the original property interface, and be based on the {{tag|canvas}} widget {{N/a|Not implemented, see also [[Canvas MapStructure]]}} || {{Progressbar|20}} [[Howto:Creating_a_Canvas_GUI_Widget#Implementing_a_Map_widget]]
|-
| {{Done}} || {{tag|combo}} || 6|| || {{N/a|Not implemented}} || list, combo and select can be unified
|-
| {{Not done}} || {{tag|select}} || 7|| {{N/a|Not implemented}} ||list, combo and select can be unified
|-
| {{Done}} || {{tag|slider}} || 4|| || {{fgdata file|Nasal/canvas/gui/widgets/Slider.nas|t=Slider}} ||
|-
| {{Done}} || {{tag|dial}} || 3|| || {{fgdata file|Nasal/canvas/gui/widgets/Dial.nas|t=Dial}} ||
|-
| {{Done}} || {{tag|textbox}} || 6|| || {{fgdata file|Nasal/canvas/gui/widgets/LineEdit.nas|t=LineEdit}} and/or {{fgdata file|Nasal/canvas/gui/widgets/Label.nas|t=Label}} ||
|}

== Menubar ==

Furthermore, we need to replace the [[Menubar]] itself, which is also implemented via PUI - for that purpose, there are some special widgets needed:
{| class="wikitable"
! Status || Complexity (0-10) !! Priority !! Canvas widget !! Remarks
|-
| {{Done}} || 3 || 10 || {{Canvas Widget|widget=MenuBar}} || see {{Fgdata commit|459dea77e5ceac592d0d5d58a059ccad1fce6daa}}
|-
| {{Done}} || 3 || 10 || {{Canvas Widget|widget=PopupMenu}} || see {{Merge-request|project=fgdata|id=305|text=Merge request:Implement canvas menus}}
see {{Fgdata commit|459dea77e5ceac592d0d5d58a059ccad1fce6daa}} <ref>https://sourceforge.net/p/flightgear/mailman/message/37756296/</ref><ref>https://sourceforge.net/p/flightgear/mailman/message/37756390/</ref><ref>https://sourceforge.net/p/flightgear/mailman/message/37756347/</ref>

|-
| {{Done}}|| 3 || 10 || {{Canvas Widget|widget=MenuItem}} || the design goal of MenuItem is to allow both simple items (text) but also check-ables ones, and in the future, simple widgets to be inside an item (eg, a slider or +/- controls in a menu item, or a multi-state selector of a few choices)

So, the aim was to have a constructor taking either a text string, or a callback which creates the widget content on demand (when the menu is shown)
<ref>https://sourceforge.net/p/flightgear/mailman/message/37756408/</ref> It's using an
item-orientated approach, and the menu has an addItem method to add an
arbitrary widget (in most cases this will be a MenuItem instance, but you
could use a slider just as well) and a createItem method that takes a text
and a callback and an optional icon, from which a new MenuItem is created.<ref>https://sourceforge.net/p/flightgear/mailman/message/37756436/</ref>
|-
| {{Done}}|| || 10 || {{Canvas Widget|widget=Menu}} || see {{Fgdata commit|459dea77e5ceac592d0d5d58a059ccad1fce6daa}}
|-
|}

In addition, there are some Canvas specific widgets that are not currently supported by PUI:

{| class="wikitable"
! Complexity (0-10) !! Priority !! Canvas widget !! Remarks
|-
| 6 || || {{fgdata file|Nasal/canvas/gui/widgets/ScrollArea.nas|t=ScrollArea}} || serves as the generic building block for any PUI list-type (waypoints/airports) with labels/buttons added for each entry shown
|-
| 4|| || {{fgdata file|Nasal/canvas/gui/widgets/TabWidget.nas|t=TabWidget}} || A [https://sourceforge.net/p/flightgear/mailman/message/37754597/ tab widget] as everyone knows it from their web browsr (pending review as of 12/2022 see {{Merge-request|project=fgdata|id=303|text=Merge request:Canvas tab widget implementation}})
|}

== General Improvements ==
With the new GUI system (!!) we could even do a mode which opens the property inspector at a particular branch of the property tree, and have a an option that reads "manually select loading settings [click here to edit values]"
… to keep the power tweakers happy without having a custom dialog box for every set of properties. (We do need to ensure they get auto-saved though, for this UI flow to be non-annoying) <ref>https://sourceforge.net/p/flightgear/mailman/message/37771124/</ref>

And that is something that we talked about and actually previously experimented with with Florent when the Addon system was being developed: There are some things in fgfs that don't really have a proper "config dialog" (yet) - but the property tree holds almost sufficient information to procedurally create a corresponding UI merely by doing a <code>foreach(var node; tree)</code> and by traversing a node to procedurally build a simple UI.

Having some sort of "overlay mode" for property-based dialogs would seem like a straightforward thing to do - we can easily support 3-5 optional attributes per node, and even recognize those dynamically inside the property browser, to provide this sort of "view" - and we could even register such nodes via a dedicated "hash" to make these available in a more direct fashion via the menubar.

The idea we had back then was to use optional XML/node attributes to add meta-info to such nodes, that way a "label" or "tooltip" attribute could be added, and even a "ui-type" node, so that such a loop could serve as a simple dialog builder for such annotated property nodes:

https://wiki.flightgear.org/Draw_masks
[[File:Draw-masks-via-canvas.png|thumb|FlightGear [[Draw masks]] GUI dialog procedurally created by the [[Canvas]] system.s]]

I guess you can see just how simple but powerful this idea is: as long as we add such meta information to certain properties, a simple loop could procedurally generate simple dialogs, without having to use separate files.

To prototype/test this sort of idea, we could use your tab widget inside the new property tree widget, and support a different sort of "view" for such nodes - basically like an "overlay", where such properties are dynamically interpreted to provide a simple UI without having to view/edit raw property values.

We could then annotate relevant property trees using optional attributes like:
* ui:label
* ui:tooltip
* ui:help (help string, could be shown via '?' button rendered next to each of these widgets)
* ui:type [toggle, checkbox, slider etc]
* ui:index (to influence in what order/manner such properties are mapped to widgets)
* ui:validate (to select applicable validation)

This sort of markup would make it very easy for fgdata/aircraft developers to create UIs without ever having to create a single dialog, just by providing sufficient meta information so that the Canvas GUI system could automatically create basic, but working, dialogs.

Imagine, a property tree node having optional attributes, e.g. along the lines of:
<syntaxhighlight language="xml">


<hostname type="string" ui:type="textbox" ui:label="Host name" ui:tooltip="enter a hostname" ui:validate:""/>
</syntaxhighlight>

We could then use a wrapper Class to map <code>props.Node</code> hierarchies to such dialogs using the equivalent of an <code>PropsOverlayBuilder</code> helper - the idea being to provide a UI overlay for nodes with rich meta info.

This sort of approach would also allow us to easily configure whether we want these settings to be stored with the userarchive flag set or not, or to save/load custom defaults via $FG_HOME/Export

== Styling ==
Fahim was also working on an alternate style since James wants to ensure we have correct model-view separation between the core widgets (which is the public API) and the style code that builds the visual appearance.

In general, help with making the styling parts is the piece I am slowest with though, so any help, especially creating border-images (scale9) that work as the backgrounds / frames for the various elements would be lovely.<ref>https://sourceforge.net/p/flightgear/mailman/message/37718562/</ref>

<ref>https://sourceforge.net/p/flightgear/mailman/message/37756178/</ref>

We need to figure out the split of DefaultStyle.nas, but James is very keen to ensure we add a second style alongside the default, before we change much here.

Regarding styling, James is worried about us ending up putting code into the wrong side of the widget / Style split, if we don’t have a second alternative style implementation to ‘keep us honest’<ref>https://sourceforge.net/p/flightgear/mailman/message/37756178/</ref>

We really have two kinds of ’styles’

* tweaking margins, font sizes, colours etc should indeed be done in XML as you wrote : this is also analogous to styles in the PUI sense

* making radically different ways of presenting the same logical widgets: eg text label of checkbox in a different position relative to the button (of Surface vs Material vs iOS style, if you know web/mobile UIs)

For the second kind we would use a different Nasal style implementation and that’s the abstraction James thinks it is very important to maintain.

It of course going to be a lot of work to make additional styles this way but it’s a very valuable feature to keep the possiblity, since it enables alternate UIs for user accessibility or different presentation modes such as VR.

What James doesn't want to do is add lots of widgets assuming we only care about DefaultStyle.nas, and then have an impossible mountain to climb when someone needs an alternate Nasal style. We don’t have to make a complete alternate style now, but I don’t want to take shortcuts the make it impossible in the future. So James wants to really think carefully about what is widget code and what is style code. <ref>https://sourceforge.net/p/flightgear/mailman/message/37756261/</ref>

Also, it is worth nothing that treating DefaultStyle.nas that way, is a straightforward mechanism to allow aircraft developers to customize their own styling for all sort of MFD purposes, without having to create complete widget sets from scratch - this is how Tom originally designed the whole thing, for his C130J.

== Widget Validation ==
At some point in the future, we may want to introduce support for optional constraints/restrictions for certain types of widgets (think headings/bearings/courses, frequencies, latitude/longitude, date/time, navaids, airports, file path, property path, metar string etc):

Things like password entry mode, restrictions on permitted characters (eg onl allowing numbers or an IP address), max number of characters entered, etc would all be config options as we add those kind of things gradually. That’s why I like it as an API: it avoids an explosion of setters for rarely used things, and it can be passed into the Style implementation ‘as is’ without each possible option needing to be explicitly handed over.<ref>https://sourceforge.net/p/flightgear/mailman/message/37765245/</ref>

== Cleaning up dialogs ==

Once the PUI/XML widget set is fully supported by the XMLDialog parser, it will make sense to review existing dialogs to identify opportunities to introduce new widgets and simplify existing dialogs.
As a matter of fact, a number of PUI/XML dialogs are currently working around PUI limitations by using awkward hacks to implement custom widgets. These show up by making excessive use of Nasal blobs as well as usage of the cmdarg() API, and they're a pain to maintain:

{{collapsible script
| title = PUI/XML dialogs making excessive use of embedded Nasal
| script =
* $FG_ROOT/gui/dialogs/airports.xml Total Nasal LOC: 415
* $FG_ROOT/gui/dialogs/advanced-graphics-options.xml Total Nasal LOC: 413
* $FG_ROOT/gui/dialogs/checklist.xml Total Nasal LOC: 399
* $FG_ROOT/gui/dialogs/weather.xml Total Nasal LOC: 298
* $FG_ROOT/gui/dialogs/chat-menu.xml Total Nasal LOC: 297
* $FG_ROOT/gui/dialogs/static-lod.xml Total Nasal LOC: 270
* $FG_ROOT/gui/dialogs/route-manager.xml Total Nasal LOC: 263
* $FG_ROOT/gui/dialogs/map-canvas.xml Total Nasal LOC: 188
* $FG_ROOT/gui/dialogs/file-select.xml Total Nasal LOC: 161
* $FG_ROOT/gui/dialogs/joystick-config.xml Total Nasal LOC: 159
* $FG_ROOT/gui/dialogs/location-in-air.xml Total Nasal LOC: 153
* $FG_ROOT/gui/dialogs/gps.xml Total Nasal LOC: 138
* $FG_ROOT/gui/dialogs/nasal-console.xml Total Nasal LOC: 132
* $FG_ROOT/gui/dialogs/button-config.xml Total Nasal LOC: 124
* $FG_ROOT/gui/dialogs/property-browser.xml Total Nasal LOC: 121
* $FG_ROOT/gui/dialogs/replay.xml Total Nasal LOC: 115
* $FG_ROOT/gui/dialogs/marker-adjust.xml Total Nasal LOC: 105
* $FG_ROOT/gui/dialogs/jetways-adjust.xml Total Nasal LOC: 103
* $FG_ROOT/gui/dialogs/multiplayer.xml Total Nasal LOC: 98
* $FG_ROOT/gui/dialogs/autopilot.xml Total Nasal LOC: 97
* $FG_ROOT/gui/dialogs/flight-recorder-load.xml Total Nasal LOC: 89
* $FG_ROOT/gui/dialogs/fgcom.xml Total Nasal LOC: 85
}}

== Introducing new Widgets ==
There is great scope to make /better/ Nasal APIs for items such as combo-boxes and pickers, especially ICAO and radio frequency pickers, but that's all 'improving the GUI' work than can happen once we've ditched PLIB and have something hackable.<ref>https://sourceforge.net/p/flightgear/mailman/message/29583931/</ref>

It's been repeatedly pointed out by a number of contributors, that the sheer amount of Nasal blobs embedded in PUI/XML dialogs is making UI development quite a hassle (especially those outside bindings, i.e. inside open/close blocks and the canvas load equivalent). Thus, it will make sense to review which new widgets could be introduced to get rid of these Nasal blobs:

{| class="wikitable"
! Status || Complexity (0-10) !! Priority !! Canvas widget !! Remarks
|-
| {{Not done}} || 4|| low || AirportView || this would help simplify airports.xml
|-
| {{Not done}} || 4|| low || ChecklistWidget || this would help simplify checklists.xml
|-
| {{Not done}} || 4|| low || PilotList || pilot list dialog
|-
| {{Not done}} || 4|| low || SubsystemList || performance monitor
|}

== Meta info for dialogs ==

These changes will also simplify development of the Phi/mongoose based UI, because we would be introducting dedicated widgets, which could just as well be implemented in JavaScript. However, for these changes to be introduced, we need to make some additions to the PropertyList/XML format used by GUI/XML files, namely:

* introducing a version attribute for the {{tag|PropertyList}} root
* introducing a {{tag|FileType}} node to specify that the file is a GUI/XML description: <code><FileType>GUI</FileType></code>
* introducing a {{tag|version}} node to be able to make breaking changes in the future

This way, we can easily update widgets/layouting primitives or introduce new ones, without having to be concerned about existing UI resources.

For instance, here's $FG_ROOT/gui/dialogs/scenery_loaded.xml with additional meta information, so that we can safely make changes in the future:
<syntaxhighlight lang="xml">
<?xml version="1.0"?>
<PropertyList version="1.0">
<FileType>GUIResource</FileType>
<version>1.0</version>
<name>scenery_loading</name>
<layout>vbox</layout>
<modal>true</modal>
<text>
<label>Scenery Loading...</label>
<padding>30</padding>
</text>
</PropertyList>

</syntaxhighlight>

== Reusability ==
Once our existing PUI widgets and dialogs are fully emulated, and dialogs have become better optimized (=less Nasal blobs). It will be a good idea to revisit some concerns and ideas expressed by Torsten D. based on his experience creating Phi:

Torsten once stated rightly that it would be benefical for any new UI to separate the logic included in most dialogs from the presentation anyway to make it reusable.
His vision was to have some kind of service implemented in FlightGear that wraps all complex tasks into service calls and responses. The command system is a
good start to trigger something, but it does not yet return anything.

Currently, all dialogs are a mixture of calling fg-commands and setting properties directly.

Phi already has some basic support for aircraft specific elements. <ref>https://sourceforge.net/p/flightgear/mailman/message/34532860/</ref>

We should discuss and prototype a new type of asynchronous fgcommand layer that may also return properties/values, this could benefit both: The Canvas UI, but also Phi. In the future, Canvas UI dialogs may thus also use these same fgcommands which would be running asynchronously (possibly over the same/existing non-blocking HTTP back-end already used by Phi).

At that point it will become increasingly feasible to also provide a module for Phi to interpret these new PUI/XML dialogs, because these would be primarily XML-based, should contain zero (or very little) code. And the new could be that Nasal code that still needs to stay inside such dialogs, will always need to be registered with the SGCommandMgr via the addCommand() API - that way, both front-ends would be able to interpret/execute such dialogs, which would mean that aircraft developers would not need to port/maintain two different sets of dialogs to support both front-ends.

Also, future updates to the UI will become tremendously easier once our dialogs are purely declarative/XML.

{{Appendix}}

PUI

2023-10-02T06:26:46Z

Hooray: /* Status */ https://sourceforge.net/p/flightgear/mailman/message/37881226/

{{Feature to be removed|version=2023.3|reason=[[Plib]]/PUI is to be removed and replaced by a [[Canvas widget matrix|Canvas/Nasal based solution]] to help improve compatibility with [[OSG]] 3.6+ and [[OpenGL]] 4.x ([[Core Profile support|OpenGL Core Profile]], see [[2022.X Release plan]] ) and improve performance by [[Unifying the 2D rendering backend via canvas|phasing out legacy OpenGL code]]. Therefore, people should be careful when extending the '''PUI''' based legacy GUI engine<ref>https://sourceforge.net/p/flightgear/mailman/message/34921495/</ref><ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35157325/
|title = <nowiki> Re: [Flightgear-devel] GUI options (Was: Aircraft center) </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jun 14th, 2016
|added = Jun 14th, 2016
|script_version = 0.40
}}</ref> and coordinate any related work with the devel mailing list first-this applies particularly to adding any [[Template:PUI_widget|additional hard-coded PUI widgets]]. }}
[[File:Exit.png|thumb|FlightGear GUI dialog (exit.xml)stored in $FG_ROOT/gui/dialogs]]
{{GUI Navbar}}

[[File:Custom-autopilot-dialog.png|right|200px]]
[[PUI]] is the standard GUI engine used in FlightGear, it is part of [[PLIB]] and is using raw, fixed-pipeline, [[OpenGL]] code internally (no [[OpenSceneGraph]]). As of mid 2021, FlightGear is in the process of working towards adopting the OpenGL Core Profile, this means that [[PUI]] is causing trouble and needs to be replaced/disabled or ported.

PUI provides a fairly basic, but robust, set of widgets. PUI is also used for rendering the [[Menubar]].

FlightGear uses a GUI widget set that is implemented on top of raw (legacy) [[OpenGL]]. This has many advantages from a portability standpoint and from the standpoint of integrating with window systems. [[PUI]] doesn't have every feature under the sun, but it was never meant to. It's relatively small, lean, mean, and written on top of [[OpenGL]] which makes life *much* easier for us.

[[PUI]] already is a separate distinct library within Plib. It depends on some central utility stuff, but that's about it. So it is pretty stripped down and separate already.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg26011.html</ref>

We are to some extent hamstrung by the rather old GUI toolkit we use. However, replacing that is going to be non-trivial, and it would affect not just the core GUI but also all the dialog boxes that have been set up for particular aircraft.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg25985.html</ref>

Flightgear can look amazing when you use the HDR pipeline. We absolutely need this to stay relevant. The problem is that HDR is not compatible with OpenGL1 PUI. Work on getting rid of PUI has been going on for over a decade (longer than it took to implement it).<ref>https://sourceforge.net/p/flightgear/mailman/message/37727346/</ref>

[[File:menubar2.jpg|517px]]

== Replacement status ==
{{See also|FlightGear_and_OpenGL_ES#Example:_disabling_PUI}}

{{Note| Update 09/2022: The PUI replacement [[QtQuick_use_in_FlightGear#Background|was going to be Qt]] but it started to get very complicated with changes in Qt 5.15 + Qt 6, so James is going with a more light-weight Canvas based approach now.

Qt added support for Vulkan / Metal / D3D starting in 5.15, but FlightGear / OpenSceneGraph can’t support those, so integrating the two renderers went from being ‘complicated but ok’ to ‘very very complicated’.

So now James is going with something much more lightweight using some C++ compatibility code, some Nasal for styling and the existing [[Canvas widgets|Canvas widget rendering]] from Thomas Geymayer (TheTom) with [[Canvas Widget Matrix|some extensions and additions]], based on the [[Howto:Processing_legacy_PUI_dialogs_using_Canvas#Original_Discussion|plans originally discussed when the Canvas GUI system was added to FlightGear]]: some pieces are in FlightGear & FGData already.

James has basic dialogs working okay but not the more complex ones and everything looks kind of ugly, he needs to improve the visual look before he shares screenshots to avoid everyone freaking out :) The disadvantage of this approach is James is far from expert at creating visual appearances this way, so it’s kind on unrewarding and slow for him. If someone likes messing with CSS-type styling, border-images and hover-states, ping him since we could probably move things also faster <ref>https://sourceforge.net/p/flightgear/mailman/message/37701750/</ref>}}

=== Motivation ===
{{Main article|Core Profile support}}

The bigger issue here is we need to ditch [[PUI]] (which is in progress) and some OpenGL 1.0 code (HUD, 2D panels especially - can be #ifdef for now) so we can enable Core profile on Mac - since Mac 4.x support (we only hit about 4.3 alas, but with some extensions to get in sight of 4.5) is Core profile only, no Compatability mode.

Improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, many people are convinced PUI needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

While most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so [using Qt5] would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

== Canvas Emulation ==
{{See also|Canvas widget matrix}}
'''Last updated: 04/2023 <ref>https://sourceforge.net/p/flightgear/mailman/message/37805054/</ref>
'''
=== Gallery ===

<gallery>
About-dialog-xmldialog-04-2023.png|about.xml PUI/XML dialog parsed/rendered via the [[Canvas GUI]] and the underlying XMLDialog.nas parser/translator (04-2023)
Logging-dialog-via-xmldialog-04-2023.png|logging.xml PUI/XML dialog parsed/rendered via the [[Canvas GUI]] and the underlying XMLDialog.nas parser/translator (04-2023)
Failures-dialog-via-xmldialog-04-2023.png|failures dialog-via-xmldialog-04-2023.png{{!}}thumb{{!}}logging.xml PUI/XML dialog parsed/rendered via the [[Canvas GUI]] and the underlying XMLDialog.nas parser/translator (04-2023)
Environment-dlg-via-canvas-bridge-04-2023.png|Screen shot showing the XMLDialog.nas bridge in use to parse/render the environment.xml PUI/XML dialog (unmodified)
</gallery>

=== Status ===
As of 01/2023, the replacement for PUI is making good progress<ref>https://sourceforge.net/p/flightgear/mailman/message/37765706/</ref>.

In February 2022, James reported having something in progress locally, and that should even be something we can try in March/April 2022. Hopefully that’s quick enough, knowing it has been a long time coming.<ref>https://sourceforge.net/p/flightgear/mailman/message/37606439/</ref>

There's now an XML to Nasal bridge, to keep PUI dialogs working (Disabled by a CMake option)
This is implemented on top of the [[Canvas]] system.

This builds equivalent C++ objects to what the [[PUI]] dialogs build, with properties exposed to Nasal.
Peer objects are created by Nasal [[callbacks]], which can implement the various dialog functions needed to keep compatibility, especially the [[#Background|‘update’ and ‘apply’ hooks]].<ref>https://sourceforge.net/p/flightgear/flightgear/ci/cbd5ef9e7b8f433dbc1ba97bae7d7cfc894e7cef/</ref>

For remaining work to be done, please refer to [https://sourceforge.net/p/flightgear/mailman/message/37881226/]

{{Note|The PUI Compatible Canvas GUI is a compile time option: Use the following [[Building using CMake|cmake option]] to enable this code: {{CMake Build Option|option=ENABLE_PUICOMPAT|default=ON|description=This requires latest SG/FG AND FGDATA}}. But this is all highly fluid and most of it really developer only. At one point they will become default or be accessible in the launcher.<ref>https://sourceforge.net/p/flightgear/mailman/message/37834004/</ref>

If you compiled with PUICompatibility enabled, but still don't see any dialogs - only the menubar, you might need to enable the GUI module in defaults.xml:{{PropArg}}<ref>https://sourceforge.net/p/flightgear/mailman/message/37833149/</ref>}}

The new Compatibility files can now be found in $FG_SRC/GUI:

* {{flightgear file|src/GUI/FGPUICompatDialog.cxx }}
* {{flightgear file|src/GUI/FGPUICompatDialog.hxx }}
* {{flightgear file|src/GUI/PUICompatObject.cxx }}

01/2023: James is slowly working on creating the pop-up menu and combo-box widgets [...]

One of the major things slowing down James' work on the popup-menu and combo box is time to restart the simulator for each change, he is looking for some solution to re-load the widget Nasal code independently. <ref><https://sourceforge.net/p/flightgear/mailman/message/37756183/</ref>

James has done about 75% (hah!) of the C++ work to enable live reloading of modules this way, but unfortunately there are some code paths that would become crashy if you use the feature for the Canvas: because it would reference the ‘old’ (pre-reload) Nasal code, and not the new one, and therefore you’d get a weird mix of old and new, and then just crash the sim. To fix it properly I need to track down those places that store a reference to Canvas and give them a re-init method, so we don’t keep the stale references.

The general non-fun-ness of that kind of debugging is James has been making such slow progress on my PUI replacement widgets recently <ref>https://sourceforge.net/p/flightgear/mailman/message/37756263/</ref>

=== Todo ===
Nothing in particular: help debugging the grid layout (which is in simgear) would be good. For now, you could create a grid layout manually using some Nasal.

For the menubar, we need to expose the C++ data to Nasal: we need a FGCompatMenuBar (alongisde FGPUIMenuBar) implementing FGMenubar which calls _createMenuObject in MenuBar.nas, using the same way I lookup and call _createDialogPeer in XMLDialog.nas

(Make sure you don’t break the macOS native menubar in the process!)

You can probably pass a wrapped SGpropertyNode into this, and then fill in the stubs in that file to use the Menu widgets Frederic has written.

Global menu keybindings won’t worry but don’t touch that, I have a separate plan for it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37805736/</ref>

As of 04/2023, remaining items on the todo list are: <ref>https://sourceforge.net/p/flightgear/mailman/message/37805060/</ref>

* Grid layout
** GridLayout needs debugged: After this, the basic UI is usable, would probably make it a switchable option on ‘next’ (I can already use the simulator with the new UI today, but all the sizes are off in the grid layouts which we use everywhere)

* list
* table (and tree ?) models corresponding views
* waypoint list
* Re-write the waypoint list and airport dialog to work again (since these use custom widgets):
** log list
** airport-list equivalents
* Nasal access to the menu i18n functions
* selection support for single- and multi-line text (which is being worked on -> CanvasPangoText)
* Keyboard shortcut handling, although this is not really a PUI vs replacement issue, to me we should handle UI shortcuts in the same was normal keyboard.xml shortcuts
** this previously worked because PUI got ‘first chance’ at handling key input. But we always had duplication between keyboard.xml and other places, so I would rather standardise on keyboard.xml, but allow a UI element to set a scope for shortcuts. (So that Copy/paste shortcuts etc can work in a text input, at least … but probably some other standard ones) <ref>https://sourceforge.net/p/flightgear/mailman/message/37805188/</ref>
* Ensure all the places which use the PUI combo-box and list-widget work : there’s a few of these.

The CanvasPangoText stuff is needed but we can perfectly well run the UI on next without it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37805176/</ref>

=== Parser ===
{{Main article|pui2canvas}}
The corresponding Nasal/Canvas module to dynamically "translate" legacy PUI/XML dialogs into Canvas dialogs (at runtime), is to be found in {{fgdata file|Nasal/gui/XMLDialog.nas}} <ref>https://sourceforge.net/p/flightgear/fgdata/ci/fe7c87b21a69f88ddb87d89453c48d12b69660e2/</ref>

=== Widgets ===
{{Main article|Howto:Creating a Canvas GUI Widget}}

It’s split between Simgear (see classes with widget / layout in the name) and in FGData. (Eg widgets/Button.nas) To be able to use the existing dialog XML files un-modified (which is a design goal), James is extending the widget types with many additional ones (eg PUI has slider, dial, combo-box, checkbox, all of which need to be created, see [[Canvas widget matrix]].

This is about 30% done and is the bit he's very slow at). Thomas’s canvas widgets have a very good separation of API + state from appearance, so all styling is in its own file, and James is being very strict about maintaining this separation, so we also retain the re-styling feature of the PUI UI, which many people also rely on. This does make the process of adding new widgets more complex, however.

{{See also|Canvas widgets}}

=== Layouting ===
The other thing is to preserve all the layouting: James has added a grid layout to Simgear, since that is supported by the existing PUI code (even though the layouts are not actually part of PUI itself). The problem is getting the sizing / hinting of all the widgets to match the PUI values, so that dialogs look approximately the same under the new UI as they did with PUI; again this a design goal so that all existing dialogs in aircraft and add-ons, which we can’t update, continue to work and be usable. Debugging that is also proving quite tricky, since there’s all kinds of hard-coded assumptions built into PUI widgets about pixels, font-sizes etc which are not true in the new system.<ref>https://sourceforge.net/p/flightgear/mailman/message/37701792/</ref>

== Background ==
In FlightGear, PUI dialogs are standard [[PropertyList XML File]]s that are stored in $FG_ROOT/gui/dialogs, they can contain the widgets mentioned in {{readme file|gui}}, using a simple layout engine discussed in {{readme file|layout}}, and bindings using a combination of so called fgcommands operating on properties (see {{readme file|commands}}) and custom [[Nasal]] (FlightGear scripting) code.

In addition, each PUI/XML dialog may contain Nasal script sections that are executed when opening/closing the dialog, a feature which is commonly used for procedurally creating/updating widgets using the [[Nasal_library#cmdarg.28.29|cmdarg() API]], which allows the dialog tree to be traversed and manipulated prior to the dialog being rendered.
Widgets can be conditionally hidden/shown using a wrapper for [[Conditions|SGCondition]] in [[Nasal_library/props|props.nas]]
The <code>canvas</code> widget also supports its own embedded Nasal code section to execute arbitrary widget specific Nasal code upon opening/closing the dialog/widget.

PUI/XML dialogs can be loaded, dynamically created, updated and closed using a handful of fgcommands:
* {{fgcommand|dialog-new}}
* {{fgcommand|dialog-show}}
* {{fgcommand|dialog-update}}
* {{fgcommand|dialog-apply}}
* {{fgcommand|dialog-close}}

PUI related OpenGL code is particularly infamous for causing rendering artifacts for people on AMD/ATI and Intel hardware (especially in combination with certain fonts/styles and [[Effects|effects]]/[[Shaders|shaders]]), see {{Issue|2213}}.

PUI is also known to affect rendering performance quite significantly (see {{search |keywords=anthrax+gui}}), while also preventing FlightGear from using a more recent version of OpenGL<ref>http://sourceforge.net/p/flightgear/mailman/message/34532040/</ref><ref>http://forum.flightgear.org/viewtopic.php?f=71&t=24046</ref>.

However, improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Besides, while most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

But given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, graphics folks are also convinced it needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

In addition, [[OpenSceneGraph]] (OSG) can obviously not help optimize any PUI related GL code and PUI widgets are generally considered to be pretty archaic and not easy to extend<ref>http://sourceforge.net/p/flightgear/mailman/message/26832164/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587120/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587272/</ref>.

{{Note|We use the GUI code from PLIB, which doesn't know anything about OSG. See the SGPuDrawable class in $FG_SRC/Viewer/renderer.cxx for the implementation. The one catch is that OSG has a strong notion of separation between the update of a "scene" and its rendering, and that might not play well with arbitrary existing OpenGL code. }}

As of late 2015, there is heavy activity towards providing alternatives to a PUI-based UI:
* [[Integrated Web GUI]] (external, browser-based - fully asynchronous)
* [[Howto:Processing legacy PUI dialogs using Canvas]] (internal, using the [[Canvas]] system and a simple [[Nasal]] parser to deal with existing PUI/XML dialogs)

<gallery mode="packed">
Early-Phi-screen shot.PNG|Screenshot showing [[Phi]]
About-dialog-rendered-by-canvas.png|Screenshot showing a dialog rendered by the [[Howto:Processing legacy PUI dialogs using Canvas|pui2canvas parser]]
</gallery>

== History ==
{{See also|QtQuick use in FlightGear}}
{{Caution|This is merely kept for future reference, many of the ideas discussed below have become obsolete as of 09/2022, if in doubt, please get in touch via devel-list.}}
=== 2021 ===
In early 2021, James did a brief evaluation of [https://github.com/ocornut/imgui ImGUI] as a possibility - he's also evaluating it in some projects at his day job.

The API is interesting if you’re starting from scratch and only exclusively in C++, but it’s not a great fit for how we define GUIs in FG (via [[XML]]/[[Nasal]]): there is no back door that he could find, to access the persistent state of the GUI, or build it up in a data-driven way. So making a mapping to keep our existing GUI XML working (and updating correctly) becomes a bit of a chore.<ref>https://sourceforge.net/p/flightgear/mailman/message/37295586/</ref>

Pretty much all of the FlightGear GUI is defined in XML space, except for a few oddments. Let’s say 95% at this point.

Additionally, even if we were to change that for the core sim (and James' current plan is to keep the XML syntax and just extend it), the installed base of '''aircraft''' ship their own XML dialogs (eg., replacing the autopilot dialog with a custom one, or just adding their own aircraft-specific helper controls for doors / lights / cargo / whatever). So even if we found the most sublimely beautiful, intuitive, compact GUI description language in the world, we have to keep the XML syntax working as-is, for the foreseeable future.

Given this, James' intention is to replace the output side [[PUI]] but keep the front-end side (XML / properties / bindings) unchanged, and therefore backwards compatible, and simply add some new types / options / widget types going forward. This will mean we still have to deal with the slightly cumbersome XML+Nasal syntax, but, well, it’s not *that* cumbersome. <ref>https://sourceforge.net/p/flightgear/mailman/message/37296280/</ref>

In mid 2021, James reported that he is working on some ‘PUICompat’ classes which hold/own/represent the GUI state in C++, but which can be used with [[Nasal/CppBind|Nasal CppBind]]. And of course we could indeed expose those later on. <ref>https://sourceforge.net/p/flightgear/mailman/message/37297727/</ref>

In July 2021, James suggested not to worry about the existing GUI code, it’s going in the bin.<ref>https://sourceforge.net/p/flightgear/mailman/message/37325905/</ref>

For the time being, the in-sim GUi can’t do Unicode yet, but James is working on it, hopefully available soon.<ref>https://sourceforge.net/p/flightgear/mailman/message/37328200/</ref>
Also, the in-sim menubar will change with the new GUI, *and* we use a native menubar on macOS. Until James replaces the PUI fonts we can’t use Unicode symbols. So, will have to come back to it once the new GUI is merged.<ref>https://sourceforge.net/p/flightgear/mailman/message/37327237/</ref>

=== 2020 ===
As of 03/2020, the PLIB replacement was reported to be in the backlog <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36951255/
|title = <nowiki>Re: [Flightgear-devel] C++ and/or OSG question </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Mar 18th, 2020
|added = Mar 18th, 2020
|script_version = 0.50
}}</ref>.

With PLIB replacement work likely being re-scheduled for [[Post FlightGear 2020.2 LTS changes]] <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36985375/
|title = <nowiki>Re: [Flightgear-devel] Working Group Proposal - Boost and PLIB replacement - Delegation and Teamwork </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = April 18th, 2020
|added = April 18th, 2020
|script_version = 1.10
}}</ref>.

In 08/2020, James stated that he was still working (exceptionally slowly!) on replacing PUI (as part of removing legacy OpenGL code (PUI, HUD, 2d panels, porting Canvas away form ShivaVG), so we can switch to Vulkan/VSG at some point (ideally at some point before Apple turn off OpenGL support…)), and that he doesn't think /any/ of us *want* to be working on these features particularly, but projects like these need to be done before anyone can have fun with VSG or Vulkan (personally James would be very enthusiastic about working on VSG support (being on macOS, I also have the most to lose / gain from it)). Sometimes that’s just how it goes. Equally they will all benefit the project ultimately, but the payoff both for the individual and the project is very drawn out. <ref>https://sourceforge.net/p/flightgear/mailman/message/37077158/</ref>

In 10/2020, the estimation is that PUI should be going away really ‘soon’, the replacement code is already in next / 2020.2. (There’s no plan to actually /use/ the new UI code in 2020.2, but if the bugs in it prove simple, we could actually turn it for specific dialog: it seems very unlikely this makes sense for a stable release however)<ref>https://sourceforge.net/p/flightgear/mailman/message/37123818/</ref>

The fixed-function removal, is actively in hand (Gaetan is working on the 2D panel part, and James is going to focus on PUI in the rest of 2020). James hopes that means next year he can focus on Vulkan, or at least, using OSG as if /were/ VSG, so the migration in a year or two when VSG is stable, is not so painful.<ref>https://sourceforge.net/p/flightgear/mailman/message/37129098/</ref>

The PUI UI and replacement can co-exist in the same build (they already do, effectively.<ref>https://sourceforge.net/p/flightgear/mailman/message/37131297/</ref>

In 11/2020, James suggested not to worry about details such as PUI styling/theming etc: we’re not making such changes for the LTS, and PUI should be gone before the next release.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142225/</ref> Also, he recommended (to everyone) to stop touching GUI stuff for a few weeks, as he's about to turn it all on its head.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142356/</ref>

=== 2019 ===
The new GUI has been incubating for a few years, but there's apparently been a lot of progress as of 10/2019.

It is likely the new GUI will be a user opt-in feature - at least initially. The sunset of the PLIB library _could_ happen relatively soon, but
people will need to see the new GUI and react to it before we could commit to PLIB removal <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36784489/
|title = <nowiki>Re: [Flightgear-devel] in Flightgear/Simgear C++ Code: What needs Doing? What are YOU Doing? What would you do if you had the time? </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Oct 14th, 2019
|added = Oct 14th, 2019
|script_version = 0.50
}}</ref>.

In 02/2019, James stated that the new UI is coming quite soon. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36589420/
|title = <nowiki> Re: [Flightgear-devel] Lagging </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Feb 17th, 2019
|added = Feb 17th, 2019
|script_version = 0.40
}}</ref>

=== 2018 ===
{{See also|QtQuick use in FlightGear}}

According to James, we have to accept that changes like testing or making [[PUI]] a modular thing or moving the JS code tend to have an immediate pain for some people (because strange stuff gets broken, and takes some time to get fixed), whereas the payoff in terms of improved joystick handling or replacing the UI or testing of all subsystems will take some months or years to be felt.<ref>https://sourceforge.net/p/flightgear/mailman/message/36323240/</ref>

James said he was in the middle of porting the launcher’s final tab (location) to the new UI scheme, once that’s done he will start sketching out the ‘in sim’ settings UI using the same pieces. He’ll send a request for contributions around about that in the next three-four weeks, once he has enough templates & examples that there is a clear pattern to follow.<ref>https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/2d10f16c-ddc8-07f3-07e7-eca2a0a0d55f%40zaretto.com/#msg36293586</ref>

James announced that the launcher is now feature complete with the QtQuick UI, he’ll keep making bug-fixes of course as people report them, but my todo list for the core features is now done<ref>https://sourceforge.net/p/flightgear/mailman/message/36355833/</ref>.

=== 2017 ===

In 10/2017, James said he was getting really close to having the PUI replacement UI suitable for beta-testing.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36067646/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 7th, 2017
|added = Oct 7th, 2017
|script_version = 0.40
}}</ref>

Originally, James was hoping to land the PUI replacement GUI in the last dev cycle in 2017 (at least as a proof-of-concept, probably not as the default UI), so wouldn’t expend lots of effort on things like collapsible sections which might be a lot of work with the current PUI/Canvas approaches, but are trivial with the new [[QtQuick use in FlightGear|QtQuick based UI scheme]].<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36059822/
|title = <nowiki> Re: [Flightgear-devel] Canvas MapLayer for OpenStreetMap, OpenAIP,
VFR Sectionals </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 1st, 2017
|added = Oct 1st, 2017
|script_version = 0.40
}}</ref>

Once the basic new UI is in place we can experiment with different re-arrangements easily, without being limited by PUI. (James expects PUI to live on as the default / alternate UI while this happens)<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36061229/
|title = <nowiki> Re: [Flightgear-devel] FGFS macOS Menubar </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 2nd, 2017
|added = Oct 2nd, 2017
|script_version = 0.40
}}</ref>

Technically, this entails replacing dialog.cxx with some code which builds up some special ‘PUI-Emulation’ QtQuick controls, so that existing dialogs (especially from Aircraft) continue to work. This mode will look somewhat ugly but hopefully no more ugly than PUI! And it helps that the set of widgets we have in PUI is limited, and the ‘tricky’ widgets (map, scrolling list, etc) are in the dialogs will will replace with new ones first.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068767/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

This PUI emulation isn't going to use any code from PLIB<ref>https://sourceforge.net/p/flightgear/mailman/message/36985303/</ref>, so what will remain from it in FG afterwards will be the FNT and JS components (reworked).<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068817/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> Florent Rougon </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

=== 2016 ===
We need to explore if Qt Quick or widgets is the better way to go, with a preference towards Qt Quick, since it will allow things closer to current PUI (semi-transparent widgets on top of the 3D content). It still allows creating separate windows too (Erik’s use case), but means we get consistent, custom theming on all platforms, since standard desktop look is not so nice for a flight-sim.

James intention is to make a QML-hosting OSG-drawable, and add this as a concept in Qt-enabled builds, then port some PUI dialogs to it, and see how easy / painful the process is. Hell create some QObjects which expose commands and the property tree and Nasal.

This has the advantage of not touching the OSG window at all, QtQuick simply provides some additional OpenGL rendering on top, which we pass events to - pretty much exactly the same as what we already do for PUI, and hopefully can co-exist with it. James got this working in a local OSG tree in a standalone demo, but that’s based on osgQt - he wants to see if he can make it work on a normal, non-Qt OSG window inside FlightGear.<ref>https://sourceforge.net/p/flightgear/mailman/message/35156051/</ref>

The idea is to host an XML dialog (Currently done with PUI) from Qt also. The question is if that can be done keeping ‘source compatibility’ exactly with the current UI XML and Nasal interface. It probably can be, but many of the PUI widgets have really ugly APIs, especially for combo-boxes, drop-down menus and scrolling lists, where it makes sense to map a Nasal class to a Qt ItemModel, which would be more elegant and easy to work with in both Nasal and integrate on the Qt side. But obviously would mean changing the dialog sources.

Of course, aircraft dialogs tend to be simpler, and not use the more complex PUI widgets, precisely for reasons like this, but that’s a limitation it would be best to remove.<ref>https://sourceforge.net/p/flightgear/mailman/message/35155721/</ref>


== References ==
{{Appendix}}

[[Category:PUI| ]]
[[Category:Rendering roadblocks]]

HDR Pipeline

2023-10-02T06:24:52Z

Hooray: /* Background */

{{forum|47|Effects & Shaders}}

{{infobox subsystem
|image = HDR pipeline c172p over TFFF.png
|name = HDR Pipeline
|started = 04/2021
|description = A modern rendering pipeline that targets relatively powerful systems
|status = In development
|developers = Fernando García Liñán <ref>https://sourceforge.net/u/fgarlin/profile/</ref>
|changelog = https://sourceforge.net/u/fgarlin/profile/feed.rss
|folders =
* {{fgdata file|Compositor/HDR}}
* {{fgdata file|Effects/HDR}}
* {{fgdata file|Shaders/HDR}}
}}

{{Rendering}}

The '''HDR Pipeline''' is a [[Compositor]]-based rendering pipeline that attempts to bring modern rendering techniques to FlightGear, namely {{wikipedia|High dynamic range|high dynamic range (HDR)}} and {{wikipedia|Physically based rendering|physically based rendering (PBR)}}. It is implemented entirely in [[$FG_ROOT]] using XML for the Compositor pipeline definition and [[Effects]], and GLSL for shaders. The pipeline can be enabled with the command line argument <code>--compositor=Compositor/HDR/hdr</code>.

== Background ==

The [[Classic Pipeline]] relies on legacy [[OpenGL]] features, so rather than improving or reworking it, the idea of creating an entirely separate rendering pipeline from scratch started taking shape. The [[Compositor]] played the biggest role in enabling this effort as it allows the creation of new rendering pipelines entirely in FGData space without any C++ changes whatsoever, greatly reducing the amount of work that had to be done and making the iterative process of testing and debugging much faster.

== Status ==
'''Last updated: 10/2023'''

The HDR pipeline is more or less stable, and is currently available on <tt>next</tt> for anyone adventurous enough to try it. The main issue is that built-in legacy GUI ([[PUI]]) is not compatible because it uses old OpenGL code, so there is no in-sim GUI:


# The GUI camera does not render anything (neither PUI nor Canvas). This is caused by OSG's attribute aliasing being enabled in HDR. Fernando suspect sthe solution might have to do with forcing the GUI camera to use shaders instead of the fixed-pipeline. He hasn't delved too deep into this yet because there are many possible places to "inject" the shader programs. It will require some trial and error and fair deal of OpenGL state debugging to fix this. Fernando will also have to talk to James since he seems to be the most familiar with the current way that things are setup regarding PUI and OSG.
# PUI requires fixed-pipeline functionality, which is not available under the GL core profile. This is fixed by the Canvas GUI.

Issue number 1 is the reason why we currently have no GUI in HDR. Issue number 2 is the reason why we don't have HDR at all on AMD/Intel, as those drivers don't care about implementing the compatibility profile.<ref>https://forum.flightgear.org/viewtopic.php?f=19&t=41377&p=414781&hilit=#p414781</ref>

Thus, for the time being, you will need to configure everything (weather, scenery, etc.) beforehand using the [[FlightGear Qt launcher|launcher]], [[command line options]], or with external tools like [[Phi]].

Keep in mind that the HDR pipeline might not work in your system until we finish [[FlightGear and OpenGL Core Profile|moving to the OpenGL core profile]]. AMD graphics cards (regardless of age) and Intel integrated GPUs are known to be problematic.

== Notes for aircraft developers ==

The HDR pipeline handles lighting in a completely different manner compared to [[Atmospheric light scattering|ALS]]. The pipeline will attempt to "translate" classic Effects so they display correctly by making some assumptions. These assumptions are not always correct, so your aircraft might not display correctly under the HDR pipeline. In this section we describe some steps you can follow to leverage all the power of the HDR pipeline.

=== PBR and glTF ===

Physically-based rendering (PBR) refers to the concept of using realistic shading/lighting models along with measured surface values to accurately represent real-world materials. See this [https://marmoset.co/posts/physically-based-rendering-and-you-can-too/ webpage] for an extensive introduction to PBR and how you can create physically-based assets for your aircraft.

This pipeline introduces a PBR Effect ({{fgdata file|Effects/model-pbr.eff}}). However, you don't need to assign this Effect manually. You can export your model from Blender to the [[glTF]] format and use it directly. The Blender exporter will take care of exporting the necessary textures and the FlightGear parser will automatically assign the PBR Effect to your model. Your model XML file would contain something like this:

<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
<PropertyList>
<path>my-aircraft.gltf</path>
[...]
</PropertyList>
</syntaxhighlight>

Although '''not recommended''', the PBR effect can be assigned as usual by adding an <tt><effect></tt> tag in the model XML and configuring it like you would configure [[Model-combined effect|model-combined]].

=== Lights ===

Lights are defined using the [[Compositor#Lights|Compositor syntax]]. However, since we are dealing with physically-based values, the ambient/diffuse/specular values are ignored and the <tt>color</tt> and <tt>intensity</tt> parameters are used instead. The <tt>attenuation</tt> parameter is also ignored.

It is possible to have a light definition that is compatible with both ALS and HDR by defining all parameters at the same time. This might be troublesome though because the same values might yield different results under each pipeline.

An example light definition is shown below:

<syntaxhighlight lang="xml">
<light>
<name>my-spotlight</name>
<type>spot</type>
<position>
<x-m>-7.7476</x-m>
<y-m>0</y-m>
<z-m>-1.7990</z-m>
</position>
<direction>
<x>-1.0</x>
<y>0</y>
<z>-0.013</z>
</direction>
<color>
<r>1.0</r>
<g>0.0</g>
0.0
</color>
<intensity>10</intensity>
<spot-exponent>5</spot-exponent>
<spot-cutoff>40</spot-cutoff>
<range-m>50</range-m>
</light>
</syntaxhighlight>

== References ==
{{Appendix}}

== Related content ==
* [[Compositor]]
* [[glTF]]

[[Category:Compositor Pipelines]]

OpenGL

2023-10-02T06:22:58Z

Hooray: /* Status */ https://sourceforge.net/p/flightgear/mailman/message/37881226/

{{See also|FlightGear and OpenGL ES}}

'''OpenGL''' ('''Open G'''raphics '''L'''ibrary) is a graphics API used by [[FlightGear]]. It was developed by Silicon Graphics and first released in 1992.

Currently FlightGear requires OpenGL 1.2, but more likely 2.0, and recommends 2.1 or above.
However, over the course of the next 12-18 months, this in the process of changing (see [[#Status]] for details).

== Status ==
Last updated: 10/2023



We’re actively going to switch to [https://www.khronos.org/opengl/wiki/OpenGL_Context Core profile], on next, in the coming months: at least that is James' big goal for 2023 development, personally.

Maybe not getting as far as [[Vulkan Scene Graph|Vulkan/VSG]] (it would be nice but a lot more work….) but certainly getting our use of the OSG API as modern as possible, and getting the shaders into a OpenGL 4.x variant. (Eg, if MoltenGL can host us, that would be good for macOS…)

The problem is macOS: there is no compatibility profile.<ref>https://sourceforge.net/p/flightgear/mailman/message/37881226/</ref>
So, the main motivation for Core profile is macOS, where OpenGL 2 won’t help us : it needs to be Open 3.2, that’s what you get when you request a core profile.<ref>https://sourceforge.net/p/flightgear/mailman/message/37883795/</ref>

Fernando added a compile time switch for the default HUD (which still relies on legacy GL code), and made a few small modifications to allow for PUI to be disabled entirely. These modifications break font rendering currently. <ref>https://sourceforge.net/p/flightgear/mailman/message/39000474/</ref>

James would expect as a result of that, we would require OpenGL 4.1 or 4.2 on next: we could do 3.3 at a push but why bother? Apple supports 4.2 [1] and everyone else can update their drivers. Writing clean shaders will be so much easier if we can rely on 4.2 features as a baseline.

That would imply 2020.3 is the last OpenGL 2.x / non-shader release, but James also suspects on plenty of lower-spec machines, using OpenGL 4 and shaders will give us *better* FPS than our current fixed-function code. Given lower-spec machines have Intel graphics and the Intel drivers are terrible bad at fixed-function.<ref>https://sourceforge.net/p/flightgear/mailman/message/37146847/</ref>

{{See also|2022.X Release Plan#Rendering}}

{{Note|01/2023: As part of the [[Unifying the 2D rendering backend via canvas|Core profile migration]], we need to replace ShivaVG (which is the functional guts of CanvasPath.cxx) with a shader based implementation}}

Scott has been working on preparing to make the switch to OpenGL Core Profile <ref>https://sourceforge.net/p/flightgear/mailman/message/37147065/</ref>:
* Compile OSG with Core - {{Done}}
* Disable (a.k.a hack) SG/FG [[FlightGear_and_OpenGL_ES#Affected_features_and_sources|features requiring compatibility profile]] {{Done}}
** [[PUI#2022]] (new Canvas based UI expected around June 2023)
** [[FlightGear_and_OpenGL_ES#Affected_features_and_sources|HUD]]
** [[Shiva Alternatives|Canvas.Path]] (replace Shiva probably using Erik's ShaderVG work )
** [[Post_FlightGear_2020.2_LTS_changes#2D_Panels|2D Panels]]
* Review GLSL shaders to identify where changes are required - {{Done}}
* Refactor GLSL shaders {{Progressbar|90}} <ref>https://sourceforge.net/p/flightgear/mailman/message/37230099/</ref>

== Shaders ==

All the shaders are *330 core* compatible at the moment. Scott has been declaring *460 core*, but that will not be the final targeted version. We've discussed *420 core* as a potential soft target.<ref>https://sourceforge.net/p/flightgear/mailman/message/37261504/</ref>

Open GL 4.1 seems to be the latest supported version on macOS <ref>https://support.apple.com/en-us/HT202823</ref>, and that means shaders targeting 410 might be the best supported version for macOS users <ref>https://sourceforge.net/p/flightgear/mailman/message/37261554/</ref>

For the time being, we should probably target 410 at most. We will have to decide if we want to remain at 330 or we want to push to 410. The changes are not too significant, the main differences seem to be that 410 supports 32 bit floating point textures and tessellation shaders.<ref>https://sourceforge.net/p/flightgear/mailman/message/37262096/</ref>

== Related content ==
* [[Resources#General OpenGL Resources|General OpenGL Resources]]
* [[Graphics drivers configuration]]
* [[Graphics Card Profiles]]

== External links ==
* [http://www.opengl.org/ Official website]
* http://www.sgi.com/products/software/opengl/overview.html
* http://en.wikibooks.org/wiki/Opengl

==References ==
{{Appendix}}

[[Category:Software]]
[[pt:OpenGL]]

OpenGL

2023-10-02T06:20:02Z

Hooray: /* Status */ https://sourceforge.net/p/flightgear/mailman/message/37883795/

{{See also|FlightGear and OpenGL ES}}

'''OpenGL''' ('''Open G'''raphics '''L'''ibrary) is a graphics API used by [[FlightGear]]. It was developed by Silicon Graphics and first released in 1992.

Currently FlightGear requires OpenGL 1.2, but more likely 2.0, and recommends 2.1 or above.
However, over the course of the next 12-18 months, this in the process of changing (see [[#Status]] for details).

== Status ==
Last updated: 10/2023



We’re actively going to switch to [https://www.khronos.org/opengl/wiki/OpenGL_Context Core profile], on next, in the coming months: at least that is James' big goal for 2023 development, personally.

Maybe not getting as far as [[Vulkan Scene Graph|Vulkan/VSG]] (it would be nice but a lot more work….) but certainly getting our use of the OSG API as modern as possible, and getting the shaders into a OpenGL 4.x variant. (Eg, if MoltenGL can host us, that would be good for macOS…)

The main motivation for Core profile is macOS, where OpenGL 2 won’t help us : it needs to be Open 3.2, that’s what you get when you request a core profile.<ref>https://sourceforge.net/p/flightgear/mailman/message/37883795/</ref>

Fernando added a compile time switch for the default HUD (which still relies on legacy GL code), and made a few small modifications to allow for PUI to be disabled entirely. These modifications break font rendering currently. <ref>https://sourceforge.net/p/flightgear/mailman/message/39000474/</ref>

James would expect as a result of that, we would require OpenGL 4.1 or 4.2 on next: we could do 3.3 at a push but why bother? Apple supports 4.2 [1] and everyone else can update their drivers. Writing clean shaders will be so much easier if we can rely on 4.2 features as a baseline.

That would imply 2020.3 is the last OpenGL 2.x / non-shader release, but James also suspects on plenty of lower-spec machines, using OpenGL 4 and shaders will give us *better* FPS than our current fixed-function code. Given lower-spec machines have Intel graphics and the Intel drivers are terrible bad at fixed-function.<ref>https://sourceforge.net/p/flightgear/mailman/message/37146847/</ref>

{{See also|2022.X Release Plan#Rendering}}

{{Note|01/2023: As part of the [[Unifying the 2D rendering backend via canvas|Core profile migration]], we need to replace ShivaVG (which is the functional guts of CanvasPath.cxx) with a shader based implementation}}

Scott has been working on preparing to make the switch to OpenGL Core Profile <ref>https://sourceforge.net/p/flightgear/mailman/message/37147065/</ref>:
* Compile OSG with Core - {{Done}}
* Disable (a.k.a hack) SG/FG [[FlightGear_and_OpenGL_ES#Affected_features_and_sources|features requiring compatibility profile]] {{Done}}
** [[PUI#2022]] (new Canvas based UI expected around June 2023)
** [[FlightGear_and_OpenGL_ES#Affected_features_and_sources|HUD]]
** [[Shiva Alternatives|Canvas.Path]] (replace Shiva probably using Erik's ShaderVG work )
** [[Post_FlightGear_2020.2_LTS_changes#2D_Panels|2D Panels]]
* Review GLSL shaders to identify where changes are required - {{Done}}
* Refactor GLSL shaders {{Progressbar|90}} <ref>https://sourceforge.net/p/flightgear/mailman/message/37230099/</ref>

== Shaders ==

All the shaders are *330 core* compatible at the moment. Scott has been declaring *460 core*, but that will not be the final targeted version. We've discussed *420 core* as a potential soft target.<ref>https://sourceforge.net/p/flightgear/mailman/message/37261504/</ref>

Open GL 4.1 seems to be the latest supported version on macOS <ref>https://support.apple.com/en-us/HT202823</ref>, and that means shaders targeting 410 might be the best supported version for macOS users <ref>https://sourceforge.net/p/flightgear/mailman/message/37261554/</ref>

For the time being, we should probably target 410 at most. We will have to decide if we want to remain at 330 or we want to push to 410. The changes are not too significant, the main differences seem to be that 410 supports 32 bit floating point textures and tessellation shaders.<ref>https://sourceforge.net/p/flightgear/mailman/message/37262096/</ref>

== Related content ==
* [[Resources#General OpenGL Resources|General OpenGL Resources]]
* [[Graphics drivers configuration]]
* [[Graphics Card Profiles]]

== External links ==
* [http://www.opengl.org/ Official website]
* http://www.sgi.com/products/software/opengl/overview.html
* http://en.wikibooks.org/wiki/Opengl

==References ==
{{Appendix}}

[[Category:Software]]
[[pt:OpenGL]]

Unifying the 2D rendering backend via canvas

2023-10-02T06:18:35Z

Hooray: /* Background */ https://sourceforge.net/p/flightgear/mailman/message/37884120/

{{Main article|FlightGear and OpenGL ES}}

{{Template:Canvas Navigation}}

We have some many reasons to unify on as few rendering backends as possible: ideally just Canvas for everything 2D, so that as we improve how Canvas itself renders, those users automatically get faster.<ref>https://sourceforge.net/p/flightgear/mailman/message/37884120/</ref>
== Background ==

{{FGCquote
| the reason we still havent moved to opengl 3.x+ has been due to supporting OSX. If we wish to support OSX, we need to completely abandon the fixed function pipeline. Some of our dependencies (plib) are no longer maintained , so must be replaced with something that supports shaders (canvas, etc). 
 
Apple has made app developers to move on or stay in fixed fn. We aren't there yet. 
 
Almost every feature in fg needs a maintainer.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=221132#p221132
|title=<nowiki>Re: Orbital Makes the Sky Black</nowiki>
|author=<nowiki>psadro_gm</nowiki>
|date=<nowiki>Sat Oct 18</nowiki>
}}
}}

{{FGCquote
|the other issue is that there's still legacy GL code running in the main/rendering loop that prevents us from using a more recent OpenGL version, such as the panel/HUD and GUI code - those things are in the process of being unified, and re-implemented, on top of modern OSG code using a shared back-end via Canvas.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=221133#p221133
|title=<nowiki>Re: Orbital Makes the Sky Black</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sat Oct 18</nowiki>
}}
}}

{{cquote|In contrast to using some hardcoded GUI system (PUI, osgWidget, etc.) this approach would give much more flexibility and also the means of modifying and creating new widgets without the need to touch any core code.

With the Canvas system every type of widget would be possible, so that also things like submenus can be realized.

Another advantage of the Canvas approach is that it is heavily using the property tree and therefore is already fully accessible from Nasal code and also configurable with the existing xml formats.|[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg37861.html Thomas Geymayer]}}

{{cquote|using the Canvas also for the GUI would give us the advantage of a unified rendering backend for any type of GUI/text rendering and also the ability to use the same widgets everywhere - eg. use them also inside aircrafts for CDU GUIs or other displays... |[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg37867.html Thomas Geymayer]}}

{{cquote|I'm even more convinced now that we should move the 2D panel and HUD rendering over to this approach, since that would get rid of all the legacy OpenGL code besides the GUI.|[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg37868.html James Turner]}}

{{cquote|The long term idea is to eventually port some other 2D elements to this backend (eg the HUD and 2D panels) so they use OSG (and osgText) natively, and hence reduce the amount of C++ code we have for these jobs. (And increase our chances of working with newer OpenGL versions that forbid old style GL calls) Long-term here means 'after 2.8 at least'.|[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg37441.html James Turner]}}

{{cquote|Moving the HUD to use the Canvas would be a great step from my point of view, since it and 2D panels (which I am happy to write the convert for!) are the last places besides the UI which make raw OpenGL calls, and hence would benefit from moving to the Canvas (and thus, to use OSG internally)|[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38629.html James Turner]}}

{{FGCquote
|1= One solution would be to port the HUD to use osgText : that’s actually somewhat doable because it’s already centralised, but rather high risk close to release.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34769314/
| title = <nowiki>Re: [Flightgear-devel] Corrupted HUD / 2D panel text</nowiki>
| author = <nowiki>James Turner</nowiki>
| date = Jan 15th, 2016
| added = Jan 15th, 2016
| script_version = 0.23
}}
}}

<references/>

== HUD ==
{{See also|Post FlightGear 2020.2 LTS changes#Canvas}}
For the HUD, the question is if the Canvas-HUD could gain a Nasal glue layer, to replicate the C++ HUD?

This would then allow the C++ HUD code to be removed entirely, which would be a GoodThing(TM) since it does archaic OpenGL rendering. If Nasal is more your thing than C++, that might be another way to help hasten the death of PLIB <ref>https://sourceforge.net/p/flightgear/mailman/message/36289586/</ref>

There is no conceptual limitation in the Canvas that prevents us doing everything the built-in HUD does.<ref>https://sourceforge.net/p/flightgear/mailman/message/36401872/</ref>

If we are to move beyond the legacy C++ code, we need a layer (in Nasal or C++) that parses the existing HUID XML, and looks/works close-to-identical to the current version.

We could for example just add some more parseXXX functions (like parsesvg) which parse a dialog/hud/whathever file and create a canvas from it. So we would just have to modify eg. the show-dialog command to create a canvas and call the parser.<ref>https://sourceforge.net/p/flightgear/mailman/message/29589689/</ref>

Replace the HUD (HUD.cxx and related code) with a Canvas implementation. This is a confusing scheme, since we have ‘old’ and ‘new’ C++ HUDs (but I recall I unified their rendering some years ago), and some aircraft already using ‘custom Canvas HUDs’, i.e totally independent of the ‘built-in’ HUD.

To be clear, this is the HUD you get by pressing ‘h’ key in the sim. It’s configured by an XML file: FG_DATA/Huds/default.xml - and you can see in that directory, other configs are possible - the ‘new C++ HUD’ layer allows arbitrary placement of HUD elements defined by these XML.

Some aircraft, but I don’t know how many, use the C++ HUD system, but replace the default HUD with their own - see the F16 example file also in FG_DATA/Huds for example.

The aim would be to replace the C++ code with a Nasal HUD layer, likely in FG_DATA/Canvas/Hud - with one Canvas HUD item per each of the current C++ HUD items (ladder, tape, dial etc). Each one should be fairly easy to build with some path, text and group commands.

Then we need to write an XML loader in Nasal, possibly one line of C++ to trigger loading, and we can remove the C++ HUD code in favour of the Canvas implementation.

Of course, probably it’s not so simple but this is the concept!

Oh, and there is some complexity I guess about how the Canvas-for-the-HUD is positioned, since right now the HUD moves when the view is rotated. I guess / hope the existing Canvas HUDs can show how to handle that correctly.<ref>https://sourceforge.net/p/flightgear/mailman/message/36399261/</ref>

If the new impl defines each HUD component with the same features as the C++ implementation, it should work as a drop-in replacement for the old system. (Honestly it may be the case that some features supported in C++ are not used by any aircraft out there, but as ever with FG, we have no way to capture the set of in-use features).

If you look at say HUD_tape.cxx - which is one of the more complex ones - it’s some fairly ‘simple’ (but verbose) code to draw either a horizontal or vertical tape. Mostly it comes down to many draw_line calls which ultimately do the OpenGL - you can replace the draw_line calls in a Nasal version with appending a moveTo,lineTo onto a Canvas path.

And the constructor for HUD::Tape::Tape shows you the XML config properties for the tape which are supported.<ref>https://sourceforge.net/p/flightgear/mailman/message/36401850/</ref>

Of course, developing some Canvas HUDs for particular aircraft is a great way to get comfortable with writing Canvas code in general, and HUD display concepts. I just want to explain, that making fifty different Canvas HUDs for our aircraft, still won’t ever let us drop the legacy C++ code - we need a generic (XML driven) HUD for that.<ref>https://sourceforge.net/p/flightgear/mailman/message/36406449/</ref>

About making the specific HUD, I’d suggest to follow the Shuttle approach (procedurally generated geometry) more than the F-14 or F-15 - for a generic HUD using SVG elements will not work, the Shuttle HUD is already 100% defined via Nasal and hence closer to what you need.<ref>https://sourceforge.net/p/flightgear/mailman/message/36407420/</ref>

Canvas-HUD-that-replaces-the-C++-one would appear the same way Canvas tooltips / popups do. (or Canvas dialogs, or…)<ref>https://sourceforge.net/p/flightgear/mailman/message/36401971/</ref>

== 2D Panels ==

== osgText ==

== Planning ==
{{See also|Encapsulating rendering code using Canvas (RFC)}}

at some point we need to convert the generic HUD to sue the canvas - not a job I'm looking forward too - so I'm likely to steal any ideas and pieces I can to make my life easier. If anyone who actually uses HUDs wants to help with such an effort, please get in touch with TheTom and/or Zakalawe[http://forum.flightgear.org/viewtopic.php?f=71&t=18727#p174005].

The Canvas subsystem is flexible enough to re-implement existing 2D rendering related features, such as the HUD system or the 2D panel system, in scripting space, so that legacy C++ code can be incrementally replaced with a more accessible and more maintainable version in scripting space, i.e. as part of the base package - while ensuring that the 2D rendering backend is increasingly unified, using the Canvas subsystem as the common rendering backend. Once a standalone mode for the canvas system has been implemented, all systems making use of the canvas backend will automatically support standalone (FGPanel-analogous) rendering.

The idea is to provide Nasal wrappers for these systems, which implement the existing behavior using the canvas system, so that the old C++ code can be eventually phased out. In particular, this means that wrappers for the following systems will be added:

* HUD: {{flightgear url|src/Instrumentation/HUD}}
* 2D PANEL: {{flightgear url|src/Cockpit}}
* GUI: {{flightgear url|src/GUI/FGPUIDialog.cxx|line=709}} (currently in progress, see [[Canvas Widgets]])

Note that the API-requirements will be pretty much identical for GUI widgets and MFD-screens with touch screen functionality, both features will need a way to deal with keyboard/mouse input.

Initially, the main focus will be on providing the infrastructure to enable people to develop widgets entirely in Nasal space. Once that is working, it will be possible to increasingly re-implement native PUI widgets in Canvas/Nasal space, so that PUI usage is increasingly reduced.

To ensure that the Canvas/GUI wrapper is flexible enough, we need to take a look at existing hard coded PUI dialogs/widgets, and make sure that these can be theoretically reimplemented using Canvas/Nasal, and add any missing hooks as required:

* property list widget: {{flightgear url|src/GUI/property_list.cxx}}
* waypoint list widget: {{flightgear url|src/GUI/WaypointList.cxx}}
* map widget: {{flightgear url|src/GUI/MapWidget.cxx}}

Also, the Canvas subsystem should be powerful enough to allow re-implementing existing hard-coded {{flightgear source|src/Cockpit/od_gauge.cxx|text=od_gauge instruments}}, such as:

* dclgps: {{flightgear url|src/Instrumentation/dclgps.cxx}}
* kln89: {{flightgear url|src/Instrumentation/KLN89}}
* groundradar: {{flightgear url|src/Cockpit/groundradar.cxx}}
* wxRadar: {{flightgear url|src/Cockpit/wxradar.cxx}}
* agradar: {{flightgear url|src/Cockpit/agradar.cxx}}
* [[TCAS]]: {{flightgear url|src/Instrumentation/tcas.cxx}}
* NavDisplay: {{flightgear url|src/Cockpit/NavDisplay.cxx}}

We need to take a look at these instruments and their C++ code, to ensure that the Canvas API is sufficiently customizable to implement these and similar instruments purely in scripting space.

As of 07/2012 the navdb (including airports, runways etc) is fully exposed as part of the NasalPositioned module in $FG_SRC/Scripting: {{flightgear url|src/Scripting/NasalPositioned.cxx}}.

[[Category:Canvas GUI]]

Template:Canvas Widget Matrix

2023-10-02T06:17:08Z

Hooray: /* Status */ https://sourceforge.net/p/flightgear/mailman/message/37884138/

{{Note|If you'd like to get involved in working on widgets or creating new ones, please get in touch via the devel-mailing list to coordinate related efforts with James Turner first.}}
The following tablet represents a list of Canvas GUI widgets, with the goal being to implement a sufficient number of widgets to re-implement/emulate basic [[PUI]] functionality by using the new {{Fgdata file|Nasal/gui/XMLDialog.nas}} module that translates existing PUI/XML dialogs into Canvas dialogs dynamically (i.e. at runtime). To learn more about the rationale, please see [[PUI#Replacement status]], [[Unifying the 2D rendering backend via canvas]] and [[Hackathon Proposal:Canvas Widgets]].

For a (somewhat outdated) overview of PUI widgets used by FlightGear, see {{Readme file|gui}}.
To learn more about undocumented widgets, see: [[Template:PUI widget]]

For an authoritative list of PUI based widgets used by FlightGear, please refer to {{Flightgear source|src/GUI/FGPUIDialog.cxx|line=882}}.

== Status ==
{{See also|PUI#Status}}
'''Last updated: 10/2023
'''
* The lack of the menubar being implemented in Canvas was raised on the devel-list <ref>https://sourceforge.net/p/flightgear/mailman/message/37884138/</ref>
* The Canvas GUI Camera needs additional work in Core Profile mode <ref>https://forum.flightgear.org/viewtopic.php?f=19&t=41377&p=414781&hilit=#p414781</ref>
* Implementation of missing widgets to emulate [[PUI]] {{Progressbar|70}} (7/20 missing)
* add the menubar to the widget factory dialog {{Done}}
* Once the menubar widget is working properly and once we can parse/translate menubar.xml, we should consider using a separate dialog to show the fully translated menubar {{Not done}}
* Introduce a dialog to preview dialogs generated by XMLDialog.nas, so that more contributors can get involved in previewing/testing existing dialogs (including those outside fgdata) {{Not done}}
* C++ additions:
** expose [[SG_LOG]] stream for the loglist widget {{Not done}}
** expose translations for the menubar {{not done}}
** before porting the [[Map dialog|mapWidget]] (and before phasing it out), we need to revisit a long standing issue, i.e. not having back-ported the projection handling fix to the Canvas system: {{Issue|550}} and {{Issue|454}} (for details see [[Canvas_development#Projections]] and [[Howto:Adding new projections to Canvas Map]]) <ref>https://forum.flightgear.org/search.php?st=0&sk=t&sd=d&sr=posts&keywords=canvas+projection+map</ref>
** when opening 3+ concurrent instances of the new propertyTree dialog, fgfs will be massively slowed down, and that seems due to how labels are dynamically updated in Nasal space - we should probably extend label properties to optionally be based on on an sprintf-style string, and a list of properties to be read, and handle updates directly in C++ space rather than in Nasal space. Also, it might make sense to only update visible items? (for now, it's a really good stress test!)
** there seems to be a rather serious memory leak when using the Canvas GUI subsystem: the number of refs/objs and the size of Nasal memory pools never reduces upon closing said dialogs/windows (unlike PUI!), this applies to any Canvas GUI dialog/window, including tooltips
* Introduce meta information at the PropertyList/XML level to be able to version dialogs, for future changes to the underlying format
* Clean up the existing UI:
** especially the introduction of submenu support will make it possible to declutter the menubar (debug menu etc) {{Not done}}
** furthermore, introducing proper {{tag|tab}} support will make it possible to simplify a few existing dialogs {{Not done}}
* Optimizing and simplifying existing dialogs by introducing new layouting/widget primitives {{Not done}}

== Widgets ==

The majority of missing widgets can be implemented/approximated by using existing ones or adapting/extending those as needed. To get started with widget development, it's a good idea to look at some of the really simple ones first, and then take it from there - for instance, the Label widget is a comparatively simple widget:

{| class="wikitable"
! Status !!PUI widget {{Flightgear source|src/GUI/FGPUIDialog.cxx|line=882}} !! Complexity (0-10) !! Priority !! Canvas widget !! Remarks
|-
| {{Done}} || {{tag|frame}} || 1 || not critical || {{Canvas Widget|widget=Frame}} || see {{Fgdata commit|459dea77e5ceac592d0d5d58a059ccad1fce6daa}}
|-
| {{Done}} || {{tag|hrule}}/{{tag|vrule}}|| 1 || not critical || {{Canvas Widget|widget=Rule}} || {{Fgdata commit|459dea77e5ceac592d0d5d58a059ccad1fce6daa}}
|-
| {{Done}} || {{tag|list}} || 5|| high || {{Canvas Widget|widget=List}} || list, combo and select should probably be tackled together, there's plenty of common/similar functionality - these could all be based on the same superclass internally, which should probably be structured so that specific list types (airport list, property list, waypoint list, log list) can be implemented on top of the existing list widget.
|-
| {{Not done}} || {{tag|airport-list}} || 5|| || {{N/a|Not implemented}} ||trivial using navdb APIs and ScrollArea with buttons/labels for each entry and a corresponding event handler [[Howto:Processing_legacy_PUI_dialogs_using_Canvas#Use_Case:_airports.xml]]
|-
| {{Done}} || {{tag|property-list}} || 5|| || {{N/a|Not implemented}} || [[Property Browser]], [[Howto:Processing_legacy_PUI_dialogs_using_Canvas#Coming_up_with_a_property-list|rough prototype]] exists already, basically mapping 3 props.nas APIs to a ScrollArea with buttons for each property/node, allowing the tree to be travsersed interactively. Could be also implemented by using text labels and ASCII art, analogous to [[Nasal_Browser]] or using the new ListView widget
|-
| {{Not done}} || {{tag|waypointlist}} || 6|| || {{N/a|Not implemented}} || trivial using navdb APIs and ScrollArea with buttons
|-
| {{Not done}} || {{tag|loglist}} || 4|| || {{N/a|Not implemented}} || needs [[SG_LOG]] logstream exposed via [[Nasal/CppBind]]
|-
| {{Done}} || {{tag|input}} || 3 || || {{fgdata file|Nasal/canvas/gui/widgets/LineEdit.nas|t=LineEdit}} ||
|-
| {{Done}} || {{tag|text}} || 6|| || {{fgdata file|Nasal/canvas/gui/widgets/Label.nas|t=Label}} ||
|-
| {{Done}} || {{tag|checkbox}} || 4|| || {{fgdata file|Nasal/canvas/gui/widgets/Checkbox.nas|t=Checkbox}} ||
|-
| {{Done}} || {{tag|radio}} || 2|| || {{Canvas Widget|widget=RadioButton}} ||
|-
| {{Done}} || {{tag|button}} || 2|| || {{fgdata file|Nasal/canvas/gui/widgets/Button.nas|t=Button}} ||
|-
| {{Not done}} || {{tag|canvas}} || 4|| || should be implemented prior to {{tag|map}} || While we don't necessarily need a proper canvas widget, we need to map the PUI widget to a corresponding equivalent, i.e. an embedded Canvas with its own scripting block to animate the whole thing. The original pui2canvas parser simply set up an embedded Canvas via a Label with the raster image set up to show the Canvas instead: [[Howto:Processing_legacy_PUI_dialogs_using_Canvas#Embedded_Canvas]]
|-
| {{Not done}} || {{tag|map}} || 5|| || should honor the original property interface, and be based on the {{tag|canvas}} widget {{N/a|Not implemented, see also [[Canvas MapStructure]]}} || {{Progressbar|20}} [[Howto:Creating_a_Canvas_GUI_Widget#Implementing_a_Map_widget]]
|-
| {{Done}} || {{tag|combo}} || 6|| || {{N/a|Not implemented}} || list, combo and select can be unified
|-
| {{Not done}} || {{tag|select}} || 7|| {{N/a|Not implemented}} ||list, combo and select can be unified
|-
| {{Done}} || {{tag|slider}} || 4|| || {{fgdata file|Nasal/canvas/gui/widgets/Slider.nas|t=Slider}} ||
|-
| {{Done}} || {{tag|dial}} || 3|| || {{fgdata file|Nasal/canvas/gui/widgets/Dial.nas|t=Dial}} ||
|-
| {{Done}} || {{tag|textbox}} || 6|| || {{fgdata file|Nasal/canvas/gui/widgets/LineEdit.nas|t=LineEdit}} and/or {{fgdata file|Nasal/canvas/gui/widgets/Label.nas|t=Label}} ||
|}

== Menubar ==

Furthermore, we need to replace the [[Menubar]] itself, which is also implemented via PUI - for that purpose, there are some special widgets needed:
{| class="wikitable"
! Status || Complexity (0-10) !! Priority !! Canvas widget !! Remarks
|-
| {{Done}} || 3 || 10 || {{Canvas Widget|widget=MenuBar}} || see {{Fgdata commit|459dea77e5ceac592d0d5d58a059ccad1fce6daa}}
|-
| {{Done}} || 3 || 10 || {{Canvas Widget|widget=PopupMenu}} || see {{Merge-request|project=fgdata|id=305|text=Merge request:Implement canvas menus}}
see {{Fgdata commit|459dea77e5ceac592d0d5d58a059ccad1fce6daa}} <ref>https://sourceforge.net/p/flightgear/mailman/message/37756296/</ref><ref>https://sourceforge.net/p/flightgear/mailman/message/37756390/</ref><ref>https://sourceforge.net/p/flightgear/mailman/message/37756347/</ref>

|-
| {{Done}}|| 3 || 10 || {{Canvas Widget|widget=MenuItem}} || the design goal of MenuItem is to allow both simple items (text) but also check-ables ones, and in the future, simple widgets to be inside an item (eg, a slider or +/- controls in a menu item, or a multi-state selector of a few choices)

So, the aim was to have a constructor taking either a text string, or a callback which creates the widget content on demand (when the menu is shown)
<ref>https://sourceforge.net/p/flightgear/mailman/message/37756408/</ref> It's using an
item-orientated approach, and the menu has an addItem method to add an
arbitrary widget (in most cases this will be a MenuItem instance, but you
could use a slider just as well) and a createItem method that takes a text
and a callback and an optional icon, from which a new MenuItem is created.<ref>https://sourceforge.net/p/flightgear/mailman/message/37756436/</ref>
|-
| {{Done}}|| || 10 || {{Canvas Widget|widget=Menu}} || see {{Fgdata commit|459dea77e5ceac592d0d5d58a059ccad1fce6daa}}
|-
|}

In addition, there are some Canvas specific widgets that are not currently supported by PUI:

{| class="wikitable"
! Complexity (0-10) !! Priority !! Canvas widget !! Remarks
|-
| 6 || || {{fgdata file|Nasal/canvas/gui/widgets/ScrollArea.nas|t=ScrollArea}} || serves as the generic building block for any PUI list-type (waypoints/airports) with labels/buttons added for each entry shown
|-
| 4|| || {{fgdata file|Nasal/canvas/gui/widgets/TabWidget.nas|t=TabWidget}} || A [https://sourceforge.net/p/flightgear/mailman/message/37754597/ tab widget] as everyone knows it from their web browsr (pending review as of 12/2022 see {{Merge-request|project=fgdata|id=303|text=Merge request:Canvas tab widget implementation}})
|}

== General Improvements ==
With the new GUI system (!!) we could even do a mode which opens the property inspector at a particular branch of the property tree, and have a an option that reads "manually select loading settings [click here to edit values]"
… to keep the power tweakers happy without having a custom dialog box for every set of properties. (We do need to ensure they get auto-saved though, for this UI flow to be non-annoying) <ref>https://sourceforge.net/p/flightgear/mailman/message/37771124/</ref>

And that is something that we talked about and actually previously experimented with with Florent when the Addon system was being developed: There are some things in fgfs that don't really have a proper "config dialog" (yet) - but the property tree holds almost sufficient information to procedurally create a corresponding UI merely by doing a <code>foreach(var node; tree)</code> and by traversing a node to procedurally build a simple UI.

Having some sort of "overlay mode" for property-based dialogs would seem like a straightforward thing to do - we can easily support 3-5 optional attributes per node, and even recognize those dynamically inside the property browser, to provide this sort of "view" - and we could even register such nodes via a dedicated "hash" to make these available in a more direct fashion via the menubar.

The idea we had back then was to use optional XML/node attributes to add meta-info to such nodes, that way a "label" or "tooltip" attribute could be added, and even a "ui-type" node, so that such a loop could serve as a simple dialog builder for such annotated property nodes:

https://wiki.flightgear.org/Draw_masks
[[File:Draw-masks-via-canvas.png|thumb|FlightGear [[Draw masks]] GUI dialog procedurally created by the [[Canvas]] system.s]]

I guess you can see just how simple but powerful this idea is: as long as we add such meta information to certain properties, a simple loop could procedurally generate simple dialogs, without having to use separate files.

To prototype/test this sort of idea, we could use your tab widget inside the new property tree widget, and support a different sort of "view" for such nodes - basically like an "overlay", where such properties are dynamically interpreted to provide a simple UI without having to view/edit raw property values.

We could then annotate relevant property trees using optional attributes like:
* ui:label
* ui:tooltip
* ui:help (help string, could be shown via '?' button rendered next to each of these widgets)
* ui:type [toggle, checkbox, slider etc]
* ui:index (to influence in what order/manner such properties are mapped to widgets)
* ui:validate (to select applicable validation)

This sort of markup would make it very easy for fgdata/aircraft developers to create UIs without ever having to create a single dialog, just by providing sufficient meta information so that the Canvas GUI system could automatically create basic, but working, dialogs.

Imagine, a property tree node having optional attributes, e.g. along the lines of:
<syntaxhighlight language="xml">


<hostname type="string" ui:type="textbox" ui:label="Host name" ui:tooltip="enter a hostname" ui:validate:""/>
</syntaxhighlight>

We could then use a wrapper Class to map <code>props.Node</code> hierarchies to such dialogs using the equivalent of an <code>PropsOverlayBuilder</code> helper - the idea being to provide a UI overlay for nodes with rich meta info.

This sort of approach would also allow us to easily configure whether we want these settings to be stored with the userarchive flag set or not, or to save/load custom defaults via $FG_HOME/Export

== Styling ==
Fahim was also working on an alternate style since James wants to ensure we have correct model-view separation between the core widgets (which is the public API) and the style code that builds the visual appearance.

In general, help with making the styling parts is the piece I am slowest with though, so any help, especially creating border-images (scale9) that work as the backgrounds / frames for the various elements would be lovely.<ref>https://sourceforge.net/p/flightgear/mailman/message/37718562/</ref>

<ref>https://sourceforge.net/p/flightgear/mailman/message/37756178/</ref>

We need to figure out the split of DefaultStyle.nas, but James is very keen to ensure we add a second style alongside the default, before we change much here.

Regarding styling, James is worried about us ending up putting code into the wrong side of the widget / Style split, if we don’t have a second alternative style implementation to ‘keep us honest’<ref>https://sourceforge.net/p/flightgear/mailman/message/37756178/</ref>

We really have two kinds of ’styles’

* tweaking margins, font sizes, colours etc should indeed be done in XML as you wrote : this is also analogous to styles in the PUI sense

* making radically different ways of presenting the same logical widgets: eg text label of checkbox in a different position relative to the button (of Surface vs Material vs iOS style, if you know web/mobile UIs)

For the second kind we would use a different Nasal style implementation and that’s the abstraction James thinks it is very important to maintain.

It of course going to be a lot of work to make additional styles this way but it’s a very valuable feature to keep the possiblity, since it enables alternate UIs for user accessibility or different presentation modes such as VR.

What James doesn't want to do is add lots of widgets assuming we only care about DefaultStyle.nas, and then have an impossible mountain to climb when someone needs an alternate Nasal style. We don’t have to make a complete alternate style now, but I don’t want to take shortcuts the make it impossible in the future. So James wants to really think carefully about what is widget code and what is style code. <ref>https://sourceforge.net/p/flightgear/mailman/message/37756261/</ref>

Also, it is worth nothing that treating DefaultStyle.nas that way, is a straightforward mechanism to allow aircraft developers to customize their own styling for all sort of MFD purposes, without having to create complete widget sets from scratch - this is how Tom originally designed the whole thing, for his C130J.

== Widget Validation ==
At some point in the future, we may want to introduce support for optional constraints/restrictions for certain types of widgets (think headings/bearings/courses, frequencies, latitude/longitude, date/time, navaids, airports, file path, property path, metar string etc):

Things like password entry mode, restrictions on permitted characters (eg onl allowing numbers or an IP address), max number of characters entered, etc would all be config options as we add those kind of things gradually. That’s why I like it as an API: it avoids an explosion of setters for rarely used things, and it can be passed into the Style implementation ‘as is’ without each possible option needing to be explicitly handed over.<ref>https://sourceforge.net/p/flightgear/mailman/message/37765245/</ref>

== Cleaning up dialogs ==

Once the PUI/XML widget set is fully supported by the XMLDialog parser, it will make sense to review existing dialogs to identify opportunities to introduce new widgets and simplify existing dialogs.
As a matter of fact, a number of PUI/XML dialogs are currently working around PUI limitations by using awkward hacks to implement custom widgets. These show up by making excessive use of Nasal blobs as well as usage of the cmdarg() API, and they're a pain to maintain:

{{collapsible script
| title = PUI/XML dialogs making excessive use of embedded Nasal
| script =
* $FG_ROOT/gui/dialogs/airports.xml Total Nasal LOC: 415
* $FG_ROOT/gui/dialogs/advanced-graphics-options.xml Total Nasal LOC: 413
* $FG_ROOT/gui/dialogs/checklist.xml Total Nasal LOC: 399
* $FG_ROOT/gui/dialogs/weather.xml Total Nasal LOC: 298
* $FG_ROOT/gui/dialogs/chat-menu.xml Total Nasal LOC: 297
* $FG_ROOT/gui/dialogs/static-lod.xml Total Nasal LOC: 270
* $FG_ROOT/gui/dialogs/route-manager.xml Total Nasal LOC: 263
* $FG_ROOT/gui/dialogs/map-canvas.xml Total Nasal LOC: 188
* $FG_ROOT/gui/dialogs/file-select.xml Total Nasal LOC: 161
* $FG_ROOT/gui/dialogs/joystick-config.xml Total Nasal LOC: 159
* $FG_ROOT/gui/dialogs/location-in-air.xml Total Nasal LOC: 153
* $FG_ROOT/gui/dialogs/gps.xml Total Nasal LOC: 138
* $FG_ROOT/gui/dialogs/nasal-console.xml Total Nasal LOC: 132
* $FG_ROOT/gui/dialogs/button-config.xml Total Nasal LOC: 124
* $FG_ROOT/gui/dialogs/property-browser.xml Total Nasal LOC: 121
* $FG_ROOT/gui/dialogs/replay.xml Total Nasal LOC: 115
* $FG_ROOT/gui/dialogs/marker-adjust.xml Total Nasal LOC: 105
* $FG_ROOT/gui/dialogs/jetways-adjust.xml Total Nasal LOC: 103
* $FG_ROOT/gui/dialogs/multiplayer.xml Total Nasal LOC: 98
* $FG_ROOT/gui/dialogs/autopilot.xml Total Nasal LOC: 97
* $FG_ROOT/gui/dialogs/flight-recorder-load.xml Total Nasal LOC: 89
* $FG_ROOT/gui/dialogs/fgcom.xml Total Nasal LOC: 85
}}

== Introducing new Widgets ==
There is great scope to make /better/ Nasal APIs for items such as combo-boxes and pickers, especially ICAO and radio frequency pickers, but that's all 'improving the GUI' work than can happen once we've ditched PLIB and have something hackable.<ref>https://sourceforge.net/p/flightgear/mailman/message/29583931/</ref>

It's been repeatedly pointed out by a number of contributors, that the sheer amount of Nasal blobs embedded in PUI/XML dialogs is making UI development quite a hassle (especially those outside bindings, i.e. inside open/close blocks and the canvas load equivalent). Thus, it will make sense to review which new widgets could be introduced to get rid of these Nasal blobs:

{| class="wikitable"
! Status || Complexity (0-10) !! Priority !! Canvas widget !! Remarks
|-
| {{Not done}} || 4|| low || AirportView || this would help simplify airports.xml
|-
| {{Not done}} || 4|| low || ChecklistWidget || this would help simplify checklists.xml
|-
| {{Not done}} || 4|| low || PilotList || pilot list dialog
|-
| {{Not done}} || 4|| low || SubsystemList || performance monitor
|}

== Meta info for dialogs ==

These changes will also simplify development of the Phi/mongoose based UI, because we would be introducting dedicated widgets, which could just as well be implemented in JavaScript. However, for these changes to be introduced, we need to make some additions to the PropertyList/XML format used by GUI/XML files, namely:

* introducing a version attribute for the {{tag|PropertyList}} root
* introducing a {{tag|FileType}} node to specify that the file is a GUI/XML description: <code><FileType>GUI</FileType></code>
* introducing a {{tag|version}} node to be able to make breaking changes in the future

This way, we can easily update widgets/layouting primitives or introduce new ones, without having to be concerned about existing UI resources.

For instance, here's $FG_ROOT/gui/dialogs/scenery_loaded.xml with additional meta information, so that we can safely make changes in the future:
<syntaxhighlight lang="xml">
<?xml version="1.0"?>
<PropertyList version="1.0">
<FileType>GUIResource</FileType>
<version>1.0</version>
<name>scenery_loading</name>
<layout>vbox</layout>
<modal>true</modal>
<text>
<label>Scenery Loading...</label>
<padding>30</padding>
</text>
</PropertyList>

</syntaxhighlight>

== Reusability ==
Once our existing PUI widgets and dialogs are fully emulated, and dialogs have become better optimized (=less Nasal blobs). It will be a good idea to revisit some concerns and ideas expressed by Torsten D. based on his experience creating Phi:

Torsten once stated rightly that it would be benefical for any new UI to separate the logic included in most dialogs from the presentation anyway to make it reusable.
His vision was to have some kind of service implemented in FlightGear that wraps all complex tasks into service calls and responses. The command system is a
good start to trigger something, but it does not yet return anything.

Currently, all dialogs are a mixture of calling fg-commands and setting properties directly.

Phi already has some basic support for aircraft specific elements. <ref>https://sourceforge.net/p/flightgear/mailman/message/34532860/</ref>

We should discuss and prototype a new type of asynchronous fgcommand layer that may also return properties/values, this could benefit both: The Canvas UI, but also Phi. In the future, Canvas UI dialogs may thus also use these same fgcommands which would be running asynchronously (possibly over the same/existing non-blocking HTTP back-end already used by Phi).

At that point it will become increasingly feasible to also provide a module for Phi to interpret these new PUI/XML dialogs, because these would be primarily XML-based, should contain zero (or very little) code. And the new could be that Nasal code that still needs to stay inside such dialogs, will always need to be registered with the SGCommandMgr via the addCommand() API - that way, both front-ends would be able to interpret/execute such dialogs, which would mean that aircraft developers would not need to port/maintain two different sets of dialogs to support both front-ends.

Also, future updates to the UI will become tremendously easier once our dialogs are purely declarative/XML.

{{Appendix}}

Template:Canvas Widget Matrix

2023-10-02T06:15:41Z

Hooray: /* Status */ https://forum.flightgear.org/viewtopic.php?f=19&t=41377&p=414781&hilit=canvas#p414781

{{Note|If you'd like to get involved in working on widgets or creating new ones, please get in touch via the devel-mailing list to coordinate related efforts with James Turner first.}}
The following tablet represents a list of Canvas GUI widgets, with the goal being to implement a sufficient number of widgets to re-implement/emulate basic [[PUI]] functionality by using the new {{Fgdata file|Nasal/gui/XMLDialog.nas}} module that translates existing PUI/XML dialogs into Canvas dialogs dynamically (i.e. at runtime). To learn more about the rationale, please see [[PUI#Replacement status]], [[Unifying the 2D rendering backend via canvas]] and [[Hackathon Proposal:Canvas Widgets]].

For a (somewhat outdated) overview of PUI widgets used by FlightGear, see {{Readme file|gui}}.
To learn more about undocumented widgets, see: [[Template:PUI widget]]

For an authoritative list of PUI based widgets used by FlightGear, please refer to {{Flightgear source|src/GUI/FGPUIDialog.cxx|line=882}}.

== Status ==
{{See also|PUI#Status}}
'''Last updated: 10/2023
'''
* The Canvas GUI Camera needs additional work in Core Profile mode <ref>https://forum.flightgear.org/viewtopic.php?f=19&t=41377&p=414781&hilit=#p414781</ref>
* Implementation of missing widgets to emulate [[PUI]] {{Progressbar|70}} (7/20 missing)
* add the menubar to the widget factory dialog {{Done}}
* Once the menubar widget is working properly and once we can parse/translate menubar.xml, we should consider using a separate dialog to show the fully translated menubar {{Not done}}
* Introduce a dialog to preview dialogs generated by XMLDialog.nas, so that more contributors can get involved in previewing/testing existing dialogs (including those outside fgdata) {{Not done}}
* C++ additions:
** expose [[SG_LOG]] stream for the loglist widget {{Not done}}
** expose translations for the menubar {{not done}}
** before porting the [[Map dialog|mapWidget]] (and before phasing it out), we need to revisit a long standing issue, i.e. not having back-ported the projection handling fix to the Canvas system: {{Issue|550}} and {{Issue|454}} (for details see [[Canvas_development#Projections]] and [[Howto:Adding new projections to Canvas Map]]) <ref>https://forum.flightgear.org/search.php?st=0&sk=t&sd=d&sr=posts&keywords=canvas+projection+map</ref>
** when opening 3+ concurrent instances of the new propertyTree dialog, fgfs will be massively slowed down, and that seems due to how labels are dynamically updated in Nasal space - we should probably extend label properties to optionally be based on on an sprintf-style string, and a list of properties to be read, and handle updates directly in C++ space rather than in Nasal space. Also, it might make sense to only update visible items? (for now, it's a really good stress test!)
** there seems to be a rather serious memory leak when using the Canvas GUI subsystem: the number of refs/objs and the size of Nasal memory pools never reduces upon closing said dialogs/windows (unlike PUI!), this applies to any Canvas GUI dialog/window, including tooltips
* Introduce meta information at the PropertyList/XML level to be able to version dialogs, for future changes to the underlying format
* Clean up the existing UI:
** especially the introduction of submenu support will make it possible to declutter the menubar (debug menu etc) {{Not done}}
** furthermore, introducing proper {{tag|tab}} support will make it possible to simplify a few existing dialogs {{Not done}}
* Optimizing and simplifying existing dialogs by introducing new layouting/widget primitives {{Not done}}

== Widgets ==

The majority of missing widgets can be implemented/approximated by using existing ones or adapting/extending those as needed. To get started with widget development, it's a good idea to look at some of the really simple ones first, and then take it from there - for instance, the Label widget is a comparatively simple widget:

{| class="wikitable"
! Status !!PUI widget {{Flightgear source|src/GUI/FGPUIDialog.cxx|line=882}} !! Complexity (0-10) !! Priority !! Canvas widget !! Remarks
|-
| {{Done}} || {{tag|frame}} || 1 || not critical || {{Canvas Widget|widget=Frame}} || see {{Fgdata commit|459dea77e5ceac592d0d5d58a059ccad1fce6daa}}
|-
| {{Done}} || {{tag|hrule}}/{{tag|vrule}}|| 1 || not critical || {{Canvas Widget|widget=Rule}} || {{Fgdata commit|459dea77e5ceac592d0d5d58a059ccad1fce6daa}}
|-
| {{Done}} || {{tag|list}} || 5|| high || {{Canvas Widget|widget=List}} || list, combo and select should probably be tackled together, there's plenty of common/similar functionality - these could all be based on the same superclass internally, which should probably be structured so that specific list types (airport list, property list, waypoint list, log list) can be implemented on top of the existing list widget.
|-
| {{Not done}} || {{tag|airport-list}} || 5|| || {{N/a|Not implemented}} ||trivial using navdb APIs and ScrollArea with buttons/labels for each entry and a corresponding event handler [[Howto:Processing_legacy_PUI_dialogs_using_Canvas#Use_Case:_airports.xml]]
|-
| {{Done}} || {{tag|property-list}} || 5|| || {{N/a|Not implemented}} || [[Property Browser]], [[Howto:Processing_legacy_PUI_dialogs_using_Canvas#Coming_up_with_a_property-list|rough prototype]] exists already, basically mapping 3 props.nas APIs to a ScrollArea with buttons for each property/node, allowing the tree to be travsersed interactively. Could be also implemented by using text labels and ASCII art, analogous to [[Nasal_Browser]] or using the new ListView widget
|-
| {{Not done}} || {{tag|waypointlist}} || 6|| || {{N/a|Not implemented}} || trivial using navdb APIs and ScrollArea with buttons
|-
| {{Not done}} || {{tag|loglist}} || 4|| || {{N/a|Not implemented}} || needs [[SG_LOG]] logstream exposed via [[Nasal/CppBind]]
|-
| {{Done}} || {{tag|input}} || 3 || || {{fgdata file|Nasal/canvas/gui/widgets/LineEdit.nas|t=LineEdit}} ||
|-
| {{Done}} || {{tag|text}} || 6|| || {{fgdata file|Nasal/canvas/gui/widgets/Label.nas|t=Label}} ||
|-
| {{Done}} || {{tag|checkbox}} || 4|| || {{fgdata file|Nasal/canvas/gui/widgets/Checkbox.nas|t=Checkbox}} ||
|-
| {{Done}} || {{tag|radio}} || 2|| || {{Canvas Widget|widget=RadioButton}} ||
|-
| {{Done}} || {{tag|button}} || 2|| || {{fgdata file|Nasal/canvas/gui/widgets/Button.nas|t=Button}} ||
|-
| {{Not done}} || {{tag|canvas}} || 4|| || should be implemented prior to {{tag|map}} || While we don't necessarily need a proper canvas widget, we need to map the PUI widget to a corresponding equivalent, i.e. an embedded Canvas with its own scripting block to animate the whole thing. The original pui2canvas parser simply set up an embedded Canvas via a Label with the raster image set up to show the Canvas instead: [[Howto:Processing_legacy_PUI_dialogs_using_Canvas#Embedded_Canvas]]
|-
| {{Not done}} || {{tag|map}} || 5|| || should honor the original property interface, and be based on the {{tag|canvas}} widget {{N/a|Not implemented, see also [[Canvas MapStructure]]}} || {{Progressbar|20}} [[Howto:Creating_a_Canvas_GUI_Widget#Implementing_a_Map_widget]]
|-
| {{Done}} || {{tag|combo}} || 6|| || {{N/a|Not implemented}} || list, combo and select can be unified
|-
| {{Not done}} || {{tag|select}} || 7|| {{N/a|Not implemented}} ||list, combo and select can be unified
|-
| {{Done}} || {{tag|slider}} || 4|| || {{fgdata file|Nasal/canvas/gui/widgets/Slider.nas|t=Slider}} ||
|-
| {{Done}} || {{tag|dial}} || 3|| || {{fgdata file|Nasal/canvas/gui/widgets/Dial.nas|t=Dial}} ||
|-
| {{Done}} || {{tag|textbox}} || 6|| || {{fgdata file|Nasal/canvas/gui/widgets/LineEdit.nas|t=LineEdit}} and/or {{fgdata file|Nasal/canvas/gui/widgets/Label.nas|t=Label}} ||
|}

== Menubar ==

Furthermore, we need to replace the [[Menubar]] itself, which is also implemented via PUI - for that purpose, there are some special widgets needed:
{| class="wikitable"
! Status || Complexity (0-10) !! Priority !! Canvas widget !! Remarks
|-
| {{Done}} || 3 || 10 || {{Canvas Widget|widget=MenuBar}} || see {{Fgdata commit|459dea77e5ceac592d0d5d58a059ccad1fce6daa}}
|-
| {{Done}} || 3 || 10 || {{Canvas Widget|widget=PopupMenu}} || see {{Merge-request|project=fgdata|id=305|text=Merge request:Implement canvas menus}}
see {{Fgdata commit|459dea77e5ceac592d0d5d58a059ccad1fce6daa}} <ref>https://sourceforge.net/p/flightgear/mailman/message/37756296/</ref><ref>https://sourceforge.net/p/flightgear/mailman/message/37756390/</ref><ref>https://sourceforge.net/p/flightgear/mailman/message/37756347/</ref>

|-
| {{Done}}|| 3 || 10 || {{Canvas Widget|widget=MenuItem}} || the design goal of MenuItem is to allow both simple items (text) but also check-ables ones, and in the future, simple widgets to be inside an item (eg, a slider or +/- controls in a menu item, or a multi-state selector of a few choices)

So, the aim was to have a constructor taking either a text string, or a callback which creates the widget content on demand (when the menu is shown)
<ref>https://sourceforge.net/p/flightgear/mailman/message/37756408/</ref> It's using an
item-orientated approach, and the menu has an addItem method to add an
arbitrary widget (in most cases this will be a MenuItem instance, but you
could use a slider just as well) and a createItem method that takes a text
and a callback and an optional icon, from which a new MenuItem is created.<ref>https://sourceforge.net/p/flightgear/mailman/message/37756436/</ref>
|-
| {{Done}}|| || 10 || {{Canvas Widget|widget=Menu}} || see {{Fgdata commit|459dea77e5ceac592d0d5d58a059ccad1fce6daa}}
|-
|}

In addition, there are some Canvas specific widgets that are not currently supported by PUI:

{| class="wikitable"
! Complexity (0-10) !! Priority !! Canvas widget !! Remarks
|-
| 6 || || {{fgdata file|Nasal/canvas/gui/widgets/ScrollArea.nas|t=ScrollArea}} || serves as the generic building block for any PUI list-type (waypoints/airports) with labels/buttons added for each entry shown
|-
| 4|| || {{fgdata file|Nasal/canvas/gui/widgets/TabWidget.nas|t=TabWidget}} || A [https://sourceforge.net/p/flightgear/mailman/message/37754597/ tab widget] as everyone knows it from their web browsr (pending review as of 12/2022 see {{Merge-request|project=fgdata|id=303|text=Merge request:Canvas tab widget implementation}})
|}

== General Improvements ==
With the new GUI system (!!) we could even do a mode which opens the property inspector at a particular branch of the property tree, and have a an option that reads "manually select loading settings [click here to edit values]"
… to keep the power tweakers happy without having a custom dialog box for every set of properties. (We do need to ensure they get auto-saved though, for this UI flow to be non-annoying) <ref>https://sourceforge.net/p/flightgear/mailman/message/37771124/</ref>

And that is something that we talked about and actually previously experimented with with Florent when the Addon system was being developed: There are some things in fgfs that don't really have a proper "config dialog" (yet) - but the property tree holds almost sufficient information to procedurally create a corresponding UI merely by doing a <code>foreach(var node; tree)</code> and by traversing a node to procedurally build a simple UI.

Having some sort of "overlay mode" for property-based dialogs would seem like a straightforward thing to do - we can easily support 3-5 optional attributes per node, and even recognize those dynamically inside the property browser, to provide this sort of "view" - and we could even register such nodes via a dedicated "hash" to make these available in a more direct fashion via the menubar.

The idea we had back then was to use optional XML/node attributes to add meta-info to such nodes, that way a "label" or "tooltip" attribute could be added, and even a "ui-type" node, so that such a loop could serve as a simple dialog builder for such annotated property nodes:

https://wiki.flightgear.org/Draw_masks
[[File:Draw-masks-via-canvas.png|thumb|FlightGear [[Draw masks]] GUI dialog procedurally created by the [[Canvas]] system.s]]

I guess you can see just how simple but powerful this idea is: as long as we add such meta information to certain properties, a simple loop could procedurally generate simple dialogs, without having to use separate files.

To prototype/test this sort of idea, we could use your tab widget inside the new property tree widget, and support a different sort of "view" for such nodes - basically like an "overlay", where such properties are dynamically interpreted to provide a simple UI without having to view/edit raw property values.

We could then annotate relevant property trees using optional attributes like:
* ui:label
* ui:tooltip
* ui:help (help string, could be shown via '?' button rendered next to each of these widgets)
* ui:type [toggle, checkbox, slider etc]
* ui:index (to influence in what order/manner such properties are mapped to widgets)
* ui:validate (to select applicable validation)

This sort of markup would make it very easy for fgdata/aircraft developers to create UIs without ever having to create a single dialog, just by providing sufficient meta information so that the Canvas GUI system could automatically create basic, but working, dialogs.

Imagine, a property tree node having optional attributes, e.g. along the lines of:
<syntaxhighlight language="xml">


<hostname type="string" ui:type="textbox" ui:label="Host name" ui:tooltip="enter a hostname" ui:validate:""/>
</syntaxhighlight>

We could then use a wrapper Class to map <code>props.Node</code> hierarchies to such dialogs using the equivalent of an <code>PropsOverlayBuilder</code> helper - the idea being to provide a UI overlay for nodes with rich meta info.

This sort of approach would also allow us to easily configure whether we want these settings to be stored with the userarchive flag set or not, or to save/load custom defaults via $FG_HOME/Export

== Styling ==
Fahim was also working on an alternate style since James wants to ensure we have correct model-view separation between the core widgets (which is the public API) and the style code that builds the visual appearance.

In general, help with making the styling parts is the piece I am slowest with though, so any help, especially creating border-images (scale9) that work as the backgrounds / frames for the various elements would be lovely.<ref>https://sourceforge.net/p/flightgear/mailman/message/37718562/</ref>

<ref>https://sourceforge.net/p/flightgear/mailman/message/37756178/</ref>

We need to figure out the split of DefaultStyle.nas, but James is very keen to ensure we add a second style alongside the default, before we change much here.

Regarding styling, James is worried about us ending up putting code into the wrong side of the widget / Style split, if we don’t have a second alternative style implementation to ‘keep us honest’<ref>https://sourceforge.net/p/flightgear/mailman/message/37756178/</ref>

We really have two kinds of ’styles’

* tweaking margins, font sizes, colours etc should indeed be done in XML as you wrote : this is also analogous to styles in the PUI sense

* making radically different ways of presenting the same logical widgets: eg text label of checkbox in a different position relative to the button (of Surface vs Material vs iOS style, if you know web/mobile UIs)

For the second kind we would use a different Nasal style implementation and that’s the abstraction James thinks it is very important to maintain.

It of course going to be a lot of work to make additional styles this way but it’s a very valuable feature to keep the possiblity, since it enables alternate UIs for user accessibility or different presentation modes such as VR.

What James doesn't want to do is add lots of widgets assuming we only care about DefaultStyle.nas, and then have an impossible mountain to climb when someone needs an alternate Nasal style. We don’t have to make a complete alternate style now, but I don’t want to take shortcuts the make it impossible in the future. So James wants to really think carefully about what is widget code and what is style code. <ref>https://sourceforge.net/p/flightgear/mailman/message/37756261/</ref>

Also, it is worth nothing that treating DefaultStyle.nas that way, is a straightforward mechanism to allow aircraft developers to customize their own styling for all sort of MFD purposes, without having to create complete widget sets from scratch - this is how Tom originally designed the whole thing, for his C130J.

== Widget Validation ==
At some point in the future, we may want to introduce support for optional constraints/restrictions for certain types of widgets (think headings/bearings/courses, frequencies, latitude/longitude, date/time, navaids, airports, file path, property path, metar string etc):

Things like password entry mode, restrictions on permitted characters (eg onl allowing numbers or an IP address), max number of characters entered, etc would all be config options as we add those kind of things gradually. That’s why I like it as an API: it avoids an explosion of setters for rarely used things, and it can be passed into the Style implementation ‘as is’ without each possible option needing to be explicitly handed over.<ref>https://sourceforge.net/p/flightgear/mailman/message/37765245/</ref>

== Cleaning up dialogs ==

Once the PUI/XML widget set is fully supported by the XMLDialog parser, it will make sense to review existing dialogs to identify opportunities to introduce new widgets and simplify existing dialogs.
As a matter of fact, a number of PUI/XML dialogs are currently working around PUI limitations by using awkward hacks to implement custom widgets. These show up by making excessive use of Nasal blobs as well as usage of the cmdarg() API, and they're a pain to maintain:

{{collapsible script
| title = PUI/XML dialogs making excessive use of embedded Nasal
| script =
* $FG_ROOT/gui/dialogs/airports.xml Total Nasal LOC: 415
* $FG_ROOT/gui/dialogs/advanced-graphics-options.xml Total Nasal LOC: 413
* $FG_ROOT/gui/dialogs/checklist.xml Total Nasal LOC: 399
* $FG_ROOT/gui/dialogs/weather.xml Total Nasal LOC: 298
* $FG_ROOT/gui/dialogs/chat-menu.xml Total Nasal LOC: 297
* $FG_ROOT/gui/dialogs/static-lod.xml Total Nasal LOC: 270
* $FG_ROOT/gui/dialogs/route-manager.xml Total Nasal LOC: 263
* $FG_ROOT/gui/dialogs/map-canvas.xml Total Nasal LOC: 188
* $FG_ROOT/gui/dialogs/file-select.xml Total Nasal LOC: 161
* $FG_ROOT/gui/dialogs/joystick-config.xml Total Nasal LOC: 159
* $FG_ROOT/gui/dialogs/location-in-air.xml Total Nasal LOC: 153
* $FG_ROOT/gui/dialogs/gps.xml Total Nasal LOC: 138
* $FG_ROOT/gui/dialogs/nasal-console.xml Total Nasal LOC: 132
* $FG_ROOT/gui/dialogs/button-config.xml Total Nasal LOC: 124
* $FG_ROOT/gui/dialogs/property-browser.xml Total Nasal LOC: 121
* $FG_ROOT/gui/dialogs/replay.xml Total Nasal LOC: 115
* $FG_ROOT/gui/dialogs/marker-adjust.xml Total Nasal LOC: 105
* $FG_ROOT/gui/dialogs/jetways-adjust.xml Total Nasal LOC: 103
* $FG_ROOT/gui/dialogs/multiplayer.xml Total Nasal LOC: 98
* $FG_ROOT/gui/dialogs/autopilot.xml Total Nasal LOC: 97
* $FG_ROOT/gui/dialogs/flight-recorder-load.xml Total Nasal LOC: 89
* $FG_ROOT/gui/dialogs/fgcom.xml Total Nasal LOC: 85
}}

== Introducing new Widgets ==
There is great scope to make /better/ Nasal APIs for items such as combo-boxes and pickers, especially ICAO and radio frequency pickers, but that's all 'improving the GUI' work than can happen once we've ditched PLIB and have something hackable.<ref>https://sourceforge.net/p/flightgear/mailman/message/29583931/</ref>

It's been repeatedly pointed out by a number of contributors, that the sheer amount of Nasal blobs embedded in PUI/XML dialogs is making UI development quite a hassle (especially those outside bindings, i.e. inside open/close blocks and the canvas load equivalent). Thus, it will make sense to review which new widgets could be introduced to get rid of these Nasal blobs:

{| class="wikitable"
! Status || Complexity (0-10) !! Priority !! Canvas widget !! Remarks
|-
| {{Not done}} || 4|| low || AirportView || this would help simplify airports.xml
|-
| {{Not done}} || 4|| low || ChecklistWidget || this would help simplify checklists.xml
|-
| {{Not done}} || 4|| low || PilotList || pilot list dialog
|-
| {{Not done}} || 4|| low || SubsystemList || performance monitor
|}

== Meta info for dialogs ==

These changes will also simplify development of the Phi/mongoose based UI, because we would be introducting dedicated widgets, which could just as well be implemented in JavaScript. However, for these changes to be introduced, we need to make some additions to the PropertyList/XML format used by GUI/XML files, namely:

* introducing a version attribute for the {{tag|PropertyList}} root
* introducing a {{tag|FileType}} node to specify that the file is a GUI/XML description: <code><FileType>GUI</FileType></code>
* introducing a {{tag|version}} node to be able to make breaking changes in the future

This way, we can easily update widgets/layouting primitives or introduce new ones, without having to be concerned about existing UI resources.

For instance, here's $FG_ROOT/gui/dialogs/scenery_loaded.xml with additional meta information, so that we can safely make changes in the future:
<syntaxhighlight lang="xml">
<?xml version="1.0"?>
<PropertyList version="1.0">
<FileType>GUIResource</FileType>
<version>1.0</version>
<name>scenery_loading</name>
<layout>vbox</layout>
<modal>true</modal>
<text>
<label>Scenery Loading...</label>
<padding>30</padding>
</text>
</PropertyList>

</syntaxhighlight>

== Reusability ==
Once our existing PUI widgets and dialogs are fully emulated, and dialogs have become better optimized (=less Nasal blobs). It will be a good idea to revisit some concerns and ideas expressed by Torsten D. based on his experience creating Phi:

Torsten once stated rightly that it would be benefical for any new UI to separate the logic included in most dialogs from the presentation anyway to make it reusable.
His vision was to have some kind of service implemented in FlightGear that wraps all complex tasks into service calls and responses. The command system is a
good start to trigger something, but it does not yet return anything.

Currently, all dialogs are a mixture of calling fg-commands and setting properties directly.

Phi already has some basic support for aircraft specific elements. <ref>https://sourceforge.net/p/flightgear/mailman/message/34532860/</ref>

We should discuss and prototype a new type of asynchronous fgcommand layer that may also return properties/values, this could benefit both: The Canvas UI, but also Phi. In the future, Canvas UI dialogs may thus also use these same fgcommands which would be running asynchronously (possibly over the same/existing non-blocking HTTP back-end already used by Phi).

At that point it will become increasingly feasible to also provide a module for Phi to interpret these new PUI/XML dialogs, because these would be primarily XML-based, should contain zero (or very little) code. And the new could be that Nasal code that still needs to stay inside such dialogs, will always need to be registered with the SGCommandMgr via the addCommand() API - that way, both front-ends would be able to interpret/execute such dialogs, which would mean that aircraft developers would not need to port/maintain two different sets of dialogs to support both front-ends.

Also, future updates to the UI will become tremendously easier once our dialogs are purely declarative/XML.

{{Appendix}}

HDR Pipeline

2023-10-02T06:14:12Z

Hooray: /* Status */ @Fernando: Please review, thanks ! https://forum.flightgear.org/viewtopic.php?f=19&t=41377&p=414781&hilit=#p414781

{{forum|47|Effects & Shaders}}

{{infobox subsystem
|image = HDR pipeline c172p over TFFF.png
|name = HDR Pipeline
|started = 04/2021
|description = A modern rendering pipeline that targets relatively powerful systems
|status = In development
|developers = Fernando García Liñán <ref>https://sourceforge.net/u/fgarlin/profile/</ref>
|changelog = https://sourceforge.net/u/fgarlin/profile/feed.rss
|folders =
* {{fgdata file|Compositor/HDR}}
* {{fgdata file|Effects/HDR}}
* {{fgdata file|Shaders/HDR}}
}}

{{Rendering}}

The '''HDR Pipeline''' is a [[Compositor]]-based rendering pipeline that attempts to bring modern rendering techniques to FlightGear, namely {{wikipedia|High dynamic range|high dynamic range (HDR)}} and {{wikipedia|Physically based rendering|physically based rendering (PBR)}}. It is implemented entirely in [[$FG_ROOT]] using XML for the Compositor pipeline definition and [[Effects]], and GLSL for shaders. The pipeline can be enabled with the command line argument <code>--compositor=Compositor/HDR/hdr</code>.

== Background ==

The [[Classic Pipeline]] relies on legacy OpenGL features, so rather than improving or reworking it, the idea of creating an entirely separate rendering pipeline from scratch started taking shape. The [[Compositor]] played the biggest role in enabling this effort as it allows the creation of new rendering pipelines entirely in FGData space without any C++ changes whatsoever, greatly reducing the amount of work that had to be done and making the iterative process of testing and debugging much faster.

== Status ==
'''Last updated: 10/2023'''

The HDR pipeline is more or less stable, and is currently available on <tt>next</tt> for anyone adventurous enough to try it. The main issue is that built-in legacy GUI ([[PUI]]) is not compatible because it uses old OpenGL code, so there is no in-sim GUI:


# The GUI camera does not render anything (neither PUI nor Canvas). This is caused by OSG's attribute aliasing being enabled in HDR. Fernando suspect sthe solution might have to do with forcing the GUI camera to use shaders instead of the fixed-pipeline. He hasn't delved too deep into this yet because there are many possible places to "inject" the shader programs. It will require some trial and error and fair deal of OpenGL state debugging to fix this. Fernando will also have to talk to James since he seems to be the most familiar with the current way that things are setup regarding PUI and OSG.
# PUI requires fixed-pipeline functionality, which is not available under the GL core profile. This is fixed by the Canvas GUI.

Issue number 1 is the reason why we currently have no GUI in HDR. Issue number 2 is the reason why we don't have HDR at all on AMD/Intel, as those drivers don't care about implementing the compatibility profile.<ref>https://forum.flightgear.org/viewtopic.php?f=19&t=41377&p=414781&hilit=#p414781</ref>

Thus, for the time being, you will need to configure everything (weather, scenery, etc.) beforehand using the [[FlightGear Qt launcher|launcher]], [[command line options]], or with external tools like [[Phi]].

Keep in mind that the HDR pipeline might not work in your system until we finish [[FlightGear and OpenGL Core Profile|moving to the OpenGL core profile]]. AMD graphics cards (regardless of age) and Intel integrated GPUs are known to be problematic.

== Notes for aircraft developers ==

The HDR pipeline handles lighting in a completely different manner compared to [[Atmospheric light scattering|ALS]]. The pipeline will attempt to "translate" classic Effects so they display correctly by making some assumptions. These assumptions are not always correct, so your aircraft might not display correctly under the HDR pipeline. In this section we describe some steps you can follow to leverage all the power of the HDR pipeline.

=== PBR and glTF ===

Physically-based rendering (PBR) refers to the concept of using realistic shading/lighting models along with measured surface values to accurately represent real-world materials. See this [https://marmoset.co/posts/physically-based-rendering-and-you-can-too/ webpage] for an extensive introduction to PBR and how you can create physically-based assets for your aircraft.

This pipeline introduces a PBR Effect ({{fgdata file|Effects/model-pbr.eff}}). However, you don't need to assign this Effect manually. You can export your model from Blender to the [[glTF]] format and use it directly. The Blender exporter will take care of exporting the necessary textures and the FlightGear parser will automatically assign the PBR Effect to your model. Your model XML file would contain something like this:

<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
<PropertyList>
<path>my-aircraft.gltf</path>
[...]
</PropertyList>
</syntaxhighlight>

Although '''not recommended''', the PBR effect can be assigned as usual by adding an <tt><effect></tt> tag in the model XML and configuring it like you would configure [[Model-combined effect|model-combined]].

=== Lights ===

Lights are defined using the [[Compositor#Lights|Compositor syntax]]. However, since we are dealing with physically-based values, the ambient/diffuse/specular values are ignored and the <tt>color</tt> and <tt>intensity</tt> parameters are used instead. The <tt>attenuation</tt> parameter is also ignored.

It is possible to have a light definition that is compatible with both ALS and HDR by defining all parameters at the same time. This might be troublesome though because the same values might yield different results under each pipeline.

An example light definition is shown below:

<syntaxhighlight lang="xml">
<light>
<name>my-spotlight</name>
<type>spot</type>
<position>
<x-m>-7.7476</x-m>
<y-m>0</y-m>
<z-m>-1.7990</z-m>
</position>
<direction>
<x>-1.0</x>
<y>0</y>
<z>-0.013</z>
</direction>
<color>
<r>1.0</r>
<g>0.0</g>
0.0
</color>
<intensity>10</intensity>
<spot-exponent>5</spot-exponent>
<spot-cutoff>40</spot-cutoff>
<range-m>50</range-m>
</light>
</syntaxhighlight>

== References ==
{{Appendix}}

== Related content ==
* [[Compositor]]
* [[glTF]]

[[Category:Compositor Pipelines]]

Shiva Alternatives

2023-10-02T06:09:50Z

Hooray: /* Status */ https://sourceforge.net/p/flightgear/mailman/message/39000474/

{{Main article|Unifying the 2D rendering backend via canvas}}

{{Stub}}

{{forum|71|Canvas}}

{{infobox subsystem
|image = Anniversary4.png
|name = Canvas.Path port using shaders (deprecating Shiva)
|started = 02/2022 (Available on next)
|description = Canvas.Path being ported for [[Core Profile support]]
|status = Experimental (in the process of being integrated)
|developers = Erik, Scott, Fahim, Stuart, James (see references below)
|changelog = see commit {{Simgear commit|6451e505d8549f7d1e4bb440189559448f6aea5a|text=Add ShaderVG, a shader based version of ShivaVG}}

}}

To support [[Canvas]] on [[OpenGL]] [[FlightGear and OpenGL ES|Core profile]], the plan is to migrate the [[Canvas Path]] backend from [[Shiva]] to ‘something else’ which implements the required drawing operations. Unfortunately two of the probable solutions (Skia from Chrome and Cairo from Gtk) are both enormous and a pain to deploy on macOS and Windows.

The issue is mostly how the different libraries handle clipping. The problem is that for a non-rotated (or strictly, a 90-degree rotated) rectangular clip, you can use glSicssor to clip, which is ‘free’. For arbitrary shaped clips, or where the clip is transformed in some awkward way, the options are

# stencils (which I think is what ‘old’ Shiva uses)
# intermediate framebuffers
# geometric clipping but that’s a royal pain in the ass to combine with gradients / dash patterns

BTW this is why you should be super careful about using clips in a canvas: rectangular ones which are only translated / scaled are very efficient (due to glSicssor), but anything else can bite hard, especially on systems where the chosen solution (again, eg stencils) is not a common/fast path.<ref>https://sourceforge.net/p/flightgear/mailman/message/37610707/</ref>

There is the separate issue of Canvas being a little slow for some people, but that’s a separate task which we need to work on, and will change when we switch from Shiva to something more modern (as of 03/2023, [[#ShaderVG]] seems like the most likely candidate, for details see below). <ref>https://sourceforge.net/p/flightgear/mailman/message/37608469/</ref>

At the moment there are 4 version of ShivaVG/ShaderVG in SimGear.

In next there is the ancient version of ShivaVG (probably OpenGL
compatibility profile) and ShaderVG which is based on the ancient
version of ShivaVG but adds shaders for rendering paths and color maps.

In the topics/shivavg_update branch there is an updated version of
ShivaVG which requires OpenGL2.1 (and therefore I think leaves the
OpenGL compatibility profile behind) and a version of ShaderVG where the
changes between ShivaVG and ShaderVG have been applied on top of the new
ShivaVG.

For the time being, the first thing to check, maybe, is to see whether the version of
ShivaVG in the topics/shivavg_update branch is enough to get the core
profile working. I suspect it might.<ref>https://sourceforge.net/p/flightgear/mailman/message/37803242/</ref>

== Status ==
[[File:Canvas-shadervg-testpattern.png|thumb|Screen shot showing Erik's new test-pattern dialog, created as part of the effort to adapt Canvas Path in order to port it to a shader based approach using ShaderVG]]
* September, 28th 2023, Fernando is sharing very promising progress updates relating to Core Profile migration <ref>https://sourceforge.net/p/flightgear/mailman/message/39000474/</ref>
* April 15th, 2023, Scott is hoping to investigate remaining issues <ref>https://sourceforge.net/p/flightgear/mailman/message/37803388/</ref> He took a closer look at the latest ShivaVG and confirmed that it is compatibility profile, not core profile. He also thinks, it's best to discard this as a viable option based on our goals toward core profile and Scott said, he'll start to explore ShaderVG, which he believes is a good path forward.<ref>https://sourceforge.net/p/flightgear/mailman/message/37804095/</ref>
* April 13th, 2023: the non-shader code paths are now working correctly, but as soon as one or both of the shaders are used things get whacky,and I suspect it has something to do with what used to be the ModelView matrix which don't match between OpenSceneGraph and the shaders. <ref>https://sourceforge.net/p/flightgear/mailman/message/37803242/</ref>
* March 8th, 2023: Erik seems to have got basic ShaderVG integration working with few remaining issues <ref>https://sourceforge.net/p/flightgear/mailman/message/37787634/</ref> {{Fgdata commit|61664836a45d7ea2757916b51f02adb4bb45ab77}}
* March 4th, 2023: Erik started adding custom shaders to FG for ShaderVG
* Feb 17th, 2022: Erik added ShaderVG to SimGear on next including a corresponding cmake build option

== Testing ==
{{Caution|any changes we make to Canvas rendering, need to be strict about compatibility: at least to pixel level, ideally even sub-pixel (but sub-pixel might be hard to achieve). Therefore we should really understand any differences, before touching any aircraft, and for sure check the FG-1000, the A320 displays, Henning’s CRJ and have someone check the shuttle.<ref>https://sourceforge.net/p/flightgear/mailman/message/37610762/</ref> }}

{{Canvas Navigation}}

bugman once came up with the idea to take screen shots and use those to do automated unit-testing for these things, he discussed that idea in detail with James and Stuart on the list back then, including specifically the idea to do "''Headless rendering that can be captured as a bitmap''"<ref>https://sourceforge.net/p/flightgear/mailman/message/37086044/</ref>.

The idea back then was to ''render frames to bitmaps on disk or in memory for per-pixel checks'' for regression testing purposes.<ref>https://sourceforge.net/p/flightgear/mailman/message/37345003/</ref>

Edward stated: ''we will need to implement a true "headless" mode. Querying the scene graph, including performing scene graph dumps,
could be useful for quite a number of tests. And, probably also of interest especially for debugging graphics card driver issues,
switching to offline rendering to dump to a bitmap and check individual pixels'' <ref>https://sourceforge.net/p/flightgear/mailman/message/36292929/</ref>

Referring to the Canvas specifically, it is trivial to add a screen shot handler, to take canvas-specific screen shots and dump those to disk to run a binary diff (or do so in memory): [[Canvas_troubleshooting#Serializing_a_Canvas_to_disk_.28as_raster_image.29]]

It might even be possible to add a new Canvas.Path2 element, to run shiva and shadervg in the same fgfs executable and execute those tests side-by-side that way. <ref>https://sourceforge.net/p/flightgear/mailman/message/37612255/</ref>

In the mid-term, the idea being to accept a boolean flag at the Canvas level (for each canvas) so that we can decide which back-end to use.
At that point, it would be trivial run existing Canvas code with both back-ends within the same binary, each rendering to a separate canvas FBO.

And then, all that we'd need to do is to use something like memcmp() to compare two Canvas FBOs/textures side-by-side.

We could expose the equivalent of a <code>compare-canvas</code> fgcommand that takes the SGPropertNode/path of two canvas textures and runs then memcmp() in a for-loop for each pixel.

If this sort of functionality could be added to next, it would enable early-adopters/core devs and fgdata committers to get involved in testing/troubleshooting, without breaking next/fgfs for users not wanting to tinker with ShaderVG at this point.

Later on, we could either expose ShaderVG via new dedicated Canvas.Path2 namespace (totally new and separate), and phase out Canvas.Path over time.

Or, if the port works well enough, support a custom uint "version number" for sc::Element, so that people can easily adopt the new version by setting the required version to "2" for their Canvas.Path instance (with 1 one being the current default).

This could go a long way to help people get involved in testing and troubleshooting, without having to be C++ developers, also all the deployment would be handled automatically.

And a corresponding fgcommand (or cppbind wrapper) to do a pixel/bit-wise comparison of two Canvas textures would seem like a straightforward thing to implement, if we can figure out the other parts.

To be really on the safe side, we could even implement unit tests in Nasal space for each OpenVG primitive and do a comparison of both textures after each instruction (optionally).

One simple test case would be to use SVG files (which are internally converted to OpenVG instructions via svg.nas) and then parse/load those to compare the functionality of both back-ends, while diff'ing the two resulting Canvas FBOs pixel by pixel.

If things are too difficult to port properly, introducing a dedicated Canvas.Path2 namespace while phasing out Canvas.Path, would seem like a straightforward option to help migrate to Core Profile, without having people complain that Canvas.Path (Shiva) no longer works - because there would be no guarantee it actually does for people using the new namespace...

Another option would be adding a new boolean property to each Canvas for an optional "shadow" canvas, that way the CanvasMgr itself could run optionally update TWO textures in parallel, one using the original shiva back-end, and the other one using the new ShaderVG based back-end, this sort of infrastructure should also come in very handy if/when other Canvas elements may need to be updated in the time to come.

Basically, if a "enable-canvas-tracking" property is set up, another ODGauge FBO would be set up, which would receive updates by the new sc::element/back-end. This could optionally happen per frame (costly), or at a configurable interval, or even per OpenVG instruction.

=== Headless ===
{{Mergeto|FlightGear Headless}}
More generally, Edward stated that this is an area that he had in mind for the test suite. However the basic infrastructure of starting up a minimal headless scene graph rendering to a buffer has not been implemented yet.

So, someone needs to look at OSG and work out how to set up headless rendering in a way that you can capture a bitmap of the scene. The rest is then a piece of cake.

He suggested talking to James about this, as he might be able to quickly implement a simple headless infrastructure and be able to capture the issue. This original Canvas Path issue looks like the perfect excuse to implement this test suite infrastructure that, in the future, will be immeasurably useful!

Besides, the previous headless code is not so much use. For the test suite you probably only need a one line code change to render to a 'pbuffer' in OSG, and an additional option to render to a texture. What is relevant is a short function starting up the minimal set of subsystems (and currently non-subsystem elements) to render a basic fgfs scene graph. And maybe a second function to set up what is required to capture this issue. The key is that the main bootstrap routine used in fgfs is not used in the test suite - but Fred's contribution assumes this full bootstrapped system up and running.

In the test suite we don't want that full system, but an absolute minimum set of subsystems and other code running. There will be a set of helper functions (in test_suite/FGTestApi/) to set up different OSG components for different tests. The complication is that most subsystems will segfault if they are not in normal bootstrap position - you are already well aware of their brittleness. Another complication is that certain elements are not subsystems, e.g. FGSky. So the difficulty is not the headless part but simply setting up the minimal subset, fixing up all the segfaulting.

== ShaderVG ==
{{Caution|ShaderVG support is quite experimental at this stage. If you do not want to pull the latest changes, you can also try to compile simgear explicitly with <pre>USE_SHADERVG=OFF</pre> during the cmake step to ensure it's disabled.<ref>https://sourceforge.net/p/flightgear/mailman/message/37637897/</ref>
}}

[[File:ShivaVG.jpg|thumb|Here is a comparison between ShivaVG and ShaderVG.Look at the Canvas Dialog top left and particularly the vertical airspeed bars <ref>https://sourceforge.net/p/flightgear/mailman/message/37610774/</ref>]]
[[File:ShaderVG.jpg|thumb|Here is a comparison.Look at the Canvas Dialog top left and particularly the vertical airspeed bars<ref>https://sourceforge.net/p/flightgear/mailman/message/37610774/</ref>]]
'''Status:''' As of 03/2022, Erik added ShaderVG next to ShivaVG in SimGear next for testing ({{Simgear commit|6451e505d8549f7d1e4bb440189559448f6aea5a}}). The local patches applied to ShivaVG for FlightGear have also been applied to ShaderVG where appropriate, but it's not yet fully functional.<ref>https://sourceforge.net/p/flightgear/mailman/message/37612255/</ref>

To get involved in testing, use the <pre>Cmake option: USE_SHADERVG</pre> {{Simgear commit|b157f9cb9f02a77577ef309391289e8926a9b164}}.
Refer to related commits for details, see {{Simgear commit|074ba34035e240d144e0bc31c10583efcf82e566/}}.

In 03/2023, Erik shared an update stating that he's now got the root of the problem:
In VGInitOperation.cxx the size of the OpenGL viewport is passed to vgCreateContextSH which is always (0, 0, 800, 600) for some reason.
ShaderVG takes this input as the maximum area to draw thereby ignoring the "view" property when creating a new canvas in Nasal.
If he manually matches the parameters parsed to vgCreateContextSH with the canvas "view" parameters everything renders okay.
One of the problems is that VGInitOperation is called from osg.

Now he needs to find out where that is done and how to make it retrieve Canvas::getViewport instead <ref>https://sourceforge.net/p/flightgear/mailman/message/37783708/</ref>

In April 2023, Erik mentioned a few remaining problems probably related to this: If I disable shader use in the code most of it seems to work properly.

But as soon as one or both of the shaders are used things get whacky,
and I suspect it has something to do with what used to be the ModelView
matrix which don't match between OpenSceneGraph and the shaders.

And to be honest, I don't know enough about both of them to fix this
issue. So I would greatly appreciate it of someone with more knowledge
on the subject could take a look.

The shaders have been moved from the code to FGSDATA/gui/shaders/
<ref>https://sourceforge.net/p/flightgear/mailman/message/37803242/</ref>

For the corresponding commits, refer to:
* {{Simgear commit|6e30dfddc0717ac099228f4e288786db8d0f6a96}}
* {{Flightgear commit|24012329699186ab77fc673d77d07ba1196dbac7}}
* {{Fgdata commit|cfef45c93be67b8bc75f82b70adf968c5ec663cd}}

Erik's most recent update stating that he's got basic integration working now with few remaining issues.<ref>https://sourceforge.net/p/flightgear/mailman/message/37787634/</ref> For details, please refer to {{Fgdata commit|61664836a45d7ea2757916b51f02adb4bb45ab77}} and {{Simgear commit|64be445a020e29a352b63bfaefc6ac5aca90837d}}.

An email on the devel-list early 2022 mentioned that nanoVG (see below) may not be super simple to drop in, so another idea was using ShaderVG which seems to follow exactly the same API as ShivaVG.<ref>https://sourceforge.net/p/flightgear/mailman/message/37610705/</ref>

Early experiments (patch [https://sourceforge.net/p/flightgear/mailman/message/37610741/]) in 02/2022 with ShaderVG were promising and suggest, that it ‘kind of sort of’ works, that’s already less work than integrating NanoVG.<ref>https://sourceforge.net/p/flightgear/mailman/message/37610750/</ref>

[https://github.com/tqm-dev/ShaderVG ShaderVG] is a fork of a fork of the original ShivaVG which seems to not use the fixed OpenGL pipeline (well, at least it doesn’t have any glBegin/glEnd calls etc).

It uses glSicssor for clipping, that's fine. vgMaskImage is unimplemented but we could add it if anyone ever requested it.

The actual path filling / stroking uses stencil ops: this avoids the need to specify a custom framebuffer internally: of course Canvas is often rendering using an OSG FrameBuffer but that’s same today. (Maybe ‘old’ Shiva also uses the stencil ops the same way, also)

All gradient / pattern filling is handled using shaders, that’s very nice, should make using linear/radial gradients and patterns much better than existing Shiva. (This is same as NanoVG)<ref>https://sourceforge.net/p/flightgear/mailman/message/37610713/</ref>

Also, running a diff against ShivaVG from git, it turns out that FlightGear does have a number of local changes compared to a clean
ShivaVG, among "setup GL projection" changed to "We handle viewport and projection ourselves" Something similar is probably required for ShaderVG.<ref>https://sourceforge.net/p/flightgear/mailman/message/37612162/</ref>

For the time being, it's not a one on one drop in replacement but it works quite nicely:
* For one the x,y positions are off comapared to ShivaVG making things slightly bigger (maybe too big for the screen).
* and one issue with the "title bar" being opaque.<ref>https://sourceforge.net/p/flightgear/mailman/message/37610740/</ref>

Possibly, ShaderVG is writing to a texture buffer on the graphics card, but for some reason a different texture buffer is being referenced by FG - in one case the building texture and in another a random bit of graphics card memory.<ref>https://sourceforge.net/p/flightgear/mailman/message/37613781/</ref>

== Nanovg ==
Stuart wondered, whether we could use nanovg to create the texture from the vector data, as I think we already include it for Canvas?<ref>https://sourceforge.net/p/flightgear/mailman/message/37660063/</ref>
Canvas uses Shiva VG. But there is a GPU implementation of it (called ShaderVG) lingering to get included after some bugs are ironed out.<ref>https://sourceforge.net/p/flightgear/mailman/message/37660251/</ref>

The original idea was to replace Shiva with this: https://github.com/inniyah/nanovg

.. which should be small enough to drop in directly, *and* we believe, supports the required Path rendering features which Canvas needs. (Eg, line thickness, dot/dash, clipping) Unlike Shiva, NanoVG can target Core-profile OpenGL, using its own shaders, and because they both aim to implement the same VG spec, should be close enough at the pixel level, to keep everything working. (Let’s see how that works in reality)

What could then be added to Canvas, is the option to use shaders when using a [[Canvas Image]]. Qt Quick calls this a ‘layer’ (like in Photoshop): basically when drawing this intermediate texture (which is what an Image or Canvas-in-a-Canvas is), add the option to use a custom shader in a very similar manner to an [[ALS]] filter. That would definitely be a nice enhancement to Canvas capabilities.<ref>https://sourceforge.net/p/flightgear/mailman/message/37606487/</ref>


== CPU renderer ==
{{See also|Canvas_news#Skia_backend|Canvas_news#Skia_talks}}
James has been recommending for some time, that it should be possible to render Canvas using CPU (not GPU) which for older machines could be a win for us. Even with us switching from ShivaVG to NanoVG for GPU accelerated drawing, there is some chance it’s still worth pursuing this.

(Basic idea is to use one of the mannnnnny software VG renderers, eg Cairo or something smaller : this would trade GPU time for CPU time, almost certain a bad idea on modern GPUs, but if the GPU is already the bottleneck, and CPU cores are idle, could potentially work well on older machines to make our use of resources more balanced)

It would be ‘some work’ but much less work than every aircraft dev duplicating their entire Canvas work. If someone is ever interested to try this, just ping James Turner, it’s quite a nice self-contained project.<ref>https://sourceforge.net/p/flightgear/mailman/flightgear-devel/</ref>

== References ==
{{Appendix}}

OpenGL

2023-10-02T06:07:18Z

Hooray: /* Status */ https://sourceforge.net/p/flightgear/mailman/message/39000474/

{{See also|FlightGear and OpenGL ES}}

'''OpenGL''' ('''Open G'''raphics '''L'''ibrary) is a graphics API used by [[FlightGear]]. It was developed by Silicon Graphics and first released in 1992.

Currently FlightGear requires OpenGL 1.2, but more likely 2.0, and recommends 2.1 or above.
However, over the course of the next 12-18 months, this in the process of changing (see [[#Status]] for details).

== Status ==
Last updated: 10/2023



We’re actively going to switch to [https://www.khronos.org/opengl/wiki/OpenGL_Context Core profile], on next, in the coming months: at least that is James' big goal for 2023 development, personally.

Maybe not getting as far as [[Vulkan Scene Graph|Vulkan/VSG]] (it would be nice but a lot more work….) but certainly getting our use of the OSG API as modern as possible, and getting the shaders into a OpenGL 4.x variant. (Eg, if MoltenGL can host us, that would be good for macOS…)

Fernando added a compile time switch for the default HUD (which still relies on legacy GL code), and made a few small modifications to allow for PUI to be disabled entirely. These modifications break font rendering currently. <ref>https://sourceforge.net/p/flightgear/mailman/message/39000474/</ref>

James would expect as a result of that, we would require OpenGL 4.1 or 4.2 on next: we could do 3.3 at a push but why bother? Apple supports 4.2 [1] and everyone else can update their drivers. Writing clean shaders will be so much easier if we can rely on 4.2 features as a baseline.

That would imply 2020.3 is the last OpenGL 2.x / non-shader release, but James also suspects on plenty of lower-spec machines, using OpenGL 4 and shaders will give us *better* FPS than our current fixed-function code. Given lower-spec machines have Intel graphics and the Intel drivers are terrible bad at fixed-function.<ref>https://sourceforge.net/p/flightgear/mailman/message/37146847/</ref>

{{See also|2022.X Release Plan#Rendering}}

{{Note|01/2023: As part of the [[Unifying the 2D rendering backend via canvas|Core profile migration]], we need to replace ShivaVG (which is the functional guts of CanvasPath.cxx) with a shader based implementation}}

Scott has been working on preparing to make the switch to OpenGL Core Profile <ref>https://sourceforge.net/p/flightgear/mailman/message/37147065/</ref>:
* Compile OSG with Core - {{Done}}
* Disable (a.k.a hack) SG/FG [[FlightGear_and_OpenGL_ES#Affected_features_and_sources|features requiring compatibility profile]] {{Done}}
** [[PUI#2022]] (new Canvas based UI expected around June 2023)
** [[FlightGear_and_OpenGL_ES#Affected_features_and_sources|HUD]]
** [[Shiva Alternatives|Canvas.Path]] (replace Shiva probably using Erik's ShaderVG work )
** [[Post_FlightGear_2020.2_LTS_changes#2D_Panels|2D Panels]]
* Review GLSL shaders to identify where changes are required - {{Done}}
* Refactor GLSL shaders {{Progressbar|90}} <ref>https://sourceforge.net/p/flightgear/mailman/message/37230099/</ref>

== Shaders ==

All the shaders are *330 core* compatible at the moment. Scott has been declaring *460 core*, but that will not be the final targeted version. We've discussed *420 core* as a potential soft target.<ref>https://sourceforge.net/p/flightgear/mailman/message/37261504/</ref>

Open GL 4.1 seems to be the latest supported version on macOS <ref>https://support.apple.com/en-us/HT202823</ref>, and that means shaders targeting 410 might be the best supported version for macOS users <ref>https://sourceforge.net/p/flightgear/mailman/message/37261554/</ref>

For the time being, we should probably target 410 at most. We will have to decide if we want to remain at 330 or we want to push to 410. The changes are not too significant, the main differences seem to be that 410 supports 32 bit floating point textures and tessellation shaders.<ref>https://sourceforge.net/p/flightgear/mailman/message/37262096/</ref>

== Related content ==
* [[Resources#General OpenGL Resources|General OpenGL Resources]]
* [[Graphics drivers configuration]]
* [[Graphics Card Profiles]]

== External links ==
* [http://www.opengl.org/ Official website]
* http://www.sgi.com/products/software/opengl/overview.html
* http://en.wikibooks.org/wiki/Opengl

==References ==
{{Appendix}}

[[Category:Software]]
[[pt:OpenGL]]

Next newsletter

2023-06-24T08:02:10Z

Hooray: wow, seems the newsletter is kinda abandoned these days ??

#REDIRECT [[FlightGear Newsletter July 2023]]
{{User:Skybike/Template:This months newsletter|date=now}}

User:Senusema

2023-06-12T07:49:16Z

Hooray: Created page with "Category:Watchdog"

[[Category:Watchdog]]

User:Ipol

2023-06-12T07:49:11Z

Hooray: Created page with "Category:Watchdog"

[[Category:Watchdog]]

User:Andreandeny

2023-06-12T07:49:06Z

Hooray: Created page with "Category:Watchdog"

[[Category:Watchdog]]

Category:Watchdog

2023-06-12T07:48:35Z

Hooray: Created page with "List of user accounts that were created during/shortly after a spam attack, that are to be watched."

List of user accounts that were created during/shortly after a spam attack, that are to be watched.

HDR Pipeline

2023-04-24T05:54:50Z

Hooray: /* Status */

{{forum|47|Effects & Shaders}}

{{infobox subsystem
|image = HDR pipeline c172p over TFFF.png
|name = HDR Pipeline
|started = 04/2021
|description = A modern rendering pipeline that targets relatively powerful systems
|status = In development
|developers = Fernando García Liñán <ref>https://sourceforge.net/u/fgarlin/profile/</ref>
|changelog = https://sourceforge.net/u/fgarlin/profile/feed.rss
|folders =
* {{fgdata file|Compositor/HDR}}
* {{fgdata file|Effects/HDR}}
* {{fgdata file|Shaders/HDR}}
}}

{{Rendering}}

The '''HDR Pipeline''' is a [[Compositor]]-based rendering pipeline that attempts to bring modern rendering techniques to FlightGear, namely {{wikipedia|High dynamic range|high dynamic range (HDR)}} and {{wikipedia|Physically based rendering|physically based rendering (PBR)}}. It is implemented entirely in [[$FG_ROOT]] using XML for the Compositor pipeline definition and [[Effects]], and GLSL for shaders. The pipeline can be enabled with the command line argument <code>--compositor=Compositor/HDR/hdr</code>.

== Background ==

The [[Classic Pipeline]] relies on legacy OpenGL features, so rather than improving or reworking it, the idea of creating an entirely separate rendering pipeline from scratch started taking shape. The [[Compositor]] played the biggest role in enabling this effort as it allows the creation of new rendering pipelines entirely in FGData space without any C++ changes whatsoever, greatly reducing the amount of work that had to be done and making the iterative process of testing and debugging much faster.

== Status ==
'''Last updated: 04/2023'''

The HDR pipeline is more or less stable, and is currently available on <tt>next</tt> for anyone adventurous enough to try it. The main issue is that built-in legacy GUI ([[PUI]]) is not compatible because it uses old OpenGL code, so there is no in-sim GUI. You will need to configure everything (weather, scenery, etc.) beforehand using the [[FlightGear Qt launcher|launcher]], [[command line options]], or with external tools like [[Phi]].

Keep in mind that the HDR pipeline might not work in your system until we finish [[FlightGear and OpenGL Core Profile|moving to the OpenGL core profile]]. AMD graphics cards (regardless of age) and Intel integrated GPUs are known to be problematic.

== Notes for aircraft developers ==

The HDR pipeline handles lighting in a completely different manner compared to [[Atmospheric light scattering|ALS]]. The pipeline will attempt to "translate" classic Effects so they display correctly by making some assumptions. These assumptions are not always correct, so your aircraft might not display correctly under the HDR pipeline. In this section we describe some steps you can follow to leverage all the power of the HDR pipeline.

=== PBR and glTF ===

Physically-based rendering (PBR) refers to the concept of using realistic shading/lighting models along with measured surface values to accurately represent real-world materials. See this [https://marmoset.co/posts/physically-based-rendering-and-you-can-too/ webpage] for an extensive introduction to PBR and how you can create physically-based assets for your aircraft.

This pipeline introduces a PBR Effect ({{fgdata file|Effects/model-pbr.eff}}). However, you don't need to assign this Effect manually. You can export your model from Blender to the [[glTF]] format and use it directly. The Blender exporter will take care of exporting the necessary textures and the FlightGear parser will automatically assign the PBR Effect to your model. Your model XML file would contain something like this:

<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
<PropertyList>
<path>my-aircraft.gltf</path>
[...]
</PropertyList>
</syntaxhighlight>

Although '''not recommended''', the PBR effect can be assigned as usual by adding an <tt><effect></tt> tag in the model XML and configuring it like you would configure [[Model-combined effect|model-combined]].

=== Lights ===

Lights are defined using the [[Compositor#Lights|Compositor syntax]]. However, since we are dealing with physically-based values, the ambient/diffuse/specular values are ignored and the <tt>color</tt> and <tt>intensity</tt> parameters are used instead. The <tt>attenuation</tt> parameter is also ignored.

It is possible to have a light definition that is compatible with both ALS and HDR by defining all parameters at the same time. This might be troublesome though because the same values might yield different results under each pipeline.

An example light definition is shown below:

<syntaxhighlight lang="xml">
<light>
<name>my-spotlight</name>
<type>spot</type>
<position>
<x-m>-7.7476</x-m>
<y-m>0</y-m>
<z-m>-1.7990</z-m>
</position>
<direction>
<x>-1.0</x>
<y>0</y>
<z>-0.013</z>
</direction>
<color>
<r>1.0</r>
<g>0.0</g>
0.0
</color>
<intensity>10</intensity>
<spot-exponent>5</spot-exponent>
<spot-cutoff>40</spot-cutoff>
<range-m>50</range-m>
</light>
</syntaxhighlight>

== References ==
{{Appendix}}

== Related content ==
* [[Compositor]]
* [[glTF]]

[[Category:Compositor Pipelines]]

PUI

2023-04-22T17:43:18Z

Hooray: /* Status */

{{Feature to be removed|version=2023.3|reason=[[Plib]]/PUI is to be removed and replaced by a [[Canvas widget matrix|Canvas/Nasal based solution]] to help improve compatibility with [[OSG]] 3.6+ and [[OpenGL]] 4.x ([[Core Profile support|OpenGL Core Profile]], see [[2022.X Release plan]] ) and improve performance by [[Unifying the 2D rendering backend via canvas|phasing out legacy OpenGL code]]. Therefore, people should be careful when extending the '''PUI''' based legacy GUI engine<ref>https://sourceforge.net/p/flightgear/mailman/message/34921495/</ref><ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35157325/
|title = <nowiki> Re: [Flightgear-devel] GUI options (Was: Aircraft center) </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jun 14th, 2016
|added = Jun 14th, 2016
|script_version = 0.40
}}</ref> and coordinate any related work with the devel mailing list first-this applies particularly to adding any [[Template:PUI_widget|additional hard-coded PUI widgets]]. }}
[[File:Exit.png|thumb|FlightGear GUI dialog (exit.xml)stored in $FG_ROOT/gui/dialogs]]
{{GUI Navbar}}

[[File:Custom-autopilot-dialog.png|right|200px]]
[[PUI]] is the standard GUI engine used in FlightGear, it is part of [[PLIB]] and is using raw, fixed-pipeline, [[OpenGL]] code internally (no [[OpenSceneGraph]]). As of mid 2021, FlightGear is in the process of working towards adopting the OpenGL Core Profile, this means that [[PUI]] is causing trouble and needs to be replaced/disabled or ported.

PUI provides a fairly basic, but robust, set of widgets. PUI is also used for rendering the [[Menubar]].

FlightGear uses a GUI widget set that is implemented on top of raw (legacy) [[OpenGL]]. This has many advantages from a portability standpoint and from the standpoint of integrating with window systems. [[PUI]] doesn't have every feature under the sun, but it was never meant to. It's relatively small, lean, mean, and written on top of [[OpenGL]] which makes life *much* easier for us.

[[PUI]] already is a separate distinct library within Plib. It depends on some central utility stuff, but that's about it. So it is pretty stripped down and separate already.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg26011.html</ref>

We are to some extent hamstrung by the rather old GUI toolkit we use. However, replacing that is going to be non-trivial, and it would affect not just the core GUI but also all the dialog boxes that have been set up for particular aircraft.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg25985.html</ref>

Flightgear can look amazing when you use the HDR pipeline. We absolutely need this to stay relevant. The problem is that HDR is not compatible with OpenGL1 PUI. Work on getting rid of PUI has been going on for over a decade (longer than it took to implement it).<ref>https://sourceforge.net/p/flightgear/mailman/message/37727346/</ref>

[[File:menubar2.jpg|517px]]

== Replacement status ==
{{See also|FlightGear_and_OpenGL_ES#Example:_disabling_PUI}}

{{Note| Update 09/2022: The PUI replacement [[QtQuick_use_in_FlightGear#Background|was going to be Qt]] but it started to get very complicated with changes in Qt 5.15 + Qt 6, so James is going with a more light-weight Canvas based approach now.

Qt added support for Vulkan / Metal / D3D starting in 5.15, but FlightGear / OpenSceneGraph can’t support those, so integrating the two renderers went from being ‘complicated but ok’ to ‘very very complicated’.

So now James is going with something much more lightweight using some C++ compatibility code, some Nasal for styling and the existing [[Canvas widgets|Canvas widget rendering]] from Thomas Geymayer (TheTom) with [[Canvas Widget Matrix|some extensions and additions]], based on the [[Howto:Processing_legacy_PUI_dialogs_using_Canvas#Original_Discussion|plans originally discussed when the Canvas GUI system was added to FlightGear]]: some pieces are in FlightGear & FGData already.

James has basic dialogs working okay but not the more complex ones and everything looks kind of ugly, he needs to improve the visual look before he shares screenshots to avoid everyone freaking out :) The disadvantage of this approach is James is far from expert at creating visual appearances this way, so it’s kind on unrewarding and slow for him. If someone likes messing with CSS-type styling, border-images and hover-states, ping him since we could probably move things also faster <ref>https://sourceforge.net/p/flightgear/mailman/message/37701750/</ref>}}

=== Motivation ===
{{Main article|Core Profile support}}

The bigger issue here is we need to ditch [[PUI]] (which is in progress) and some OpenGL 1.0 code (HUD, 2D panels especially - can be #ifdef for now) so we can enable Core profile on Mac - since Mac 4.x support (we only hit about 4.3 alas, but with some extensions to get in sight of 4.5) is Core profile only, no Compatability mode.

Improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, many people are convinced PUI needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

While most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so [using Qt5] would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

== Canvas Emulation ==
{{See also|Canvas widget matrix}}
'''Last updated: 04/2023 <ref>https://sourceforge.net/p/flightgear/mailman/message/37805054/</ref>
'''
=== Gallery ===

<gallery>
About-dialog-xmldialog-04-2023.png|about.xml PUI/XML dialog parsed/rendered via the [[Canvas GUI]] and the underlying XMLDialog.nas parser/translator (04-2023)
Logging-dialog-via-xmldialog-04-2023.png|logging.xml PUI/XML dialog parsed/rendered via the [[Canvas GUI]] and the underlying XMLDialog.nas parser/translator (04-2023)
Failures-dialog-via-xmldialog-04-2023.png|failures dialog-via-xmldialog-04-2023.png{{!}}thumb{{!}}logging.xml PUI/XML dialog parsed/rendered via the [[Canvas GUI]] and the underlying XMLDialog.nas parser/translator (04-2023)
Environment-dlg-via-canvas-bridge-04-2023.png|Screen shot showing the XMLDialog.nas bridge in use to parse/render the environment.xml PUI/XML dialog (unmodified)
</gallery>

=== Status ===
As of 01/2023, the replacement for PUI is making good progress<ref>https://sourceforge.net/p/flightgear/mailman/message/37765706/</ref>.

In February 2022, James reported having something in progress locally, and that should even be something we can try in March/April 2022. Hopefully that’s quick enough, knowing it has been a long time coming.<ref>https://sourceforge.net/p/flightgear/mailman/message/37606439/</ref>

There's now an XML to Nasal bridge, to keep PUI dialogs working (Disabled by a CMake option)
This is implemented on top of the [[Canvas]] system.

This builds equivalent C++ objects to what the [[PUI]] dialogs build, with properties exposed to Nasal.
Peer objects are created by Nasal [[callbacks]], which can implement the various dialog functions needed to keep compatibility, especially the [[#Background|‘update’ and ‘apply’ hooks]].<ref>https://sourceforge.net/p/flightgear/flightgear/ci/cbd5ef9e7b8f433dbc1ba97bae7d7cfc894e7cef/</ref>

{{Note|The PUI Compatible Canvas GUI is a compile time option: Use the following [[Building using CMake|cmake option]] to enable this code: {{CMake Build Option|option=ENABLE_PUICOMPAT|default=ON|description=This requires latest SG/FG AND FGDATA}}. But this is all highly fluid and most of it really developer only. At one point they will become default or be accessible in the launcher.<ref>https://sourceforge.net/p/flightgear/mailman/message/37834004/</ref>

If you compiled with PUICompatibility enabled, but still don't see any dialogs - only the menubar, you might need to enable the GUI module in defaults.xml:{{PropArg}}<ref>https://sourceforge.net/p/flightgear/mailman/message/37833149/</ref>}}

The new Compatibility files can now be found in $FG_SRC/GUI:

* {{flightgear file|src/GUI/FGPUICompatDialog.cxx }}
* {{flightgear file|src/GUI/FGPUICompatDialog.hxx }}
* {{flightgear file|src/GUI/PUICompatObject.cxx }}

01/2023: James is slowly working on creating the pop-up menu and combo-box widgets [...]

One of the major things slowing down James' work on the popup-menu and combo box is time to restart the simulator for each change, he is looking for some solution to re-load the widget Nasal code independently. <ref><https://sourceforge.net/p/flightgear/mailman/message/37756183/</ref>

James has done about 75% (hah!) of the C++ work to enable live reloading of modules this way, but unfortunately there are some code paths that would become crashy if you use the feature for the Canvas: because it would reference the ‘old’ (pre-reload) Nasal code, and not the new one, and therefore you’d get a weird mix of old and new, and then just crash the sim. To fix it properly I need to track down those places that store a reference to Canvas and give them a re-init method, so we don’t keep the stale references.

The general non-fun-ness of that kind of debugging is James has been making such slow progress on my PUI replacement widgets recently <ref>https://sourceforge.net/p/flightgear/mailman/message/37756263/</ref>

=== Todo ===
Nothing in particular: help debugging the grid layout (which is in simgear) would be good. For now, you could create a grid layout manually using some Nasal.

For the menubar, we need to expose the C++ data to Nasal: we need a FGCompatMenuBar (alongisde FGPUIMenuBar) implementing FGMenubar which calls _createMenuObject in MenuBar.nas, using the same way I lookup and call _createDialogPeer in XMLDialog.nas

(Make sure you don’t break the macOS native menubar in the process!)

You can probably pass a wrapped SGpropertyNode into this, and then fill in the stubs in that file to use the Menu widgets Frederic has written.

Global menu keybindings won’t worry but don’t touch that, I have a separate plan for it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37805736/</ref>

As of 04/2023, remaining items on the todo list are: <ref>https://sourceforge.net/p/flightgear/mailman/message/37805060/</ref>

* Grid layout
** GridLayout needs debugged: After this, the basic UI is usable, would probably make it a switchable option on ‘next’ (I can already use the simulator with the new UI today, but all the sizes are off in the grid layouts which we use everywhere)

* list
* table (and tree ?) models corresponding views
* waypoint list
* Re-write the waypoint list and airport dialog to work again (since these use custom widgets):
** log list
** airport-list equivalents
* Nasal access to the menu i18n functions
* selection support for single- and multi-line text (which is being worked on -> CanvasPangoText)
* Keyboard shortcut handling, although this is not really a PUI vs replacement issue, to me we should handle UI shortcuts in the same was normal keyboard.xml shortcuts
** this previously worked because PUI got ‘first chance’ at handling key input. But we always had duplication between keyboard.xml and other places, so I would rather standardise on keyboard.xml, but allow a UI element to set a scope for shortcuts. (So that Copy/paste shortcuts etc can work in a text input, at least … but probably some other standard ones) <ref>https://sourceforge.net/p/flightgear/mailman/message/37805188/</ref>
* Ensure all the places which use the PUI combo-box and list-widget work : there’s a few of these.

The CanvasPangoText stuff is needed but we can perfectly well run the UI on next without it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37805176/</ref>

=== Parser ===
{{Main article|pui2canvas}}
The corresponding Nasal/Canvas module to dynamically "translate" legacy PUI/XML dialogs into Canvas dialogs (at runtime), is to be found in {{fgdata file|Nasal/gui/XMLDialog.nas}} <ref>https://sourceforge.net/p/flightgear/fgdata/ci/fe7c87b21a69f88ddb87d89453c48d12b69660e2/</ref>

=== Widgets ===
{{Main article|Howto:Creating a Canvas GUI Widget}}

It’s split between Simgear (see classes with widget / layout in the name) and in FGData. (Eg widgets/Button.nas) To be able to use the existing dialog XML files un-modified (which is a design goal), James is extending the widget types with many additional ones (eg PUI has slider, dial, combo-box, checkbox, all of which need to be created, see [[Canvas widget matrix]].

This is about 30% done and is the bit he's very slow at). Thomas’s canvas widgets have a very good separation of API + state from appearance, so all styling is in its own file, and James is being very strict about maintaining this separation, so we also retain the re-styling feature of the PUI UI, which many people also rely on. This does make the process of adding new widgets more complex, however.

{{See also|Canvas widgets}}

=== Layouting ===
The other thing is to preserve all the layouting: James has added a grid layout to Simgear, since that is supported by the existing PUI code (even though the layouts are not actually part of PUI itself). The problem is getting the sizing / hinting of all the widgets to match the PUI values, so that dialogs look approximately the same under the new UI as they did with PUI; again this a design goal so that all existing dialogs in aircraft and add-ons, which we can’t update, continue to work and be usable. Debugging that is also proving quite tricky, since there’s all kinds of hard-coded assumptions built into PUI widgets about pixels, font-sizes etc which are not true in the new system.<ref>https://sourceforge.net/p/flightgear/mailman/message/37701792/</ref>

== Background ==
In FlightGear, PUI dialogs are standard [[PropertyList XML File]]s that are stored in $FG_ROOT/gui/dialogs, they can contain the widgets mentioned in {{readme file|gui}}, using a simple layout engine discussed in {{readme file|layout}}, and bindings using a combination of so called fgcommands operating on properties (see {{readme file|commands}}) and custom [[Nasal]] (FlightGear scripting) code.

In addition, each PUI/XML dialog may contain Nasal script sections that are executed when opening/closing the dialog, a feature which is commonly used for procedurally creating/updating widgets using the [[Nasal_library#cmdarg.28.29|cmdarg() API]], which allows the dialog tree to be traversed and manipulated prior to the dialog being rendered.
Widgets can be conditionally hidden/shown using a wrapper for [[Conditions|SGCondition]] in [[Nasal_library/props|props.nas]]
The <code>canvas</code> widget also supports its own embedded Nasal code section to execute arbitrary widget specific Nasal code upon opening/closing the dialog/widget.

PUI/XML dialogs can be loaded, dynamically created, updated and closed using a handful of fgcommands:
* {{fgcommand|dialog-new}}
* {{fgcommand|dialog-show}}
* {{fgcommand|dialog-update}}
* {{fgcommand|dialog-apply}}
* {{fgcommand|dialog-close}}

PUI related OpenGL code is particularly infamous for causing rendering artifacts for people on AMD/ATI and Intel hardware (especially in combination with certain fonts/styles and [[Effects|effects]]/[[Shaders|shaders]]), see {{Issue|2213}}.

PUI is also known to affect rendering performance quite significantly (see {{search |keywords=anthrax+gui}}), while also preventing FlightGear from using a more recent version of OpenGL<ref>http://sourceforge.net/p/flightgear/mailman/message/34532040/</ref><ref>http://forum.flightgear.org/viewtopic.php?f=71&t=24046</ref>.

However, improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Besides, while most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

But given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, graphics folks are also convinced it needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

In addition, [[OpenSceneGraph]] (OSG) can obviously not help optimize any PUI related GL code and PUI widgets are generally considered to be pretty archaic and not easy to extend<ref>http://sourceforge.net/p/flightgear/mailman/message/26832164/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587120/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587272/</ref>.

{{Note|We use the GUI code from PLIB, which doesn't know anything about OSG. See the SGPuDrawable class in $FG_SRC/Viewer/renderer.cxx for the implementation. The one catch is that OSG has a strong notion of separation between the update of a "scene" and its rendering, and that might not play well with arbitrary existing OpenGL code. }}

As of late 2015, there is heavy activity towards providing alternatives to a PUI-based UI:
* [[Integrated Web GUI]] (external, browser-based - fully asynchronous)
* [[Howto:Processing legacy PUI dialogs using Canvas]] (internal, using the [[Canvas]] system and a simple [[Nasal]] parser to deal with existing PUI/XML dialogs)

<gallery mode="packed">
Early-Phi-screen shot.PNG|Screenshot showing [[Phi]]
About-dialog-rendered-by-canvas.png|Screenshot showing a dialog rendered by the [[Howto:Processing legacy PUI dialogs using Canvas|pui2canvas parser]]
</gallery>

== History ==
{{See also|QtQuick use in FlightGear}}
{{Caution|This is merely kept for future reference, many of the ideas discussed below have become obsolete as of 09/2022, if in doubt, please get in touch via devel-list.}}
=== 2021 ===
In early 2021, James did a brief evaluation of [https://github.com/ocornut/imgui ImGUI] as a possibility - he's also evaluating it in some projects at his day job.

The API is interesting if you’re starting from scratch and only exclusively in C++, but it’s not a great fit for how we define GUIs in FG (via [[XML]]/[[Nasal]]): there is no back door that he could find, to access the persistent state of the GUI, or build it up in a data-driven way. So making a mapping to keep our existing GUI XML working (and updating correctly) becomes a bit of a chore.<ref>https://sourceforge.net/p/flightgear/mailman/message/37295586/</ref>

Pretty much all of the FlightGear GUI is defined in XML space, except for a few oddments. Let’s say 95% at this point.

Additionally, even if we were to change that for the core sim (and James' current plan is to keep the XML syntax and just extend it), the installed base of '''aircraft''' ship their own XML dialogs (eg., replacing the autopilot dialog with a custom one, or just adding their own aircraft-specific helper controls for doors / lights / cargo / whatever). So even if we found the most sublimely beautiful, intuitive, compact GUI description language in the world, we have to keep the XML syntax working as-is, for the foreseeable future.

Given this, James' intention is to replace the output side [[PUI]] but keep the front-end side (XML / properties / bindings) unchanged, and therefore backwards compatible, and simply add some new types / options / widget types going forward. This will mean we still have to deal with the slightly cumbersome XML+Nasal syntax, but, well, it’s not *that* cumbersome. <ref>https://sourceforge.net/p/flightgear/mailman/message/37296280/</ref>

In mid 2021, James reported that he is working on some ‘PUICompat’ classes which hold/own/represent the GUI state in C++, but which can be used with [[Nasal/CppBind|Nasal CppBind]]. And of course we could indeed expose those later on. <ref>https://sourceforge.net/p/flightgear/mailman/message/37297727/</ref>

In July 2021, James suggested not to worry about the existing GUI code, it’s going in the bin.<ref>https://sourceforge.net/p/flightgear/mailman/message/37325905/</ref>

For the time being, the in-sim GUi can’t do Unicode yet, but James is working on it, hopefully available soon.<ref>https://sourceforge.net/p/flightgear/mailman/message/37328200/</ref>
Also, the in-sim menubar will change with the new GUI, *and* we use a native menubar on macOS. Until James replaces the PUI fonts we can’t use Unicode symbols. So, will have to come back to it once the new GUI is merged.<ref>https://sourceforge.net/p/flightgear/mailman/message/37327237/</ref>

=== 2020 ===
As of 03/2020, the PLIB replacement was reported to be in the backlog <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36951255/
|title = <nowiki>Re: [Flightgear-devel] C++ and/or OSG question </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Mar 18th, 2020
|added = Mar 18th, 2020
|script_version = 0.50
}}</ref>.

With PLIB replacement work likely being re-scheduled for [[Post FlightGear 2020.2 LTS changes]] <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36985375/
|title = <nowiki>Re: [Flightgear-devel] Working Group Proposal - Boost and PLIB replacement - Delegation and Teamwork </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = April 18th, 2020
|added = April 18th, 2020
|script_version = 1.10
}}</ref>.

In 08/2020, James stated that he was still working (exceptionally slowly!) on replacing PUI (as part of removing legacy OpenGL code (PUI, HUD, 2d panels, porting Canvas away form ShivaVG), so we can switch to Vulkan/VSG at some point (ideally at some point before Apple turn off OpenGL support…)), and that he doesn't think /any/ of us *want* to be working on these features particularly, but projects like these need to be done before anyone can have fun with VSG or Vulkan (personally James would be very enthusiastic about working on VSG support (being on macOS, I also have the most to lose / gain from it)). Sometimes that’s just how it goes. Equally they will all benefit the project ultimately, but the payoff both for the individual and the project is very drawn out. <ref>https://sourceforge.net/p/flightgear/mailman/message/37077158/</ref>

In 10/2020, the estimation is that PUI should be going away really ‘soon’, the replacement code is already in next / 2020.2. (There’s no plan to actually /use/ the new UI code in 2020.2, but if the bugs in it prove simple, we could actually turn it for specific dialog: it seems very unlikely this makes sense for a stable release however)<ref>https://sourceforge.net/p/flightgear/mailman/message/37123818/</ref>

The fixed-function removal, is actively in hand (Gaetan is working on the 2D panel part, and James is going to focus on PUI in the rest of 2020). James hopes that means next year he can focus on Vulkan, or at least, using OSG as if /were/ VSG, so the migration in a year or two when VSG is stable, is not so painful.<ref>https://sourceforge.net/p/flightgear/mailman/message/37129098/</ref>

The PUI UI and replacement can co-exist in the same build (they already do, effectively.<ref>https://sourceforge.net/p/flightgear/mailman/message/37131297/</ref>

In 11/2020, James suggested not to worry about details such as PUI styling/theming etc: we’re not making such changes for the LTS, and PUI should be gone before the next release.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142225/</ref> Also, he recommended (to everyone) to stop touching GUI stuff for a few weeks, as he's about to turn it all on its head.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142356/</ref>

=== 2019 ===
The new GUI has been incubating for a few years, but there's apparently been a lot of progress as of 10/2019.

It is likely the new GUI will be a user opt-in feature - at least initially. The sunset of the PLIB library _could_ happen relatively soon, but
people will need to see the new GUI and react to it before we could commit to PLIB removal <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36784489/
|title = <nowiki>Re: [Flightgear-devel] in Flightgear/Simgear C++ Code: What needs Doing? What are YOU Doing? What would you do if you had the time? </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Oct 14th, 2019
|added = Oct 14th, 2019
|script_version = 0.50
}}</ref>.

In 02/2019, James stated that the new UI is coming quite soon. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36589420/
|title = <nowiki> Re: [Flightgear-devel] Lagging </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Feb 17th, 2019
|added = Feb 17th, 2019
|script_version = 0.40
}}</ref>

=== 2018 ===
{{See also|QtQuick use in FlightGear}}

According to James, we have to accept that changes like testing or making [[PUI]] a modular thing or moving the JS code tend to have an immediate pain for some people (because strange stuff gets broken, and takes some time to get fixed), whereas the payoff in terms of improved joystick handling or replacing the UI or testing of all subsystems will take some months or years to be felt.<ref>https://sourceforge.net/p/flightgear/mailman/message/36323240/</ref>

James said he was in the middle of porting the launcher’s final tab (location) to the new UI scheme, once that’s done he will start sketching out the ‘in sim’ settings UI using the same pieces. He’ll send a request for contributions around about that in the next three-four weeks, once he has enough templates & examples that there is a clear pattern to follow.<ref>https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/2d10f16c-ddc8-07f3-07e7-eca2a0a0d55f%40zaretto.com/#msg36293586</ref>

James announced that the launcher is now feature complete with the QtQuick UI, he’ll keep making bug-fixes of course as people report them, but my todo list for the core features is now done<ref>https://sourceforge.net/p/flightgear/mailman/message/36355833/</ref>.

=== 2017 ===

In 10/2017, James said he was getting really close to having the PUI replacement UI suitable for beta-testing.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36067646/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 7th, 2017
|added = Oct 7th, 2017
|script_version = 0.40
}}</ref>

Originally, James was hoping to land the PUI replacement GUI in the last dev cycle in 2017 (at least as a proof-of-concept, probably not as the default UI), so wouldn’t expend lots of effort on things like collapsible sections which might be a lot of work with the current PUI/Canvas approaches, but are trivial with the new [[QtQuick use in FlightGear|QtQuick based UI scheme]].<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36059822/
|title = <nowiki> Re: [Flightgear-devel] Canvas MapLayer for OpenStreetMap, OpenAIP,
VFR Sectionals </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 1st, 2017
|added = Oct 1st, 2017
|script_version = 0.40
}}</ref>

Once the basic new UI is in place we can experiment with different re-arrangements easily, without being limited by PUI. (James expects PUI to live on as the default / alternate UI while this happens)<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36061229/
|title = <nowiki> Re: [Flightgear-devel] FGFS macOS Menubar </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 2nd, 2017
|added = Oct 2nd, 2017
|script_version = 0.40
}}</ref>

Technically, this entails replacing dialog.cxx with some code which builds up some special ‘PUI-Emulation’ QtQuick controls, so that existing dialogs (especially from Aircraft) continue to work. This mode will look somewhat ugly but hopefully no more ugly than PUI! And it helps that the set of widgets we have in PUI is limited, and the ‘tricky’ widgets (map, scrolling list, etc) are in the dialogs will will replace with new ones first.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068767/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

This PUI emulation isn't going to use any code from PLIB<ref>https://sourceforge.net/p/flightgear/mailman/message/36985303/</ref>, so what will remain from it in FG afterwards will be the FNT and JS components (reworked).<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068817/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> Florent Rougon </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

=== 2016 ===
We need to explore if Qt Quick or widgets is the better way to go, with a preference towards Qt Quick, since it will allow things closer to current PUI (semi-transparent widgets on top of the 3D content). It still allows creating separate windows too (Erik’s use case), but means we get consistent, custom theming on all platforms, since standard desktop look is not so nice for a flight-sim.

James intention is to make a QML-hosting OSG-drawable, and add this as a concept in Qt-enabled builds, then port some PUI dialogs to it, and see how easy / painful the process is. Hell create some QObjects which expose commands and the property tree and Nasal.

This has the advantage of not touching the OSG window at all, QtQuick simply provides some additional OpenGL rendering on top, which we pass events to - pretty much exactly the same as what we already do for PUI, and hopefully can co-exist with it. James got this working in a local OSG tree in a standalone demo, but that’s based on osgQt - he wants to see if he can make it work on a normal, non-Qt OSG window inside FlightGear.<ref>https://sourceforge.net/p/flightgear/mailman/message/35156051/</ref>

The idea is to host an XML dialog (Currently done with PUI) from Qt also. The question is if that can be done keeping ‘source compatibility’ exactly with the current UI XML and Nasal interface. It probably can be, but many of the PUI widgets have really ugly APIs, especially for combo-boxes, drop-down menus and scrolling lists, where it makes sense to map a Nasal class to a Qt ItemModel, which would be more elegant and easy to work with in both Nasal and integrate on the Qt side. But obviously would mean changing the dialog sources.

Of course, aircraft dialogs tend to be simpler, and not use the more complex PUI widgets, precisely for reasons like this, but that’s a limitation it would be best to remove.<ref>https://sourceforge.net/p/flightgear/mailman/message/35155721/</ref>


== References ==
{{Appendix}}

[[Category:PUI| ]]
[[Category:Rendering roadblocks]]

Template:PropArg

2023-04-22T17:42:50Z

Hooray: Created page with "<code>--prop:{{{property|/nasal/gui}}}={{{value|1}}}</code> <noinclude>{{Stub}}</noinclude>"

<code>--prop:{{{property|/nasal/gui}}}={{{value|1}}}</code>
<noinclude>{{Stub}}</noinclude>

PUI

2023-04-22T09:43:57Z

Hooray: /* Canvas Emulation */

{{Feature to be removed|version=2023.3|reason=[[Plib]]/PUI is to be removed and replaced by a [[Canvas widget matrix|Canvas/Nasal based solution]] to help improve compatibility with [[OSG]] 3.6+ and [[OpenGL]] 4.x ([[Core Profile support|OpenGL Core Profile]], see [[2022.X Release plan]] ) and improve performance by [[Unifying the 2D rendering backend via canvas|phasing out legacy OpenGL code]]. Therefore, people should be careful when extending the '''PUI''' based legacy GUI engine<ref>https://sourceforge.net/p/flightgear/mailman/message/34921495/</ref><ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35157325/
|title = <nowiki> Re: [Flightgear-devel] GUI options (Was: Aircraft center) </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jun 14th, 2016
|added = Jun 14th, 2016
|script_version = 0.40
}}</ref> and coordinate any related work with the devel mailing list first-this applies particularly to adding any [[Template:PUI_widget|additional hard-coded PUI widgets]]. }}
[[File:Exit.png|thumb|FlightGear GUI dialog (exit.xml)stored in $FG_ROOT/gui/dialogs]]
{{GUI Navbar}}

[[File:Custom-autopilot-dialog.png|right|200px]]
[[PUI]] is the standard GUI engine used in FlightGear, it is part of [[PLIB]] and is using raw, fixed-pipeline, [[OpenGL]] code internally (no [[OpenSceneGraph]]). As of mid 2021, FlightGear is in the process of working towards adopting the OpenGL Core Profile, this means that [[PUI]] is causing trouble and needs to be replaced/disabled or ported.

PUI provides a fairly basic, but robust, set of widgets. PUI is also used for rendering the [[Menubar]].

FlightGear uses a GUI widget set that is implemented on top of raw (legacy) [[OpenGL]]. This has many advantages from a portability standpoint and from the standpoint of integrating with window systems. [[PUI]] doesn't have every feature under the sun, but it was never meant to. It's relatively small, lean, mean, and written on top of [[OpenGL]] which makes life *much* easier for us.

[[PUI]] already is a separate distinct library within Plib. It depends on some central utility stuff, but that's about it. So it is pretty stripped down and separate already.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg26011.html</ref>

We are to some extent hamstrung by the rather old GUI toolkit we use. However, replacing that is going to be non-trivial, and it would affect not just the core GUI but also all the dialog boxes that have been set up for particular aircraft.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg25985.html</ref>

Flightgear can look amazing when you use the HDR pipeline. We absolutely need this to stay relevant. The problem is that HDR is not compatible with OpenGL1 PUI. Work on getting rid of PUI has been going on for over a decade (longer than it took to implement it).<ref>https://sourceforge.net/p/flightgear/mailman/message/37727346/</ref>

[[File:menubar2.jpg|517px]]

== Replacement status ==
{{See also|FlightGear_and_OpenGL_ES#Example:_disabling_PUI}}

{{Note| Update 09/2022: The PUI replacement [[QtQuick_use_in_FlightGear#Background|was going to be Qt]] but it started to get very complicated with changes in Qt 5.15 + Qt 6, so James is going with a more light-weight Canvas based approach now.

Qt added support for Vulkan / Metal / D3D starting in 5.15, but FlightGear / OpenSceneGraph can’t support those, so integrating the two renderers went from being ‘complicated but ok’ to ‘very very complicated’.

So now James is going with something much more lightweight using some C++ compatibility code, some Nasal for styling and the existing [[Canvas widgets|Canvas widget rendering]] from Thomas Geymayer (TheTom) with [[Canvas Widget Matrix|some extensions and additions]], based on the [[Howto:Processing_legacy_PUI_dialogs_using_Canvas#Original_Discussion|plans originally discussed when the Canvas GUI system was added to FlightGear]]: some pieces are in FlightGear & FGData already.

James has basic dialogs working okay but not the more complex ones and everything looks kind of ugly, he needs to improve the visual look before he shares screenshots to avoid everyone freaking out :) The disadvantage of this approach is James is far from expert at creating visual appearances this way, so it’s kind on unrewarding and slow for him. If someone likes messing with CSS-type styling, border-images and hover-states, ping him since we could probably move things also faster <ref>https://sourceforge.net/p/flightgear/mailman/message/37701750/</ref>}}

=== Motivation ===
{{Main article|Core Profile support}}

The bigger issue here is we need to ditch [[PUI]] (which is in progress) and some OpenGL 1.0 code (HUD, 2D panels especially - can be #ifdef for now) so we can enable Core profile on Mac - since Mac 4.x support (we only hit about 4.3 alas, but with some extensions to get in sight of 4.5) is Core profile only, no Compatability mode.

Improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, many people are convinced PUI needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

While most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so [using Qt5] would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

== Canvas Emulation ==
{{See also|Canvas widget matrix}}
'''Last updated: 04/2023 <ref>https://sourceforge.net/p/flightgear/mailman/message/37805054/</ref>
'''
=== Gallery ===

<gallery>
About-dialog-xmldialog-04-2023.png|about.xml PUI/XML dialog parsed/rendered via the [[Canvas GUI]] and the underlying XMLDialog.nas parser/translator (04-2023)
Logging-dialog-via-xmldialog-04-2023.png|logging.xml PUI/XML dialog parsed/rendered via the [[Canvas GUI]] and the underlying XMLDialog.nas parser/translator (04-2023)
Failures-dialog-via-xmldialog-04-2023.png|failures dialog-via-xmldialog-04-2023.png{{!}}thumb{{!}}logging.xml PUI/XML dialog parsed/rendered via the [[Canvas GUI]] and the underlying XMLDialog.nas parser/translator (04-2023)
Environment-dlg-via-canvas-bridge-04-2023.png|Screen shot showing the XMLDialog.nas bridge in use to parse/render the environment.xml PUI/XML dialog (unmodified)
</gallery>

=== Status ===
As of 01/2023, the replacement for PUI is making good progress<ref>https://sourceforge.net/p/flightgear/mailman/message/37765706/</ref>.

In February 2022, James reported having something in progress locally, and that should even be something we can try in March/April 2022. Hopefully that’s quick enough, knowing it has been a long time coming.<ref>https://sourceforge.net/p/flightgear/mailman/message/37606439/</ref>

There's now an XML to Nasal bridge, to keep PUI dialogs working (Disabled by a CMake option)
This is implemented on top of the [[Canvas]] system.

This builds equivalent C++ objects to what the [[PUI]] dialogs build, with properties exposed to Nasal.
Peer objects are created by Nasal [[callbacks]], which can implement the various dialog functions needed to keep compatibility, especially the [[#Background|‘update’ and ‘apply’ hooks]].<ref>https://sourceforge.net/p/flightgear/flightgear/ci/cbd5ef9e7b8f433dbc1ba97bae7d7cfc894e7cef/</ref>

{{Note|The PUI Compatible Canvas GUI is a compile time option: Use the following [[Building using CMake|cmake option]] to enable this code: {{CMake Build Option|option=ENABLE_PUICOMPAT|default=ON|description=This requires latest SG/FG AND FGDATA}}. But this is all highly fluid and most of it really developer only. At one point they will become default or be accessible in the launcher.<ref>https://sourceforge.net/p/flightgear/mailman/message/37834004/</ref>

If you compiled with PUICompatibility enabled, but still don't see any dialogs - only the menubar, you might need to enable the GUI module in defaults.xml<ref>https://sourceforge.net/p/flightgear/mailman/message/37833149/</ref>}}

The new Compatibility files can now be found in $FG_SRC/GUI:

* {{flightgear file|src/GUI/FGPUICompatDialog.cxx }}
* {{flightgear file|src/GUI/FGPUICompatDialog.hxx }}
* {{flightgear file|src/GUI/PUICompatObject.cxx }}

01/2023: James is slowly working on creating the pop-up menu and combo-box widgets [...]

One of the major things slowing down James' work on the popup-menu and combo box is time to restart the simulator for each change, he is looking for some solution to re-load the widget Nasal code independently. <ref><https://sourceforge.net/p/flightgear/mailman/message/37756183/</ref>

James has done about 75% (hah!) of the C++ work to enable live reloading of modules this way, but unfortunately there are some code paths that would become crashy if you use the feature for the Canvas: because it would reference the ‘old’ (pre-reload) Nasal code, and not the new one, and therefore you’d get a weird mix of old and new, and then just crash the sim. To fix it properly I need to track down those places that store a reference to Canvas and give them a re-init method, so we don’t keep the stale references.

The general non-fun-ness of that kind of debugging is James has been making such slow progress on my PUI replacement widgets recently <ref>https://sourceforge.net/p/flightgear/mailman/message/37756263/</ref>

=== Todo ===
Nothing in particular: help debugging the grid layout (which is in simgear) would be good. For now, you could create a grid layout manually using some Nasal.

For the menubar, we need to expose the C++ data to Nasal: we need a FGCompatMenuBar (alongisde FGPUIMenuBar) implementing FGMenubar which calls _createMenuObject in MenuBar.nas, using the same way I lookup and call _createDialogPeer in XMLDialog.nas

(Make sure you don’t break the macOS native menubar in the process!)

You can probably pass a wrapped SGpropertyNode into this, and then fill in the stubs in that file to use the Menu widgets Frederic has written.

Global menu keybindings won’t worry but don’t touch that, I have a separate plan for it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37805736/</ref>

As of 04/2023, remaining items on the todo list are: <ref>https://sourceforge.net/p/flightgear/mailman/message/37805060/</ref>

* Grid layout
** GridLayout needs debugged: After this, the basic UI is usable, would probably make it a switchable option on ‘next’ (I can already use the simulator with the new UI today, but all the sizes are off in the grid layouts which we use everywhere)

* list
* table (and tree ?) models corresponding views
* waypoint list
* Re-write the waypoint list and airport dialog to work again (since these use custom widgets):
** log list
** airport-list equivalents
* Nasal access to the menu i18n functions
* selection support for single- and multi-line text (which is being worked on -> CanvasPangoText)
* Keyboard shortcut handling, although this is not really a PUI vs replacement issue, to me we should handle UI shortcuts in the same was normal keyboard.xml shortcuts
** this previously worked because PUI got ‘first chance’ at handling key input. But we always had duplication between keyboard.xml and other places, so I would rather standardise on keyboard.xml, but allow a UI element to set a scope for shortcuts. (So that Copy/paste shortcuts etc can work in a text input, at least … but probably some other standard ones) <ref>https://sourceforge.net/p/flightgear/mailman/message/37805188/</ref>
* Ensure all the places which use the PUI combo-box and list-widget work : there’s a few of these.

The CanvasPangoText stuff is needed but we can perfectly well run the UI on next without it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37805176/</ref>

=== Parser ===
{{Main article|pui2canvas}}
The corresponding Nasal/Canvas module to dynamically "translate" legacy PUI/XML dialogs into Canvas dialogs (at runtime), is to be found in {{fgdata file|Nasal/gui/XMLDialog.nas}} <ref>https://sourceforge.net/p/flightgear/fgdata/ci/fe7c87b21a69f88ddb87d89453c48d12b69660e2/</ref>

=== Widgets ===
{{Main article|Howto:Creating a Canvas GUI Widget}}

It’s split between Simgear (see classes with widget / layout in the name) and in FGData. (Eg widgets/Button.nas) To be able to use the existing dialog XML files un-modified (which is a design goal), James is extending the widget types with many additional ones (eg PUI has slider, dial, combo-box, checkbox, all of which need to be created, see [[Canvas widget matrix]].

This is about 30% done and is the bit he's very slow at). Thomas’s canvas widgets have a very good separation of API + state from appearance, so all styling is in its own file, and James is being very strict about maintaining this separation, so we also retain the re-styling feature of the PUI UI, which many people also rely on. This does make the process of adding new widgets more complex, however.

{{See also|Canvas widgets}}

=== Layouting ===
The other thing is to preserve all the layouting: James has added a grid layout to Simgear, since that is supported by the existing PUI code (even though the layouts are not actually part of PUI itself). The problem is getting the sizing / hinting of all the widgets to match the PUI values, so that dialogs look approximately the same under the new UI as they did with PUI; again this a design goal so that all existing dialogs in aircraft and add-ons, which we can’t update, continue to work and be usable. Debugging that is also proving quite tricky, since there’s all kinds of hard-coded assumptions built into PUI widgets about pixels, font-sizes etc which are not true in the new system.<ref>https://sourceforge.net/p/flightgear/mailman/message/37701792/</ref>

== Background ==
In FlightGear, PUI dialogs are standard [[PropertyList XML File]]s that are stored in $FG_ROOT/gui/dialogs, they can contain the widgets mentioned in {{readme file|gui}}, using a simple layout engine discussed in {{readme file|layout}}, and bindings using a combination of so called fgcommands operating on properties (see {{readme file|commands}}) and custom [[Nasal]] (FlightGear scripting) code.

In addition, each PUI/XML dialog may contain Nasal script sections that are executed when opening/closing the dialog, a feature which is commonly used for procedurally creating/updating widgets using the [[Nasal_library#cmdarg.28.29|cmdarg() API]], which allows the dialog tree to be traversed and manipulated prior to the dialog being rendered.
Widgets can be conditionally hidden/shown using a wrapper for [[Conditions|SGCondition]] in [[Nasal_library/props|props.nas]]
The <code>canvas</code> widget also supports its own embedded Nasal code section to execute arbitrary widget specific Nasal code upon opening/closing the dialog/widget.

PUI/XML dialogs can be loaded, dynamically created, updated and closed using a handful of fgcommands:
* {{fgcommand|dialog-new}}
* {{fgcommand|dialog-show}}
* {{fgcommand|dialog-update}}
* {{fgcommand|dialog-apply}}
* {{fgcommand|dialog-close}}

PUI related OpenGL code is particularly infamous for causing rendering artifacts for people on AMD/ATI and Intel hardware (especially in combination with certain fonts/styles and [[Effects|effects]]/[[Shaders|shaders]]), see {{Issue|2213}}.

PUI is also known to affect rendering performance quite significantly (see {{search |keywords=anthrax+gui}}), while also preventing FlightGear from using a more recent version of OpenGL<ref>http://sourceforge.net/p/flightgear/mailman/message/34532040/</ref><ref>http://forum.flightgear.org/viewtopic.php?f=71&t=24046</ref>.

However, improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Besides, while most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

But given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, graphics folks are also convinced it needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

In addition, [[OpenSceneGraph]] (OSG) can obviously not help optimize any PUI related GL code and PUI widgets are generally considered to be pretty archaic and not easy to extend<ref>http://sourceforge.net/p/flightgear/mailman/message/26832164/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587120/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587272/</ref>.

{{Note|We use the GUI code from PLIB, which doesn't know anything about OSG. See the SGPuDrawable class in $FG_SRC/Viewer/renderer.cxx for the implementation. The one catch is that OSG has a strong notion of separation between the update of a "scene" and its rendering, and that might not play well with arbitrary existing OpenGL code. }}

As of late 2015, there is heavy activity towards providing alternatives to a PUI-based UI:
* [[Integrated Web GUI]] (external, browser-based - fully asynchronous)
* [[Howto:Processing legacy PUI dialogs using Canvas]] (internal, using the [[Canvas]] system and a simple [[Nasal]] parser to deal with existing PUI/XML dialogs)

<gallery mode="packed">
Early-Phi-screen shot.PNG|Screenshot showing [[Phi]]
About-dialog-rendered-by-canvas.png|Screenshot showing a dialog rendered by the [[Howto:Processing legacy PUI dialogs using Canvas|pui2canvas parser]]
</gallery>

== History ==
{{See also|QtQuick use in FlightGear}}
{{Caution|This is merely kept for future reference, many of the ideas discussed below have become obsolete as of 09/2022, if in doubt, please get in touch via devel-list.}}
=== 2021 ===
In early 2021, James did a brief evaluation of [https://github.com/ocornut/imgui ImGUI] as a possibility - he's also evaluating it in some projects at his day job.

The API is interesting if you’re starting from scratch and only exclusively in C++, but it’s not a great fit for how we define GUIs in FG (via [[XML]]/[[Nasal]]): there is no back door that he could find, to access the persistent state of the GUI, or build it up in a data-driven way. So making a mapping to keep our existing GUI XML working (and updating correctly) becomes a bit of a chore.<ref>https://sourceforge.net/p/flightgear/mailman/message/37295586/</ref>

Pretty much all of the FlightGear GUI is defined in XML space, except for a few oddments. Let’s say 95% at this point.

Additionally, even if we were to change that for the core sim (and James' current plan is to keep the XML syntax and just extend it), the installed base of '''aircraft''' ship their own XML dialogs (eg., replacing the autopilot dialog with a custom one, or just adding their own aircraft-specific helper controls for doors / lights / cargo / whatever). So even if we found the most sublimely beautiful, intuitive, compact GUI description language in the world, we have to keep the XML syntax working as-is, for the foreseeable future.

Given this, James' intention is to replace the output side [[PUI]] but keep the front-end side (XML / properties / bindings) unchanged, and therefore backwards compatible, and simply add some new types / options / widget types going forward. This will mean we still have to deal with the slightly cumbersome XML+Nasal syntax, but, well, it’s not *that* cumbersome. <ref>https://sourceforge.net/p/flightgear/mailman/message/37296280/</ref>

In mid 2021, James reported that he is working on some ‘PUICompat’ classes which hold/own/represent the GUI state in C++, but which can be used with [[Nasal/CppBind|Nasal CppBind]]. And of course we could indeed expose those later on. <ref>https://sourceforge.net/p/flightgear/mailman/message/37297727/</ref>

In July 2021, James suggested not to worry about the existing GUI code, it’s going in the bin.<ref>https://sourceforge.net/p/flightgear/mailman/message/37325905/</ref>

For the time being, the in-sim GUi can’t do Unicode yet, but James is working on it, hopefully available soon.<ref>https://sourceforge.net/p/flightgear/mailman/message/37328200/</ref>
Also, the in-sim menubar will change with the new GUI, *and* we use a native menubar on macOS. Until James replaces the PUI fonts we can’t use Unicode symbols. So, will have to come back to it once the new GUI is merged.<ref>https://sourceforge.net/p/flightgear/mailman/message/37327237/</ref>

=== 2020 ===
As of 03/2020, the PLIB replacement was reported to be in the backlog <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36951255/
|title = <nowiki>Re: [Flightgear-devel] C++ and/or OSG question </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Mar 18th, 2020
|added = Mar 18th, 2020
|script_version = 0.50
}}</ref>.

With PLIB replacement work likely being re-scheduled for [[Post FlightGear 2020.2 LTS changes]] <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36985375/
|title = <nowiki>Re: [Flightgear-devel] Working Group Proposal - Boost and PLIB replacement - Delegation and Teamwork </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = April 18th, 2020
|added = April 18th, 2020
|script_version = 1.10
}}</ref>.

In 08/2020, James stated that he was still working (exceptionally slowly!) on replacing PUI (as part of removing legacy OpenGL code (PUI, HUD, 2d panels, porting Canvas away form ShivaVG), so we can switch to Vulkan/VSG at some point (ideally at some point before Apple turn off OpenGL support…)), and that he doesn't think /any/ of us *want* to be working on these features particularly, but projects like these need to be done before anyone can have fun with VSG or Vulkan (personally James would be very enthusiastic about working on VSG support (being on macOS, I also have the most to lose / gain from it)). Sometimes that’s just how it goes. Equally they will all benefit the project ultimately, but the payoff both for the individual and the project is very drawn out. <ref>https://sourceforge.net/p/flightgear/mailman/message/37077158/</ref>

In 10/2020, the estimation is that PUI should be going away really ‘soon’, the replacement code is already in next / 2020.2. (There’s no plan to actually /use/ the new UI code in 2020.2, but if the bugs in it prove simple, we could actually turn it for specific dialog: it seems very unlikely this makes sense for a stable release however)<ref>https://sourceforge.net/p/flightgear/mailman/message/37123818/</ref>

The fixed-function removal, is actively in hand (Gaetan is working on the 2D panel part, and James is going to focus on PUI in the rest of 2020). James hopes that means next year he can focus on Vulkan, or at least, using OSG as if /were/ VSG, so the migration in a year or two when VSG is stable, is not so painful.<ref>https://sourceforge.net/p/flightgear/mailman/message/37129098/</ref>

The PUI UI and replacement can co-exist in the same build (they already do, effectively.<ref>https://sourceforge.net/p/flightgear/mailman/message/37131297/</ref>

In 11/2020, James suggested not to worry about details such as PUI styling/theming etc: we’re not making such changes for the LTS, and PUI should be gone before the next release.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142225/</ref> Also, he recommended (to everyone) to stop touching GUI stuff for a few weeks, as he's about to turn it all on its head.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142356/</ref>

=== 2019 ===
The new GUI has been incubating for a few years, but there's apparently been a lot of progress as of 10/2019.

It is likely the new GUI will be a user opt-in feature - at least initially. The sunset of the PLIB library _could_ happen relatively soon, but
people will need to see the new GUI and react to it before we could commit to PLIB removal <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36784489/
|title = <nowiki>Re: [Flightgear-devel] in Flightgear/Simgear C++ Code: What needs Doing? What are YOU Doing? What would you do if you had the time? </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Oct 14th, 2019
|added = Oct 14th, 2019
|script_version = 0.50
}}</ref>.

In 02/2019, James stated that the new UI is coming quite soon. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36589420/
|title = <nowiki> Re: [Flightgear-devel] Lagging </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Feb 17th, 2019
|added = Feb 17th, 2019
|script_version = 0.40
}}</ref>

=== 2018 ===
{{See also|QtQuick use in FlightGear}}

According to James, we have to accept that changes like testing or making [[PUI]] a modular thing or moving the JS code tend to have an immediate pain for some people (because strange stuff gets broken, and takes some time to get fixed), whereas the payoff in terms of improved joystick handling or replacing the UI or testing of all subsystems will take some months or years to be felt.<ref>https://sourceforge.net/p/flightgear/mailman/message/36323240/</ref>

James said he was in the middle of porting the launcher’s final tab (location) to the new UI scheme, once that’s done he will start sketching out the ‘in sim’ settings UI using the same pieces. He’ll send a request for contributions around about that in the next three-four weeks, once he has enough templates & examples that there is a clear pattern to follow.<ref>https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/2d10f16c-ddc8-07f3-07e7-eca2a0a0d55f%40zaretto.com/#msg36293586</ref>

James announced that the launcher is now feature complete with the QtQuick UI, he’ll keep making bug-fixes of course as people report them, but my todo list for the core features is now done<ref>https://sourceforge.net/p/flightgear/mailman/message/36355833/</ref>.

=== 2017 ===

In 10/2017, James said he was getting really close to having the PUI replacement UI suitable for beta-testing.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36067646/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 7th, 2017
|added = Oct 7th, 2017
|script_version = 0.40
}}</ref>

Originally, James was hoping to land the PUI replacement GUI in the last dev cycle in 2017 (at least as a proof-of-concept, probably not as the default UI), so wouldn’t expend lots of effort on things like collapsible sections which might be a lot of work with the current PUI/Canvas approaches, but are trivial with the new [[QtQuick use in FlightGear|QtQuick based UI scheme]].<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36059822/
|title = <nowiki> Re: [Flightgear-devel] Canvas MapLayer for OpenStreetMap, OpenAIP,
VFR Sectionals </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 1st, 2017
|added = Oct 1st, 2017
|script_version = 0.40
}}</ref>

Once the basic new UI is in place we can experiment with different re-arrangements easily, without being limited by PUI. (James expects PUI to live on as the default / alternate UI while this happens)<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36061229/
|title = <nowiki> Re: [Flightgear-devel] FGFS macOS Menubar </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 2nd, 2017
|added = Oct 2nd, 2017
|script_version = 0.40
}}</ref>

Technically, this entails replacing dialog.cxx with some code which builds up some special ‘PUI-Emulation’ QtQuick controls, so that existing dialogs (especially from Aircraft) continue to work. This mode will look somewhat ugly but hopefully no more ugly than PUI! And it helps that the set of widgets we have in PUI is limited, and the ‘tricky’ widgets (map, scrolling list, etc) are in the dialogs will will replace with new ones first.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068767/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

This PUI emulation isn't going to use any code from PLIB<ref>https://sourceforge.net/p/flightgear/mailman/message/36985303/</ref>, so what will remain from it in FG afterwards will be the FNT and JS components (reworked).<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068817/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> Florent Rougon </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

=== 2016 ===
We need to explore if Qt Quick or widgets is the better way to go, with a preference towards Qt Quick, since it will allow things closer to current PUI (semi-transparent widgets on top of the 3D content). It still allows creating separate windows too (Erik’s use case), but means we get consistent, custom theming on all platforms, since standard desktop look is not so nice for a flight-sim.

James intention is to make a QML-hosting OSG-drawable, and add this as a concept in Qt-enabled builds, then port some PUI dialogs to it, and see how easy / painful the process is. Hell create some QObjects which expose commands and the property tree and Nasal.

This has the advantage of not touching the OSG window at all, QtQuick simply provides some additional OpenGL rendering on top, which we pass events to - pretty much exactly the same as what we already do for PUI, and hopefully can co-exist with it. James got this working in a local OSG tree in a standalone demo, but that’s based on osgQt - he wants to see if he can make it work on a normal, non-Qt OSG window inside FlightGear.<ref>https://sourceforge.net/p/flightgear/mailman/message/35156051/</ref>

The idea is to host an XML dialog (Currently done with PUI) from Qt also. The question is if that can be done keeping ‘source compatibility’ exactly with the current UI XML and Nasal interface. It probably can be, but many of the PUI widgets have really ugly APIs, especially for combo-boxes, drop-down menus and scrolling lists, where it makes sense to map a Nasal class to a Qt ItemModel, which would be more elegant and easy to work with in both Nasal and integrate on the Qt side. But obviously would mean changing the dialog sources.

Of course, aircraft dialogs tend to be simpler, and not use the more complex PUI widgets, precisely for reasons like this, but that’s a limitation it would be best to remove.<ref>https://sourceforge.net/p/flightgear/mailman/message/35155721/</ref>


== References ==
{{Appendix}}

[[Category:PUI| ]]
[[Category:Rendering roadblocks]]

PUI

2023-04-22T09:43:22Z

Hooray: /* Gallery */ convert into proper gallery

{{Feature to be removed|version=2023.3|reason=[[Plib]]/PUI is to be removed and replaced by a [[Canvas widget matrix|Canvas/Nasal based solution]] to help improve compatibility with [[OSG]] 3.6+ and [[OpenGL]] 4.x ([[Core Profile support|OpenGL Core Profile]], see [[2022.X Release plan]] ) and improve performance by [[Unifying the 2D rendering backend via canvas|phasing out legacy OpenGL code]]. Therefore, people should be careful when extending the '''PUI''' based legacy GUI engine<ref>https://sourceforge.net/p/flightgear/mailman/message/34921495/</ref><ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35157325/
|title = <nowiki> Re: [Flightgear-devel] GUI options (Was: Aircraft center) </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jun 14th, 2016
|added = Jun 14th, 2016
|script_version = 0.40
}}</ref> and coordinate any related work with the devel mailing list first-this applies particularly to adding any [[Template:PUI_widget|additional hard-coded PUI widgets]]. }}
[[File:Exit.png|thumb|FlightGear GUI dialog (exit.xml)stored in $FG_ROOT/gui/dialogs]]
{{GUI Navbar}}

[[File:Custom-autopilot-dialog.png|right|200px]]
[[PUI]] is the standard GUI engine used in FlightGear, it is part of [[PLIB]] and is using raw, fixed-pipeline, [[OpenGL]] code internally (no [[OpenSceneGraph]]). As of mid 2021, FlightGear is in the process of working towards adopting the OpenGL Core Profile, this means that [[PUI]] is causing trouble and needs to be replaced/disabled or ported.

PUI provides a fairly basic, but robust, set of widgets. PUI is also used for rendering the [[Menubar]].

FlightGear uses a GUI widget set that is implemented on top of raw (legacy) [[OpenGL]]. This has many advantages from a portability standpoint and from the standpoint of integrating with window systems. [[PUI]] doesn't have every feature under the sun, but it was never meant to. It's relatively small, lean, mean, and written on top of [[OpenGL]] which makes life *much* easier for us.

[[PUI]] already is a separate distinct library within Plib. It depends on some central utility stuff, but that's about it. So it is pretty stripped down and separate already.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg26011.html</ref>

We are to some extent hamstrung by the rather old GUI toolkit we use. However, replacing that is going to be non-trivial, and it would affect not just the core GUI but also all the dialog boxes that have been set up for particular aircraft.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg25985.html</ref>

Flightgear can look amazing when you use the HDR pipeline. We absolutely need this to stay relevant. The problem is that HDR is not compatible with OpenGL1 PUI. Work on getting rid of PUI has been going on for over a decade (longer than it took to implement it).<ref>https://sourceforge.net/p/flightgear/mailman/message/37727346/</ref>

[[File:menubar2.jpg|517px]]

== Replacement status ==
{{See also|FlightGear_and_OpenGL_ES#Example:_disabling_PUI}}

{{Note| Update 09/2022: The PUI replacement [[QtQuick_use_in_FlightGear#Background|was going to be Qt]] but it started to get very complicated with changes in Qt 5.15 + Qt 6, so James is going with a more light-weight Canvas based approach now.

Qt added support for Vulkan / Metal / D3D starting in 5.15, but FlightGear / OpenSceneGraph can’t support those, so integrating the two renderers went from being ‘complicated but ok’ to ‘very very complicated’.

So now James is going with something much more lightweight using some C++ compatibility code, some Nasal for styling and the existing [[Canvas widgets|Canvas widget rendering]] from Thomas Geymayer (TheTom) with [[Canvas Widget Matrix|some extensions and additions]], based on the [[Howto:Processing_legacy_PUI_dialogs_using_Canvas#Original_Discussion|plans originally discussed when the Canvas GUI system was added to FlightGear]]: some pieces are in FlightGear & FGData already.

James has basic dialogs working okay but not the more complex ones and everything looks kind of ugly, he needs to improve the visual look before he shares screenshots to avoid everyone freaking out :) The disadvantage of this approach is James is far from expert at creating visual appearances this way, so it’s kind on unrewarding and slow for him. If someone likes messing with CSS-type styling, border-images and hover-states, ping him since we could probably move things also faster <ref>https://sourceforge.net/p/flightgear/mailman/message/37701750/</ref>}}

=== Motivation ===
{{Main article|Core Profile support}}

The bigger issue here is we need to ditch [[PUI]] (which is in progress) and some OpenGL 1.0 code (HUD, 2D panels especially - can be #ifdef for now) so we can enable Core profile on Mac - since Mac 4.x support (we only hit about 4.3 alas, but with some extensions to get in sight of 4.5) is Core profile only, no Compatability mode.

Improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, many people are convinced PUI needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

While most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so [using Qt5] would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

== Canvas Emulation ==
{{See also|Canvas widget matrix}}
'''Last updated: 04/2023 <ref>https://sourceforge.net/p/flightgear/mailman/message/37805054/</ref>
'''
[[File:Environment-dlg-via-canvas-bridge-04-2023.png|thumb|Screen shot showing the XMLDialog.nas bridge in use to parse/render the environment.xml PUI/XML dialog (unmodified)]]
=== Gallery ===

<gallery>
About-dialog-xmldialog-04-2023.png|about.xml PUI/XML dialog parsed/rendered via the [[Canvas GUI]] and the underlying XMLDialog.nas parser/translator (04-2023)
Logging-dialog-via-xmldialog-04-2023.png|logging.xml PUI/XML dialog parsed/rendered via the [[Canvas GUI]] and the underlying XMLDialog.nas parser/translator (04-2023)
Failures-dialog-via-xmldialog-04-2023.png|failures dialog-via-xmldialog-04-2023.png{{!}}thumb{{!}}logging.xml PUI/XML dialog parsed/rendered via the [[Canvas GUI]] and the underlying XMLDialog.nas parser/translator (04-2023)
</gallery>

=== Status ===
As of 01/2023, the replacement for PUI is making good progress<ref>https://sourceforge.net/p/flightgear/mailman/message/37765706/</ref>.

In February 2022, James reported having something in progress locally, and that should even be something we can try in March/April 2022. Hopefully that’s quick enough, knowing it has been a long time coming.<ref>https://sourceforge.net/p/flightgear/mailman/message/37606439/</ref>

There's now an XML to Nasal bridge, to keep PUI dialogs working (Disabled by a CMake option)
This is implemented on top of the [[Canvas]] system.

This builds equivalent C++ objects to what the [[PUI]] dialogs build, with properties exposed to Nasal.
Peer objects are created by Nasal [[callbacks]], which can implement the various dialog functions needed to keep compatibility, especially the [[#Background|‘update’ and ‘apply’ hooks]].<ref>https://sourceforge.net/p/flightgear/flightgear/ci/cbd5ef9e7b8f433dbc1ba97bae7d7cfc894e7cef/</ref>

{{Note|The PUI Compatible Canvas GUI is a compile time option: Use the following [[Building using CMake|cmake option]] to enable this code: {{CMake Build Option|option=ENABLE_PUICOMPAT|default=ON|description=This requires latest SG/FG AND FGDATA}}. But this is all highly fluid and most of it really developer only. At one point they will become default or be accessible in the launcher.<ref>https://sourceforge.net/p/flightgear/mailman/message/37834004/</ref>

If you compiled with PUICompatibility enabled, but still don't see any dialogs - only the menubar, you might need to enable the GUI module in defaults.xml<ref>https://sourceforge.net/p/flightgear/mailman/message/37833149/</ref>}}

The new Compatibility files can now be found in $FG_SRC/GUI:

* {{flightgear file|src/GUI/FGPUICompatDialog.cxx }}
* {{flightgear file|src/GUI/FGPUICompatDialog.hxx }}
* {{flightgear file|src/GUI/PUICompatObject.cxx }}

01/2023: James is slowly working on creating the pop-up menu and combo-box widgets [...]

One of the major things slowing down James' work on the popup-menu and combo box is time to restart the simulator for each change, he is looking for some solution to re-load the widget Nasal code independently. <ref><https://sourceforge.net/p/flightgear/mailman/message/37756183/</ref>

James has done about 75% (hah!) of the C++ work to enable live reloading of modules this way, but unfortunately there are some code paths that would become crashy if you use the feature for the Canvas: because it would reference the ‘old’ (pre-reload) Nasal code, and not the new one, and therefore you’d get a weird mix of old and new, and then just crash the sim. To fix it properly I need to track down those places that store a reference to Canvas and give them a re-init method, so we don’t keep the stale references.

The general non-fun-ness of that kind of debugging is James has been making such slow progress on my PUI replacement widgets recently <ref>https://sourceforge.net/p/flightgear/mailman/message/37756263/</ref>

=== Todo ===
Nothing in particular: help debugging the grid layout (which is in simgear) would be good. For now, you could create a grid layout manually using some Nasal.

For the menubar, we need to expose the C++ data to Nasal: we need a FGCompatMenuBar (alongisde FGPUIMenuBar) implementing FGMenubar which calls _createMenuObject in MenuBar.nas, using the same way I lookup and call _createDialogPeer in XMLDialog.nas

(Make sure you don’t break the macOS native menubar in the process!)

You can probably pass a wrapped SGpropertyNode into this, and then fill in the stubs in that file to use the Menu widgets Frederic has written.

Global menu keybindings won’t worry but don’t touch that, I have a separate plan for it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37805736/</ref>

As of 04/2023, remaining items on the todo list are: <ref>https://sourceforge.net/p/flightgear/mailman/message/37805060/</ref>

* Grid layout
** GridLayout needs debugged: After this, the basic UI is usable, would probably make it a switchable option on ‘next’ (I can already use the simulator with the new UI today, but all the sizes are off in the grid layouts which we use everywhere)

* list
* table (and tree ?) models corresponding views
* waypoint list
* Re-write the waypoint list and airport dialog to work again (since these use custom widgets):
** log list
** airport-list equivalents
* Nasal access to the menu i18n functions
* selection support for single- and multi-line text (which is being worked on -> CanvasPangoText)
* Keyboard shortcut handling, although this is not really a PUI vs replacement issue, to me we should handle UI shortcuts in the same was normal keyboard.xml shortcuts
** this previously worked because PUI got ‘first chance’ at handling key input. But we always had duplication between keyboard.xml and other places, so I would rather standardise on keyboard.xml, but allow a UI element to set a scope for shortcuts. (So that Copy/paste shortcuts etc can work in a text input, at least … but probably some other standard ones) <ref>https://sourceforge.net/p/flightgear/mailman/message/37805188/</ref>
* Ensure all the places which use the PUI combo-box and list-widget work : there’s a few of these.

The CanvasPangoText stuff is needed but we can perfectly well run the UI on next without it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37805176/</ref>

=== Parser ===
{{Main article|pui2canvas}}
The corresponding Nasal/Canvas module to dynamically "translate" legacy PUI/XML dialogs into Canvas dialogs (at runtime), is to be found in {{fgdata file|Nasal/gui/XMLDialog.nas}} <ref>https://sourceforge.net/p/flightgear/fgdata/ci/fe7c87b21a69f88ddb87d89453c48d12b69660e2/</ref>

=== Widgets ===
{{Main article|Howto:Creating a Canvas GUI Widget}}

It’s split between Simgear (see classes with widget / layout in the name) and in FGData. (Eg widgets/Button.nas) To be able to use the existing dialog XML files un-modified (which is a design goal), James is extending the widget types with many additional ones (eg PUI has slider, dial, combo-box, checkbox, all of which need to be created, see [[Canvas widget matrix]].

This is about 30% done and is the bit he's very slow at). Thomas’s canvas widgets have a very good separation of API + state from appearance, so all styling is in its own file, and James is being very strict about maintaining this separation, so we also retain the re-styling feature of the PUI UI, which many people also rely on. This does make the process of adding new widgets more complex, however.

{{See also|Canvas widgets}}

=== Layouting ===
The other thing is to preserve all the layouting: James has added a grid layout to Simgear, since that is supported by the existing PUI code (even though the layouts are not actually part of PUI itself). The problem is getting the sizing / hinting of all the widgets to match the PUI values, so that dialogs look approximately the same under the new UI as they did with PUI; again this a design goal so that all existing dialogs in aircraft and add-ons, which we can’t update, continue to work and be usable. Debugging that is also proving quite tricky, since there’s all kinds of hard-coded assumptions built into PUI widgets about pixels, font-sizes etc which are not true in the new system.<ref>https://sourceforge.net/p/flightgear/mailman/message/37701792/</ref>

== Background ==
In FlightGear, PUI dialogs are standard [[PropertyList XML File]]s that are stored in $FG_ROOT/gui/dialogs, they can contain the widgets mentioned in {{readme file|gui}}, using a simple layout engine discussed in {{readme file|layout}}, and bindings using a combination of so called fgcommands operating on properties (see {{readme file|commands}}) and custom [[Nasal]] (FlightGear scripting) code.

In addition, each PUI/XML dialog may contain Nasal script sections that are executed when opening/closing the dialog, a feature which is commonly used for procedurally creating/updating widgets using the [[Nasal_library#cmdarg.28.29|cmdarg() API]], which allows the dialog tree to be traversed and manipulated prior to the dialog being rendered.
Widgets can be conditionally hidden/shown using a wrapper for [[Conditions|SGCondition]] in [[Nasal_library/props|props.nas]]
The <code>canvas</code> widget also supports its own embedded Nasal code section to execute arbitrary widget specific Nasal code upon opening/closing the dialog/widget.

PUI/XML dialogs can be loaded, dynamically created, updated and closed using a handful of fgcommands:
* {{fgcommand|dialog-new}}
* {{fgcommand|dialog-show}}
* {{fgcommand|dialog-update}}
* {{fgcommand|dialog-apply}}
* {{fgcommand|dialog-close}}

PUI related OpenGL code is particularly infamous for causing rendering artifacts for people on AMD/ATI and Intel hardware (especially in combination with certain fonts/styles and [[Effects|effects]]/[[Shaders|shaders]]), see {{Issue|2213}}.

PUI is also known to affect rendering performance quite significantly (see {{search |keywords=anthrax+gui}}), while also preventing FlightGear from using a more recent version of OpenGL<ref>http://sourceforge.net/p/flightgear/mailman/message/34532040/</ref><ref>http://forum.flightgear.org/viewtopic.php?f=71&t=24046</ref>.

However, improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Besides, while most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

But given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, graphics folks are also convinced it needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

In addition, [[OpenSceneGraph]] (OSG) can obviously not help optimize any PUI related GL code and PUI widgets are generally considered to be pretty archaic and not easy to extend<ref>http://sourceforge.net/p/flightgear/mailman/message/26832164/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587120/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587272/</ref>.

{{Note|We use the GUI code from PLIB, which doesn't know anything about OSG. See the SGPuDrawable class in $FG_SRC/Viewer/renderer.cxx for the implementation. The one catch is that OSG has a strong notion of separation between the update of a "scene" and its rendering, and that might not play well with arbitrary existing OpenGL code. }}

As of late 2015, there is heavy activity towards providing alternatives to a PUI-based UI:
* [[Integrated Web GUI]] (external, browser-based - fully asynchronous)
* [[Howto:Processing legacy PUI dialogs using Canvas]] (internal, using the [[Canvas]] system and a simple [[Nasal]] parser to deal with existing PUI/XML dialogs)

<gallery mode="packed">
Early-Phi-screen shot.PNG|Screenshot showing [[Phi]]
About-dialog-rendered-by-canvas.png|Screenshot showing a dialog rendered by the [[Howto:Processing legacy PUI dialogs using Canvas|pui2canvas parser]]
</gallery>

== History ==
{{See also|QtQuick use in FlightGear}}
{{Caution|This is merely kept for future reference, many of the ideas discussed below have become obsolete as of 09/2022, if in doubt, please get in touch via devel-list.}}
=== 2021 ===
In early 2021, James did a brief evaluation of [https://github.com/ocornut/imgui ImGUI] as a possibility - he's also evaluating it in some projects at his day job.

The API is interesting if you’re starting from scratch and only exclusively in C++, but it’s not a great fit for how we define GUIs in FG (via [[XML]]/[[Nasal]]): there is no back door that he could find, to access the persistent state of the GUI, or build it up in a data-driven way. So making a mapping to keep our existing GUI XML working (and updating correctly) becomes a bit of a chore.<ref>https://sourceforge.net/p/flightgear/mailman/message/37295586/</ref>

Pretty much all of the FlightGear GUI is defined in XML space, except for a few oddments. Let’s say 95% at this point.

Additionally, even if we were to change that for the core sim (and James' current plan is to keep the XML syntax and just extend it), the installed base of '''aircraft''' ship their own XML dialogs (eg., replacing the autopilot dialog with a custom one, or just adding their own aircraft-specific helper controls for doors / lights / cargo / whatever). So even if we found the most sublimely beautiful, intuitive, compact GUI description language in the world, we have to keep the XML syntax working as-is, for the foreseeable future.

Given this, James' intention is to replace the output side [[PUI]] but keep the front-end side (XML / properties / bindings) unchanged, and therefore backwards compatible, and simply add some new types / options / widget types going forward. This will mean we still have to deal with the slightly cumbersome XML+Nasal syntax, but, well, it’s not *that* cumbersome. <ref>https://sourceforge.net/p/flightgear/mailman/message/37296280/</ref>

In mid 2021, James reported that he is working on some ‘PUICompat’ classes which hold/own/represent the GUI state in C++, but which can be used with [[Nasal/CppBind|Nasal CppBind]]. And of course we could indeed expose those later on. <ref>https://sourceforge.net/p/flightgear/mailman/message/37297727/</ref>

In July 2021, James suggested not to worry about the existing GUI code, it’s going in the bin.<ref>https://sourceforge.net/p/flightgear/mailman/message/37325905/</ref>

For the time being, the in-sim GUi can’t do Unicode yet, but James is working on it, hopefully available soon.<ref>https://sourceforge.net/p/flightgear/mailman/message/37328200/</ref>
Also, the in-sim menubar will change with the new GUI, *and* we use a native menubar on macOS. Until James replaces the PUI fonts we can’t use Unicode symbols. So, will have to come back to it once the new GUI is merged.<ref>https://sourceforge.net/p/flightgear/mailman/message/37327237/</ref>

=== 2020 ===
As of 03/2020, the PLIB replacement was reported to be in the backlog <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36951255/
|title = <nowiki>Re: [Flightgear-devel] C++ and/or OSG question </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Mar 18th, 2020
|added = Mar 18th, 2020
|script_version = 0.50
}}</ref>.

With PLIB replacement work likely being re-scheduled for [[Post FlightGear 2020.2 LTS changes]] <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36985375/
|title = <nowiki>Re: [Flightgear-devel] Working Group Proposal - Boost and PLIB replacement - Delegation and Teamwork </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = April 18th, 2020
|added = April 18th, 2020
|script_version = 1.10
}}</ref>.

In 08/2020, James stated that he was still working (exceptionally slowly!) on replacing PUI (as part of removing legacy OpenGL code (PUI, HUD, 2d panels, porting Canvas away form ShivaVG), so we can switch to Vulkan/VSG at some point (ideally at some point before Apple turn off OpenGL support…)), and that he doesn't think /any/ of us *want* to be working on these features particularly, but projects like these need to be done before anyone can have fun with VSG or Vulkan (personally James would be very enthusiastic about working on VSG support (being on macOS, I also have the most to lose / gain from it)). Sometimes that’s just how it goes. Equally they will all benefit the project ultimately, but the payoff both for the individual and the project is very drawn out. <ref>https://sourceforge.net/p/flightgear/mailman/message/37077158/</ref>

In 10/2020, the estimation is that PUI should be going away really ‘soon’, the replacement code is already in next / 2020.2. (There’s no plan to actually /use/ the new UI code in 2020.2, but if the bugs in it prove simple, we could actually turn it for specific dialog: it seems very unlikely this makes sense for a stable release however)<ref>https://sourceforge.net/p/flightgear/mailman/message/37123818/</ref>

The fixed-function removal, is actively in hand (Gaetan is working on the 2D panel part, and James is going to focus on PUI in the rest of 2020). James hopes that means next year he can focus on Vulkan, or at least, using OSG as if /were/ VSG, so the migration in a year or two when VSG is stable, is not so painful.<ref>https://sourceforge.net/p/flightgear/mailman/message/37129098/</ref>

The PUI UI and replacement can co-exist in the same build (they already do, effectively.<ref>https://sourceforge.net/p/flightgear/mailman/message/37131297/</ref>

In 11/2020, James suggested not to worry about details such as PUI styling/theming etc: we’re not making such changes for the LTS, and PUI should be gone before the next release.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142225/</ref> Also, he recommended (to everyone) to stop touching GUI stuff for a few weeks, as he's about to turn it all on its head.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142356/</ref>

=== 2019 ===
The new GUI has been incubating for a few years, but there's apparently been a lot of progress as of 10/2019.

It is likely the new GUI will be a user opt-in feature - at least initially. The sunset of the PLIB library _could_ happen relatively soon, but
people will need to see the new GUI and react to it before we could commit to PLIB removal <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36784489/
|title = <nowiki>Re: [Flightgear-devel] in Flightgear/Simgear C++ Code: What needs Doing? What are YOU Doing? What would you do if you had the time? </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Oct 14th, 2019
|added = Oct 14th, 2019
|script_version = 0.50
}}</ref>.

In 02/2019, James stated that the new UI is coming quite soon. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36589420/
|title = <nowiki> Re: [Flightgear-devel] Lagging </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Feb 17th, 2019
|added = Feb 17th, 2019
|script_version = 0.40
}}</ref>

=== 2018 ===
{{See also|QtQuick use in FlightGear}}

According to James, we have to accept that changes like testing or making [[PUI]] a modular thing or moving the JS code tend to have an immediate pain for some people (because strange stuff gets broken, and takes some time to get fixed), whereas the payoff in terms of improved joystick handling or replacing the UI or testing of all subsystems will take some months or years to be felt.<ref>https://sourceforge.net/p/flightgear/mailman/message/36323240/</ref>

James said he was in the middle of porting the launcher’s final tab (location) to the new UI scheme, once that’s done he will start sketching out the ‘in sim’ settings UI using the same pieces. He’ll send a request for contributions around about that in the next three-four weeks, once he has enough templates & examples that there is a clear pattern to follow.<ref>https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/2d10f16c-ddc8-07f3-07e7-eca2a0a0d55f%40zaretto.com/#msg36293586</ref>

James announced that the launcher is now feature complete with the QtQuick UI, he’ll keep making bug-fixes of course as people report them, but my todo list for the core features is now done<ref>https://sourceforge.net/p/flightgear/mailman/message/36355833/</ref>.

=== 2017 ===

In 10/2017, James said he was getting really close to having the PUI replacement UI suitable for beta-testing.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36067646/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 7th, 2017
|added = Oct 7th, 2017
|script_version = 0.40
}}</ref>

Originally, James was hoping to land the PUI replacement GUI in the last dev cycle in 2017 (at least as a proof-of-concept, probably not as the default UI), so wouldn’t expend lots of effort on things like collapsible sections which might be a lot of work with the current PUI/Canvas approaches, but are trivial with the new [[QtQuick use in FlightGear|QtQuick based UI scheme]].<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36059822/
|title = <nowiki> Re: [Flightgear-devel] Canvas MapLayer for OpenStreetMap, OpenAIP,
VFR Sectionals </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 1st, 2017
|added = Oct 1st, 2017
|script_version = 0.40
}}</ref>

Once the basic new UI is in place we can experiment with different re-arrangements easily, without being limited by PUI. (James expects PUI to live on as the default / alternate UI while this happens)<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36061229/
|title = <nowiki> Re: [Flightgear-devel] FGFS macOS Menubar </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 2nd, 2017
|added = Oct 2nd, 2017
|script_version = 0.40
}}</ref>

Technically, this entails replacing dialog.cxx with some code which builds up some special ‘PUI-Emulation’ QtQuick controls, so that existing dialogs (especially from Aircraft) continue to work. This mode will look somewhat ugly but hopefully no more ugly than PUI! And it helps that the set of widgets we have in PUI is limited, and the ‘tricky’ widgets (map, scrolling list, etc) are in the dialogs will will replace with new ones first.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068767/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

This PUI emulation isn't going to use any code from PLIB<ref>https://sourceforge.net/p/flightgear/mailman/message/36985303/</ref>, so what will remain from it in FG afterwards will be the FNT and JS components (reworked).<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068817/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> Florent Rougon </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

=== 2016 ===
We need to explore if Qt Quick or widgets is the better way to go, with a preference towards Qt Quick, since it will allow things closer to current PUI (semi-transparent widgets on top of the 3D content). It still allows creating separate windows too (Erik’s use case), but means we get consistent, custom theming on all platforms, since standard desktop look is not so nice for a flight-sim.

James intention is to make a QML-hosting OSG-drawable, and add this as a concept in Qt-enabled builds, then port some PUI dialogs to it, and see how easy / painful the process is. Hell create some QObjects which expose commands and the property tree and Nasal.

This has the advantage of not touching the OSG window at all, QtQuick simply provides some additional OpenGL rendering on top, which we pass events to - pretty much exactly the same as what we already do for PUI, and hopefully can co-exist with it. James got this working in a local OSG tree in a standalone demo, but that’s based on osgQt - he wants to see if he can make it work on a normal, non-Qt OSG window inside FlightGear.<ref>https://sourceforge.net/p/flightgear/mailman/message/35156051/</ref>

The idea is to host an XML dialog (Currently done with PUI) from Qt also. The question is if that can be done keeping ‘source compatibility’ exactly with the current UI XML and Nasal interface. It probably can be, but many of the PUI widgets have really ugly APIs, especially for combo-boxes, drop-down menus and scrolling lists, where it makes sense to map a Nasal class to a Qt ItemModel, which would be more elegant and easy to work with in both Nasal and integrate on the Qt side. But obviously would mean changing the dialog sources.

Of course, aircraft dialogs tend to be simpler, and not use the more complex PUI widgets, precisely for reasons like this, but that’s a limitation it would be best to remove.<ref>https://sourceforge.net/p/flightgear/mailman/message/35155721/</ref>


== References ==
{{Appendix}}

[[Category:PUI| ]]
[[Category:Rendering roadblocks]]

PUI

2023-04-22T09:39:20Z

Hooray: /* Status */ TODO: should be using proper gallery here

{{Feature to be removed|version=2023.3|reason=[[Plib]]/PUI is to be removed and replaced by a [[Canvas widget matrix|Canvas/Nasal based solution]] to help improve compatibility with [[OSG]] 3.6+ and [[OpenGL]] 4.x ([[Core Profile support|OpenGL Core Profile]], see [[2022.X Release plan]] ) and improve performance by [[Unifying the 2D rendering backend via canvas|phasing out legacy OpenGL code]]. Therefore, people should be careful when extending the '''PUI''' based legacy GUI engine<ref>https://sourceforge.net/p/flightgear/mailman/message/34921495/</ref><ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35157325/
|title = <nowiki> Re: [Flightgear-devel] GUI options (Was: Aircraft center) </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jun 14th, 2016
|added = Jun 14th, 2016
|script_version = 0.40
}}</ref> and coordinate any related work with the devel mailing list first-this applies particularly to adding any [[Template:PUI_widget|additional hard-coded PUI widgets]]. }}
[[File:Exit.png|thumb|FlightGear GUI dialog (exit.xml)stored in $FG_ROOT/gui/dialogs]]
{{GUI Navbar}}

[[File:Custom-autopilot-dialog.png|right|200px]]
[[PUI]] is the standard GUI engine used in FlightGear, it is part of [[PLIB]] and is using raw, fixed-pipeline, [[OpenGL]] code internally (no [[OpenSceneGraph]]). As of mid 2021, FlightGear is in the process of working towards adopting the OpenGL Core Profile, this means that [[PUI]] is causing trouble and needs to be replaced/disabled or ported.

PUI provides a fairly basic, but robust, set of widgets. PUI is also used for rendering the [[Menubar]].

FlightGear uses a GUI widget set that is implemented on top of raw (legacy) [[OpenGL]]. This has many advantages from a portability standpoint and from the standpoint of integrating with window systems. [[PUI]] doesn't have every feature under the sun, but it was never meant to. It's relatively small, lean, mean, and written on top of [[OpenGL]] which makes life *much* easier for us.

[[PUI]] already is a separate distinct library within Plib. It depends on some central utility stuff, but that's about it. So it is pretty stripped down and separate already.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg26011.html</ref>

We are to some extent hamstrung by the rather old GUI toolkit we use. However, replacing that is going to be non-trivial, and it would affect not just the core GUI but also all the dialog boxes that have been set up for particular aircraft.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg25985.html</ref>

Flightgear can look amazing when you use the HDR pipeline. We absolutely need this to stay relevant. The problem is that HDR is not compatible with OpenGL1 PUI. Work on getting rid of PUI has been going on for over a decade (longer than it took to implement it).<ref>https://sourceforge.net/p/flightgear/mailman/message/37727346/</ref>

[[File:menubar2.jpg|517px]]

== Replacement status ==
{{See also|FlightGear_and_OpenGL_ES#Example:_disabling_PUI}}

{{Note| Update 09/2022: The PUI replacement [[QtQuick_use_in_FlightGear#Background|was going to be Qt]] but it started to get very complicated with changes in Qt 5.15 + Qt 6, so James is going with a more light-weight Canvas based approach now.

Qt added support for Vulkan / Metal / D3D starting in 5.15, but FlightGear / OpenSceneGraph can’t support those, so integrating the two renderers went from being ‘complicated but ok’ to ‘very very complicated’.

So now James is going with something much more lightweight using some C++ compatibility code, some Nasal for styling and the existing [[Canvas widgets|Canvas widget rendering]] from Thomas Geymayer (TheTom) with [[Canvas Widget Matrix|some extensions and additions]], based on the [[Howto:Processing_legacy_PUI_dialogs_using_Canvas#Original_Discussion|plans originally discussed when the Canvas GUI system was added to FlightGear]]: some pieces are in FlightGear & FGData already.

James has basic dialogs working okay but not the more complex ones and everything looks kind of ugly, he needs to improve the visual look before he shares screenshots to avoid everyone freaking out :) The disadvantage of this approach is James is far from expert at creating visual appearances this way, so it’s kind on unrewarding and slow for him. If someone likes messing with CSS-type styling, border-images and hover-states, ping him since we could probably move things also faster <ref>https://sourceforge.net/p/flightgear/mailman/message/37701750/</ref>}}

=== Motivation ===
{{Main article|Core Profile support}}

The bigger issue here is we need to ditch [[PUI]] (which is in progress) and some OpenGL 1.0 code (HUD, 2D panels especially - can be #ifdef for now) so we can enable Core profile on Mac - since Mac 4.x support (we only hit about 4.3 alas, but with some extensions to get in sight of 4.5) is Core profile only, no Compatability mode.

Improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, many people are convinced PUI needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

While most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so [using Qt5] would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

== Canvas Emulation ==
{{See also|Canvas widget matrix}}
'''Last updated: 04/2023 <ref>https://sourceforge.net/p/flightgear/mailman/message/37805054/</ref>
'''
[[File:Environment-dlg-via-canvas-bridge-04-2023.png|thumb|Screen shot showing the XMLDialog.nas bridge in use to parse/render the environment.xml PUI/XML dialog (unmodified)]]
=== Gallery ===

[[File:About-dialog-xmldialog-04-2023.png|thumb|about.xml PUI/XML dialog parsed/rendered via the [[Canvas GUI]] and the underlying XMLDialog.nas parser/translator (04-2023)]]
[[File:Logging-dialog-via-xmldialog-04-2023.png|thumb|logging.xml PUI/XML dialog parsed/rendered via the [[Canvas GUI]] and the underlying XMLDialog.nas parser/translator (04-2023)]]
[[File:Failures-dialog-via-xmldialog-04-2023.png|thumb|failures dialog-via-xmldialog-04-2023.png{{!}}thumb{{!}}logging.xml PUI/XML dialog parsed/rendered via the [[Canvas GUI]] and the underlying XMLDialog.nas parser/translator (04-2023)]]

=== Status ===
As of 01/2023, the replacement for PUI is making good progress<ref>https://sourceforge.net/p/flightgear/mailman/message/37765706/</ref>.

In February 2022, James reported having something in progress locally, and that should even be something we can try in March/April 2022. Hopefully that’s quick enough, knowing it has been a long time coming.<ref>https://sourceforge.net/p/flightgear/mailman/message/37606439/</ref>

There's now an XML to Nasal bridge, to keep PUI dialogs working (Disabled by a CMake option)
This is implemented on top of the [[Canvas]] system.

This builds equivalent C++ objects to what the [[PUI]] dialogs build, with properties exposed to Nasal.
Peer objects are created by Nasal [[callbacks]], which can implement the various dialog functions needed to keep compatibility, especially the [[#Background|‘update’ and ‘apply’ hooks]].<ref>https://sourceforge.net/p/flightgear/flightgear/ci/cbd5ef9e7b8f433dbc1ba97bae7d7cfc894e7cef/</ref>

{{Note|The PUI Compatible Canvas GUI is a compile time option: Use the following [[Building using CMake|cmake option]] to enable this code: {{CMake Build Option|option=ENABLE_PUICOMPAT|default=ON|description=This requires latest SG/FG AND FGDATA}}. But this is all highly fluid and most of it really developer only. At one point they will become default or be accessible in the launcher.<ref>https://sourceforge.net/p/flightgear/mailman/message/37834004/</ref>

If you compiled with PUICompatibility enabled, but still don't see any dialogs - only the menubar, you might need to enable the GUI module in defaults.xml<ref>https://sourceforge.net/p/flightgear/mailman/message/37833149/</ref>}}

The new Compatibility files can now be found in $FG_SRC/GUI:

* {{flightgear file|src/GUI/FGPUICompatDialog.cxx }}
* {{flightgear file|src/GUI/FGPUICompatDialog.hxx }}
* {{flightgear file|src/GUI/PUICompatObject.cxx }}

01/2023: James is slowly working on creating the pop-up menu and combo-box widgets [...]

One of the major things slowing down James' work on the popup-menu and combo box is time to restart the simulator for each change, he is looking for some solution to re-load the widget Nasal code independently. <ref><https://sourceforge.net/p/flightgear/mailman/message/37756183/</ref>

James has done about 75% (hah!) of the C++ work to enable live reloading of modules this way, but unfortunately there are some code paths that would become crashy if you use the feature for the Canvas: because it would reference the ‘old’ (pre-reload) Nasal code, and not the new one, and therefore you’d get a weird mix of old and new, and then just crash the sim. To fix it properly I need to track down those places that store a reference to Canvas and give them a re-init method, so we don’t keep the stale references.

The general non-fun-ness of that kind of debugging is James has been making such slow progress on my PUI replacement widgets recently <ref>https://sourceforge.net/p/flightgear/mailman/message/37756263/</ref>

=== Todo ===
Nothing in particular: help debugging the grid layout (which is in simgear) would be good. For now, you could create a grid layout manually using some Nasal.

For the menubar, we need to expose the C++ data to Nasal: we need a FGCompatMenuBar (alongisde FGPUIMenuBar) implementing FGMenubar which calls _createMenuObject in MenuBar.nas, using the same way I lookup and call _createDialogPeer in XMLDialog.nas

(Make sure you don’t break the macOS native menubar in the process!)

You can probably pass a wrapped SGpropertyNode into this, and then fill in the stubs in that file to use the Menu widgets Frederic has written.

Global menu keybindings won’t worry but don’t touch that, I have a separate plan for it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37805736/</ref>

As of 04/2023, remaining items on the todo list are: <ref>https://sourceforge.net/p/flightgear/mailman/message/37805060/</ref>

* Grid layout
** GridLayout needs debugged: After this, the basic UI is usable, would probably make it a switchable option on ‘next’ (I can already use the simulator with the new UI today, but all the sizes are off in the grid layouts which we use everywhere)

* list
* table (and tree ?) models corresponding views
* waypoint list
* Re-write the waypoint list and airport dialog to work again (since these use custom widgets):
** log list
** airport-list equivalents
* Nasal access to the menu i18n functions
* selection support for single- and multi-line text (which is being worked on -> CanvasPangoText)
* Keyboard shortcut handling, although this is not really a PUI vs replacement issue, to me we should handle UI shortcuts in the same was normal keyboard.xml shortcuts
** this previously worked because PUI got ‘first chance’ at handling key input. But we always had duplication between keyboard.xml and other places, so I would rather standardise on keyboard.xml, but allow a UI element to set a scope for shortcuts. (So that Copy/paste shortcuts etc can work in a text input, at least … but probably some other standard ones) <ref>https://sourceforge.net/p/flightgear/mailman/message/37805188/</ref>
* Ensure all the places which use the PUI combo-box and list-widget work : there’s a few of these.

The CanvasPangoText stuff is needed but we can perfectly well run the UI on next without it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37805176/</ref>

=== Parser ===
{{Main article|pui2canvas}}
The corresponding Nasal/Canvas module to dynamically "translate" legacy PUI/XML dialogs into Canvas dialogs (at runtime), is to be found in {{fgdata file|Nasal/gui/XMLDialog.nas}} <ref>https://sourceforge.net/p/flightgear/fgdata/ci/fe7c87b21a69f88ddb87d89453c48d12b69660e2/</ref>

=== Widgets ===
{{Main article|Howto:Creating a Canvas GUI Widget}}

It’s split between Simgear (see classes with widget / layout in the name) and in FGData. (Eg widgets/Button.nas) To be able to use the existing dialog XML files un-modified (which is a design goal), James is extending the widget types with many additional ones (eg PUI has slider, dial, combo-box, checkbox, all of which need to be created, see [[Canvas widget matrix]].

This is about 30% done and is the bit he's very slow at). Thomas’s canvas widgets have a very good separation of API + state from appearance, so all styling is in its own file, and James is being very strict about maintaining this separation, so we also retain the re-styling feature of the PUI UI, which many people also rely on. This does make the process of adding new widgets more complex, however.

{{See also|Canvas widgets}}

=== Layouting ===
The other thing is to preserve all the layouting: James has added a grid layout to Simgear, since that is supported by the existing PUI code (even though the layouts are not actually part of PUI itself). The problem is getting the sizing / hinting of all the widgets to match the PUI values, so that dialogs look approximately the same under the new UI as they did with PUI; again this a design goal so that all existing dialogs in aircraft and add-ons, which we can’t update, continue to work and be usable. Debugging that is also proving quite tricky, since there’s all kinds of hard-coded assumptions built into PUI widgets about pixels, font-sizes etc which are not true in the new system.<ref>https://sourceforge.net/p/flightgear/mailman/message/37701792/</ref>

== Background ==
In FlightGear, PUI dialogs are standard [[PropertyList XML File]]s that are stored in $FG_ROOT/gui/dialogs, they can contain the widgets mentioned in {{readme file|gui}}, using a simple layout engine discussed in {{readme file|layout}}, and bindings using a combination of so called fgcommands operating on properties (see {{readme file|commands}}) and custom [[Nasal]] (FlightGear scripting) code.

In addition, each PUI/XML dialog may contain Nasal script sections that are executed when opening/closing the dialog, a feature which is commonly used for procedurally creating/updating widgets using the [[Nasal_library#cmdarg.28.29|cmdarg() API]], which allows the dialog tree to be traversed and manipulated prior to the dialog being rendered.
Widgets can be conditionally hidden/shown using a wrapper for [[Conditions|SGCondition]] in [[Nasal_library/props|props.nas]]
The <code>canvas</code> widget also supports its own embedded Nasal code section to execute arbitrary widget specific Nasal code upon opening/closing the dialog/widget.

PUI/XML dialogs can be loaded, dynamically created, updated and closed using a handful of fgcommands:
* {{fgcommand|dialog-new}}
* {{fgcommand|dialog-show}}
* {{fgcommand|dialog-update}}
* {{fgcommand|dialog-apply}}
* {{fgcommand|dialog-close}}

PUI related OpenGL code is particularly infamous for causing rendering artifacts for people on AMD/ATI and Intel hardware (especially in combination with certain fonts/styles and [[Effects|effects]]/[[Shaders|shaders]]), see {{Issue|2213}}.

PUI is also known to affect rendering performance quite significantly (see {{search |keywords=anthrax+gui}}), while also preventing FlightGear from using a more recent version of OpenGL<ref>http://sourceforge.net/p/flightgear/mailman/message/34532040/</ref><ref>http://forum.flightgear.org/viewtopic.php?f=71&t=24046</ref>.

However, improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Besides, while most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

But given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, graphics folks are also convinced it needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

In addition, [[OpenSceneGraph]] (OSG) can obviously not help optimize any PUI related GL code and PUI widgets are generally considered to be pretty archaic and not easy to extend<ref>http://sourceforge.net/p/flightgear/mailman/message/26832164/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587120/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587272/</ref>.

{{Note|We use the GUI code from PLIB, which doesn't know anything about OSG. See the SGPuDrawable class in $FG_SRC/Viewer/renderer.cxx for the implementation. The one catch is that OSG has a strong notion of separation between the update of a "scene" and its rendering, and that might not play well with arbitrary existing OpenGL code. }}

As of late 2015, there is heavy activity towards providing alternatives to a PUI-based UI:
* [[Integrated Web GUI]] (external, browser-based - fully asynchronous)
* [[Howto:Processing legacy PUI dialogs using Canvas]] (internal, using the [[Canvas]] system and a simple [[Nasal]] parser to deal with existing PUI/XML dialogs)

<gallery mode="packed">
Early-Phi-screen shot.PNG|Screenshot showing [[Phi]]
About-dialog-rendered-by-canvas.png|Screenshot showing a dialog rendered by the [[Howto:Processing legacy PUI dialogs using Canvas|pui2canvas parser]]
</gallery>

== History ==
{{See also|QtQuick use in FlightGear}}
{{Caution|This is merely kept for future reference, many of the ideas discussed below have become obsolete as of 09/2022, if in doubt, please get in touch via devel-list.}}
=== 2021 ===
In early 2021, James did a brief evaluation of [https://github.com/ocornut/imgui ImGUI] as a possibility - he's also evaluating it in some projects at his day job.

The API is interesting if you’re starting from scratch and only exclusively in C++, but it’s not a great fit for how we define GUIs in FG (via [[XML]]/[[Nasal]]): there is no back door that he could find, to access the persistent state of the GUI, or build it up in a data-driven way. So making a mapping to keep our existing GUI XML working (and updating correctly) becomes a bit of a chore.<ref>https://sourceforge.net/p/flightgear/mailman/message/37295586/</ref>

Pretty much all of the FlightGear GUI is defined in XML space, except for a few oddments. Let’s say 95% at this point.

Additionally, even if we were to change that for the core sim (and James' current plan is to keep the XML syntax and just extend it), the installed base of '''aircraft''' ship their own XML dialogs (eg., replacing the autopilot dialog with a custom one, or just adding their own aircraft-specific helper controls for doors / lights / cargo / whatever). So even if we found the most sublimely beautiful, intuitive, compact GUI description language in the world, we have to keep the XML syntax working as-is, for the foreseeable future.

Given this, James' intention is to replace the output side [[PUI]] but keep the front-end side (XML / properties / bindings) unchanged, and therefore backwards compatible, and simply add some new types / options / widget types going forward. This will mean we still have to deal with the slightly cumbersome XML+Nasal syntax, but, well, it’s not *that* cumbersome. <ref>https://sourceforge.net/p/flightgear/mailman/message/37296280/</ref>

In mid 2021, James reported that he is working on some ‘PUICompat’ classes which hold/own/represent the GUI state in C++, but which can be used with [[Nasal/CppBind|Nasal CppBind]]. And of course we could indeed expose those later on. <ref>https://sourceforge.net/p/flightgear/mailman/message/37297727/</ref>

In July 2021, James suggested not to worry about the existing GUI code, it’s going in the bin.<ref>https://sourceforge.net/p/flightgear/mailman/message/37325905/</ref>

For the time being, the in-sim GUi can’t do Unicode yet, but James is working on it, hopefully available soon.<ref>https://sourceforge.net/p/flightgear/mailman/message/37328200/</ref>
Also, the in-sim menubar will change with the new GUI, *and* we use a native menubar on macOS. Until James replaces the PUI fonts we can’t use Unicode symbols. So, will have to come back to it once the new GUI is merged.<ref>https://sourceforge.net/p/flightgear/mailman/message/37327237/</ref>

=== 2020 ===
As of 03/2020, the PLIB replacement was reported to be in the backlog <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36951255/
|title = <nowiki>Re: [Flightgear-devel] C++ and/or OSG question </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Mar 18th, 2020
|added = Mar 18th, 2020
|script_version = 0.50
}}</ref>.

With PLIB replacement work likely being re-scheduled for [[Post FlightGear 2020.2 LTS changes]] <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36985375/
|title = <nowiki>Re: [Flightgear-devel] Working Group Proposal - Boost and PLIB replacement - Delegation and Teamwork </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = April 18th, 2020
|added = April 18th, 2020
|script_version = 1.10
}}</ref>.

In 08/2020, James stated that he was still working (exceptionally slowly!) on replacing PUI (as part of removing legacy OpenGL code (PUI, HUD, 2d panels, porting Canvas away form ShivaVG), so we can switch to Vulkan/VSG at some point (ideally at some point before Apple turn off OpenGL support…)), and that he doesn't think /any/ of us *want* to be working on these features particularly, but projects like these need to be done before anyone can have fun with VSG or Vulkan (personally James would be very enthusiastic about working on VSG support (being on macOS, I also have the most to lose / gain from it)). Sometimes that’s just how it goes. Equally they will all benefit the project ultimately, but the payoff both for the individual and the project is very drawn out. <ref>https://sourceforge.net/p/flightgear/mailman/message/37077158/</ref>

In 10/2020, the estimation is that PUI should be going away really ‘soon’, the replacement code is already in next / 2020.2. (There’s no plan to actually /use/ the new UI code in 2020.2, but if the bugs in it prove simple, we could actually turn it for specific dialog: it seems very unlikely this makes sense for a stable release however)<ref>https://sourceforge.net/p/flightgear/mailman/message/37123818/</ref>

The fixed-function removal, is actively in hand (Gaetan is working on the 2D panel part, and James is going to focus on PUI in the rest of 2020). James hopes that means next year he can focus on Vulkan, or at least, using OSG as if /were/ VSG, so the migration in a year or two when VSG is stable, is not so painful.<ref>https://sourceforge.net/p/flightgear/mailman/message/37129098/</ref>

The PUI UI and replacement can co-exist in the same build (they already do, effectively.<ref>https://sourceforge.net/p/flightgear/mailman/message/37131297/</ref>

In 11/2020, James suggested not to worry about details such as PUI styling/theming etc: we’re not making such changes for the LTS, and PUI should be gone before the next release.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142225/</ref> Also, he recommended (to everyone) to stop touching GUI stuff for a few weeks, as he's about to turn it all on its head.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142356/</ref>

=== 2019 ===
The new GUI has been incubating for a few years, but there's apparently been a lot of progress as of 10/2019.

It is likely the new GUI will be a user opt-in feature - at least initially. The sunset of the PLIB library _could_ happen relatively soon, but
people will need to see the new GUI and react to it before we could commit to PLIB removal <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36784489/
|title = <nowiki>Re: [Flightgear-devel] in Flightgear/Simgear C++ Code: What needs Doing? What are YOU Doing? What would you do if you had the time? </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Oct 14th, 2019
|added = Oct 14th, 2019
|script_version = 0.50
}}</ref>.

In 02/2019, James stated that the new UI is coming quite soon. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36589420/
|title = <nowiki> Re: [Flightgear-devel] Lagging </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Feb 17th, 2019
|added = Feb 17th, 2019
|script_version = 0.40
}}</ref>

=== 2018 ===
{{See also|QtQuick use in FlightGear}}

According to James, we have to accept that changes like testing or making [[PUI]] a modular thing or moving the JS code tend to have an immediate pain for some people (because strange stuff gets broken, and takes some time to get fixed), whereas the payoff in terms of improved joystick handling or replacing the UI or testing of all subsystems will take some months or years to be felt.<ref>https://sourceforge.net/p/flightgear/mailman/message/36323240/</ref>

James said he was in the middle of porting the launcher’s final tab (location) to the new UI scheme, once that’s done he will start sketching out the ‘in sim’ settings UI using the same pieces. He’ll send a request for contributions around about that in the next three-four weeks, once he has enough templates & examples that there is a clear pattern to follow.<ref>https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/2d10f16c-ddc8-07f3-07e7-eca2a0a0d55f%40zaretto.com/#msg36293586</ref>

James announced that the launcher is now feature complete with the QtQuick UI, he’ll keep making bug-fixes of course as people report them, but my todo list for the core features is now done<ref>https://sourceforge.net/p/flightgear/mailman/message/36355833/</ref>.

=== 2017 ===

In 10/2017, James said he was getting really close to having the PUI replacement UI suitable for beta-testing.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36067646/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 7th, 2017
|added = Oct 7th, 2017
|script_version = 0.40
}}</ref>

Originally, James was hoping to land the PUI replacement GUI in the last dev cycle in 2017 (at least as a proof-of-concept, probably not as the default UI), so wouldn’t expend lots of effort on things like collapsible sections which might be a lot of work with the current PUI/Canvas approaches, but are trivial with the new [[QtQuick use in FlightGear|QtQuick based UI scheme]].<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36059822/
|title = <nowiki> Re: [Flightgear-devel] Canvas MapLayer for OpenStreetMap, OpenAIP,
VFR Sectionals </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 1st, 2017
|added = Oct 1st, 2017
|script_version = 0.40
}}</ref>

Once the basic new UI is in place we can experiment with different re-arrangements easily, without being limited by PUI. (James expects PUI to live on as the default / alternate UI while this happens)<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36061229/
|title = <nowiki> Re: [Flightgear-devel] FGFS macOS Menubar </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 2nd, 2017
|added = Oct 2nd, 2017
|script_version = 0.40
}}</ref>

Technically, this entails replacing dialog.cxx with some code which builds up some special ‘PUI-Emulation’ QtQuick controls, so that existing dialogs (especially from Aircraft) continue to work. This mode will look somewhat ugly but hopefully no more ugly than PUI! And it helps that the set of widgets we have in PUI is limited, and the ‘tricky’ widgets (map, scrolling list, etc) are in the dialogs will will replace with new ones first.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068767/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

This PUI emulation isn't going to use any code from PLIB<ref>https://sourceforge.net/p/flightgear/mailman/message/36985303/</ref>, so what will remain from it in FG afterwards will be the FNT and JS components (reworked).<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068817/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> Florent Rougon </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

=== 2016 ===
We need to explore if Qt Quick or widgets is the better way to go, with a preference towards Qt Quick, since it will allow things closer to current PUI (semi-transparent widgets on top of the 3D content). It still allows creating separate windows too (Erik’s use case), but means we get consistent, custom theming on all platforms, since standard desktop look is not so nice for a flight-sim.

James intention is to make a QML-hosting OSG-drawable, and add this as a concept in Qt-enabled builds, then port some PUI dialogs to it, and see how easy / painful the process is. Hell create some QObjects which expose commands and the property tree and Nasal.

This has the advantage of not touching the OSG window at all, QtQuick simply provides some additional OpenGL rendering on top, which we pass events to - pretty much exactly the same as what we already do for PUI, and hopefully can co-exist with it. James got this working in a local OSG tree in a standalone demo, but that’s based on osgQt - he wants to see if he can make it work on a normal, non-Qt OSG window inside FlightGear.<ref>https://sourceforge.net/p/flightgear/mailman/message/35156051/</ref>

The idea is to host an XML dialog (Currently done with PUI) from Qt also. The question is if that can be done keeping ‘source compatibility’ exactly with the current UI XML and Nasal interface. It probably can be, but many of the PUI widgets have really ugly APIs, especially for combo-boxes, drop-down menus and scrolling lists, where it makes sense to map a Nasal class to a Qt ItemModel, which would be more elegant and easy to work with in both Nasal and integrate on the Qt side. But obviously would mean changing the dialog sources.

Of course, aircraft dialogs tend to be simpler, and not use the more complex PUI widgets, precisely for reasons like this, but that’s a limitation it would be best to remove.<ref>https://sourceforge.net/p/flightgear/mailman/message/35155721/</ref>


== References ==
{{Appendix}}

[[Category:PUI| ]]
[[Category:Rendering roadblocks]]

File:Failures-dialog-via-xmldialog-04-2023.png

2023-04-22T09:38:46Z

Hooray: Uploaded own work with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=failures dialog-via-xmldialog-04-2023.png{{!}}thumb{{!}}logging.xml PUI/XML dialog parsed/rendered via the [[Canvas GUI]] and the underlying XMLDialog.nas parser/translator (04-2023)}}
|date=2023-04-21
|source={{own}}
|author=[[User:Hooray|Hooray]]
|permission=
|other versions=
}}

=={{int:license-header}}==
{{self|cc-by-sa-4.0}}

[[Category:Canvas GUI]]

File:Logging-dialog-via-xmldialog-04-2023.png

2023-04-22T09:37:58Z

Hooray: Uploaded own work with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=logging.xml PUI/XML dialog parsed/rendered via the [[Canvas GUI]] and the underlying XMLDialog.nas parser/translator (04-2023)}}
|date=2023-04-21
|source={{own}}
|author=[[User:Hooray|Hooray]]
|permission=
|other versions=
}}

=={{int:license-header}}==
{{self|cc-by-sa-4.0}}

[[Category:Canvas GUI]]

File:About-dialog-xmldialog-04-2023.png

2023-04-22T09:36:53Z

Hooray: Uploaded own work with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=about.xml PUI/XML dialog parsed/rendered via the [[Canvas GUI]] and the underlying XMLDialog.nas parser/translator (04-2023)}}
|date=2023-04-22
|source={{own}}
|author=[[User:Hooray|Hooray]]
|permission=
|other versions=
}}

=={{int:license-header}}==
{{self|cc-by-sa-4.0}}

[[Category:Canvas GUI]]

PUI

2023-04-22T08:16:53Z

Hooray: /* Canvas Emulation */

{{Feature to be removed|version=2023.3|reason=[[Plib]]/PUI is to be removed and replaced by a [[Canvas widget matrix|Canvas/Nasal based solution]] to help improve compatibility with [[OSG]] 3.6+ and [[OpenGL]] 4.x ([[Core Profile support|OpenGL Core Profile]], see [[2022.X Release plan]] ) and improve performance by [[Unifying the 2D rendering backend via canvas|phasing out legacy OpenGL code]]. Therefore, people should be careful when extending the '''PUI''' based legacy GUI engine<ref>https://sourceforge.net/p/flightgear/mailman/message/34921495/</ref><ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35157325/
|title = <nowiki> Re: [Flightgear-devel] GUI options (Was: Aircraft center) </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jun 14th, 2016
|added = Jun 14th, 2016
|script_version = 0.40
}}</ref> and coordinate any related work with the devel mailing list first-this applies particularly to adding any [[Template:PUI_widget|additional hard-coded PUI widgets]]. }}
[[File:Exit.png|thumb|FlightGear GUI dialog (exit.xml)stored in $FG_ROOT/gui/dialogs]]
{{GUI Navbar}}

[[File:Custom-autopilot-dialog.png|right|200px]]
[[PUI]] is the standard GUI engine used in FlightGear, it is part of [[PLIB]] and is using raw, fixed-pipeline, [[OpenGL]] code internally (no [[OpenSceneGraph]]). As of mid 2021, FlightGear is in the process of working towards adopting the OpenGL Core Profile, this means that [[PUI]] is causing trouble and needs to be replaced/disabled or ported.

PUI provides a fairly basic, but robust, set of widgets. PUI is also used for rendering the [[Menubar]].

FlightGear uses a GUI widget set that is implemented on top of raw (legacy) [[OpenGL]]. This has many advantages from a portability standpoint and from the standpoint of integrating with window systems. [[PUI]] doesn't have every feature under the sun, but it was never meant to. It's relatively small, lean, mean, and written on top of [[OpenGL]] which makes life *much* easier for us.

[[PUI]] already is a separate distinct library within Plib. It depends on some central utility stuff, but that's about it. So it is pretty stripped down and separate already.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg26011.html</ref>

We are to some extent hamstrung by the rather old GUI toolkit we use. However, replacing that is going to be non-trivial, and it would affect not just the core GUI but also all the dialog boxes that have been set up for particular aircraft.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg25985.html</ref>

Flightgear can look amazing when you use the HDR pipeline. We absolutely need this to stay relevant. The problem is that HDR is not compatible with OpenGL1 PUI. Work on getting rid of PUI has been going on for over a decade (longer than it took to implement it).<ref>https://sourceforge.net/p/flightgear/mailman/message/37727346/</ref>

[[File:menubar2.jpg|517px]]

== Replacement status ==
{{See also|FlightGear_and_OpenGL_ES#Example:_disabling_PUI}}

{{Note| Update 09/2022: The PUI replacement [[QtQuick_use_in_FlightGear#Background|was going to be Qt]] but it started to get very complicated with changes in Qt 5.15 + Qt 6, so James is going with a more light-weight Canvas based approach now.

Qt added support for Vulkan / Metal / D3D starting in 5.15, but FlightGear / OpenSceneGraph can’t support those, so integrating the two renderers went from being ‘complicated but ok’ to ‘very very complicated’.

So now James is going with something much more lightweight using some C++ compatibility code, some Nasal for styling and the existing [[Canvas widgets|Canvas widget rendering]] from Thomas Geymayer (TheTom) with [[Canvas Widget Matrix|some extensions and additions]], based on the [[Howto:Processing_legacy_PUI_dialogs_using_Canvas#Original_Discussion|plans originally discussed when the Canvas GUI system was added to FlightGear]]: some pieces are in FlightGear & FGData already.

James has basic dialogs working okay but not the more complex ones and everything looks kind of ugly, he needs to improve the visual look before he shares screenshots to avoid everyone freaking out :) The disadvantage of this approach is James is far from expert at creating visual appearances this way, so it’s kind on unrewarding and slow for him. If someone likes messing with CSS-type styling, border-images and hover-states, ping him since we could probably move things also faster <ref>https://sourceforge.net/p/flightgear/mailman/message/37701750/</ref>}}

=== Motivation ===
{{Main article|Core Profile support}}

The bigger issue here is we need to ditch [[PUI]] (which is in progress) and some OpenGL 1.0 code (HUD, 2D panels especially - can be #ifdef for now) so we can enable Core profile on Mac - since Mac 4.x support (we only hit about 4.3 alas, but with some extensions to get in sight of 4.5) is Core profile only, no Compatability mode.

Improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, many people are convinced PUI needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

While most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so [using Qt5] would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

== Canvas Emulation ==
{{See also|Canvas widget matrix}}
'''Last updated: 04/2023 <ref>https://sourceforge.net/p/flightgear/mailman/message/37805054/</ref>
'''
[[File:Environment-dlg-via-canvas-bridge-04-2023.png|thumb|Screen shot showing the XMLDialog.nas bridge in use to parse/render the environment.xml PUI/XML dialog (unmodified)]]
=== Status ===
As of 01/2023, the replacement for PUI is making good progress<ref>https://sourceforge.net/p/flightgear/mailman/message/37765706/</ref>.

In February 2022, James reported having something in progress locally, and that should even be something we can try in March/April 2022. Hopefully that’s quick enough, knowing it has been a long time coming.<ref>https://sourceforge.net/p/flightgear/mailman/message/37606439/</ref>

There's now an XML to Nasal bridge, to keep PUI dialogs working (Disabled by a CMake option)
This is implemented on top of the [[Canvas]] system.

This builds equivalent C++ objects to what the [[PUI]] dialogs build, with properties exposed to Nasal.
Peer objects are created by Nasal [[callbacks]], which can implement the various dialog functions needed to keep compatibility, especially the [[#Background|‘update’ and ‘apply’ hooks]].<ref>https://sourceforge.net/p/flightgear/flightgear/ci/cbd5ef9e7b8f433dbc1ba97bae7d7cfc894e7cef/</ref>

{{Note|The PUI Compatible Canvas GUI is a compile time option: Use the following [[Building using CMake|cmake option]] to enable this code: {{CMake Build Option|option=ENABLE_PUICOMPAT|default=ON|description=This requires latest SG/FG AND FGDATA}}. But this is all highly fluid and most of it really developer only. At one point they will become default or be accessible in the launcher.<ref>https://sourceforge.net/p/flightgear/mailman/message/37834004/</ref>

If you compiled with PUICompatibility enabled, but still don't see any dialogs - only the menubar, you might need to enable the GUI module in defaults.xml<ref>https://sourceforge.net/p/flightgear/mailman/message/37833149/</ref>}}

The new Compatibility files can now be found in $FG_SRC/GUI:

* {{flightgear file|src/GUI/FGPUICompatDialog.cxx }}
* {{flightgear file|src/GUI/FGPUICompatDialog.hxx }}
* {{flightgear file|src/GUI/PUICompatObject.cxx }}

01/2023: James is slowly working on creating the pop-up menu and combo-box widgets [...]

One of the major things slowing down James' work on the popup-menu and combo box is time to restart the simulator for each change, he is looking for some solution to re-load the widget Nasal code independently. <ref><https://sourceforge.net/p/flightgear/mailman/message/37756183/</ref>

James has done about 75% (hah!) of the C++ work to enable live reloading of modules this way, but unfortunately there are some code paths that would become crashy if you use the feature for the Canvas: because it would reference the ‘old’ (pre-reload) Nasal code, and not the new one, and therefore you’d get a weird mix of old and new, and then just crash the sim. To fix it properly I need to track down those places that store a reference to Canvas and give them a re-init method, so we don’t keep the stale references.

The general non-fun-ness of that kind of debugging is James has been making such slow progress on my PUI replacement widgets recently <ref>https://sourceforge.net/p/flightgear/mailman/message/37756263/</ref>

=== Todo ===
Nothing in particular: help debugging the grid layout (which is in simgear) would be good. For now, you could create a grid layout manually using some Nasal.

For the menubar, we need to expose the C++ data to Nasal: we need a FGCompatMenuBar (alongisde FGPUIMenuBar) implementing FGMenubar which calls _createMenuObject in MenuBar.nas, using the same way I lookup and call _createDialogPeer in XMLDialog.nas

(Make sure you don’t break the macOS native menubar in the process!)

You can probably pass a wrapped SGpropertyNode into this, and then fill in the stubs in that file to use the Menu widgets Frederic has written.

Global menu keybindings won’t worry but don’t touch that, I have a separate plan for it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37805736/</ref>

As of 04/2023, remaining items on the todo list are: <ref>https://sourceforge.net/p/flightgear/mailman/message/37805060/</ref>

* Grid layout
** GridLayout needs debugged: After this, the basic UI is usable, would probably make it a switchable option on ‘next’ (I can already use the simulator with the new UI today, but all the sizes are off in the grid layouts which we use everywhere)

* list
* table (and tree ?) models corresponding views
* waypoint list
* Re-write the waypoint list and airport dialog to work again (since these use custom widgets):
** log list
** airport-list equivalents
* Nasal access to the menu i18n functions
* selection support for single- and multi-line text (which is being worked on -> CanvasPangoText)
* Keyboard shortcut handling, although this is not really a PUI vs replacement issue, to me we should handle UI shortcuts in the same was normal keyboard.xml shortcuts
** this previously worked because PUI got ‘first chance’ at handling key input. But we always had duplication between keyboard.xml and other places, so I would rather standardise on keyboard.xml, but allow a UI element to set a scope for shortcuts. (So that Copy/paste shortcuts etc can work in a text input, at least … but probably some other standard ones) <ref>https://sourceforge.net/p/flightgear/mailman/message/37805188/</ref>
* Ensure all the places which use the PUI combo-box and list-widget work : there’s a few of these.

The CanvasPangoText stuff is needed but we can perfectly well run the UI on next without it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37805176/</ref>

=== Parser ===
{{Main article|pui2canvas}}
The corresponding Nasal/Canvas module to dynamically "translate" legacy PUI/XML dialogs into Canvas dialogs (at runtime), is to be found in {{fgdata file|Nasal/gui/XMLDialog.nas}} <ref>https://sourceforge.net/p/flightgear/fgdata/ci/fe7c87b21a69f88ddb87d89453c48d12b69660e2/</ref>

=== Widgets ===
{{Main article|Howto:Creating a Canvas GUI Widget}}

It’s split between Simgear (see classes with widget / layout in the name) and in FGData. (Eg widgets/Button.nas) To be able to use the existing dialog XML files un-modified (which is a design goal), James is extending the widget types with many additional ones (eg PUI has slider, dial, combo-box, checkbox, all of which need to be created, see [[Canvas widget matrix]].

This is about 30% done and is the bit he's very slow at). Thomas’s canvas widgets have a very good separation of API + state from appearance, so all styling is in its own file, and James is being very strict about maintaining this separation, so we also retain the re-styling feature of the PUI UI, which many people also rely on. This does make the process of adding new widgets more complex, however.

{{See also|Canvas widgets}}

=== Layouting ===
The other thing is to preserve all the layouting: James has added a grid layout to Simgear, since that is supported by the existing PUI code (even though the layouts are not actually part of PUI itself). The problem is getting the sizing / hinting of all the widgets to match the PUI values, so that dialogs look approximately the same under the new UI as they did with PUI; again this a design goal so that all existing dialogs in aircraft and add-ons, which we can’t update, continue to work and be usable. Debugging that is also proving quite tricky, since there’s all kinds of hard-coded assumptions built into PUI widgets about pixels, font-sizes etc which are not true in the new system.<ref>https://sourceforge.net/p/flightgear/mailman/message/37701792/</ref>

== Background ==
In FlightGear, PUI dialogs are standard [[PropertyList XML File]]s that are stored in $FG_ROOT/gui/dialogs, they can contain the widgets mentioned in {{readme file|gui}}, using a simple layout engine discussed in {{readme file|layout}}, and bindings using a combination of so called fgcommands operating on properties (see {{readme file|commands}}) and custom [[Nasal]] (FlightGear scripting) code.

In addition, each PUI/XML dialog may contain Nasal script sections that are executed when opening/closing the dialog, a feature which is commonly used for procedurally creating/updating widgets using the [[Nasal_library#cmdarg.28.29|cmdarg() API]], which allows the dialog tree to be traversed and manipulated prior to the dialog being rendered.
Widgets can be conditionally hidden/shown using a wrapper for [[Conditions|SGCondition]] in [[Nasal_library/props|props.nas]]
The <code>canvas</code> widget also supports its own embedded Nasal code section to execute arbitrary widget specific Nasal code upon opening/closing the dialog/widget.

PUI/XML dialogs can be loaded, dynamically created, updated and closed using a handful of fgcommands:
* {{fgcommand|dialog-new}}
* {{fgcommand|dialog-show}}
* {{fgcommand|dialog-update}}
* {{fgcommand|dialog-apply}}
* {{fgcommand|dialog-close}}

PUI related OpenGL code is particularly infamous for causing rendering artifacts for people on AMD/ATI and Intel hardware (especially in combination with certain fonts/styles and [[Effects|effects]]/[[Shaders|shaders]]), see {{Issue|2213}}.

PUI is also known to affect rendering performance quite significantly (see {{search |keywords=anthrax+gui}}), while also preventing FlightGear from using a more recent version of OpenGL<ref>http://sourceforge.net/p/flightgear/mailman/message/34532040/</ref><ref>http://forum.flightgear.org/viewtopic.php?f=71&t=24046</ref>.

However, improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Besides, while most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

But given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, graphics folks are also convinced it needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

In addition, [[OpenSceneGraph]] (OSG) can obviously not help optimize any PUI related GL code and PUI widgets are generally considered to be pretty archaic and not easy to extend<ref>http://sourceforge.net/p/flightgear/mailman/message/26832164/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587120/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587272/</ref>.

{{Note|We use the GUI code from PLIB, which doesn't know anything about OSG. See the SGPuDrawable class in $FG_SRC/Viewer/renderer.cxx for the implementation. The one catch is that OSG has a strong notion of separation between the update of a "scene" and its rendering, and that might not play well with arbitrary existing OpenGL code. }}

As of late 2015, there is heavy activity towards providing alternatives to a PUI-based UI:
* [[Integrated Web GUI]] (external, browser-based - fully asynchronous)
* [[Howto:Processing legacy PUI dialogs using Canvas]] (internal, using the [[Canvas]] system and a simple [[Nasal]] parser to deal with existing PUI/XML dialogs)

<gallery mode="packed">
Early-Phi-screen shot.PNG|Screenshot showing [[Phi]]
About-dialog-rendered-by-canvas.png|Screenshot showing a dialog rendered by the [[Howto:Processing legacy PUI dialogs using Canvas|pui2canvas parser]]
</gallery>

== History ==
{{See also|QtQuick use in FlightGear}}
{{Caution|This is merely kept for future reference, many of the ideas discussed below have become obsolete as of 09/2022, if in doubt, please get in touch via devel-list.}}
=== 2021 ===
In early 2021, James did a brief evaluation of [https://github.com/ocornut/imgui ImGUI] as a possibility - he's also evaluating it in some projects at his day job.

The API is interesting if you’re starting from scratch and only exclusively in C++, but it’s not a great fit for how we define GUIs in FG (via [[XML]]/[[Nasal]]): there is no back door that he could find, to access the persistent state of the GUI, or build it up in a data-driven way. So making a mapping to keep our existing GUI XML working (and updating correctly) becomes a bit of a chore.<ref>https://sourceforge.net/p/flightgear/mailman/message/37295586/</ref>

Pretty much all of the FlightGear GUI is defined in XML space, except for a few oddments. Let’s say 95% at this point.

Additionally, even if we were to change that for the core sim (and James' current plan is to keep the XML syntax and just extend it), the installed base of '''aircraft''' ship their own XML dialogs (eg., replacing the autopilot dialog with a custom one, or just adding their own aircraft-specific helper controls for doors / lights / cargo / whatever). So even if we found the most sublimely beautiful, intuitive, compact GUI description language in the world, we have to keep the XML syntax working as-is, for the foreseeable future.

Given this, James' intention is to replace the output side [[PUI]] but keep the front-end side (XML / properties / bindings) unchanged, and therefore backwards compatible, and simply add some new types / options / widget types going forward. This will mean we still have to deal with the slightly cumbersome XML+Nasal syntax, but, well, it’s not *that* cumbersome. <ref>https://sourceforge.net/p/flightgear/mailman/message/37296280/</ref>

In mid 2021, James reported that he is working on some ‘PUICompat’ classes which hold/own/represent the GUI state in C++, but which can be used with [[Nasal/CppBind|Nasal CppBind]]. And of course we could indeed expose those later on. <ref>https://sourceforge.net/p/flightgear/mailman/message/37297727/</ref>

In July 2021, James suggested not to worry about the existing GUI code, it’s going in the bin.<ref>https://sourceforge.net/p/flightgear/mailman/message/37325905/</ref>

For the time being, the in-sim GUi can’t do Unicode yet, but James is working on it, hopefully available soon.<ref>https://sourceforge.net/p/flightgear/mailman/message/37328200/</ref>
Also, the in-sim menubar will change with the new GUI, *and* we use a native menubar on macOS. Until James replaces the PUI fonts we can’t use Unicode symbols. So, will have to come back to it once the new GUI is merged.<ref>https://sourceforge.net/p/flightgear/mailman/message/37327237/</ref>

=== 2020 ===
As of 03/2020, the PLIB replacement was reported to be in the backlog <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36951255/
|title = <nowiki>Re: [Flightgear-devel] C++ and/or OSG question </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Mar 18th, 2020
|added = Mar 18th, 2020
|script_version = 0.50
}}</ref>.

With PLIB replacement work likely being re-scheduled for [[Post FlightGear 2020.2 LTS changes]] <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36985375/
|title = <nowiki>Re: [Flightgear-devel] Working Group Proposal - Boost and PLIB replacement - Delegation and Teamwork </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = April 18th, 2020
|added = April 18th, 2020
|script_version = 1.10
}}</ref>.

In 08/2020, James stated that he was still working (exceptionally slowly!) on replacing PUI (as part of removing legacy OpenGL code (PUI, HUD, 2d panels, porting Canvas away form ShivaVG), so we can switch to Vulkan/VSG at some point (ideally at some point before Apple turn off OpenGL support…)), and that he doesn't think /any/ of us *want* to be working on these features particularly, but projects like these need to be done before anyone can have fun with VSG or Vulkan (personally James would be very enthusiastic about working on VSG support (being on macOS, I also have the most to lose / gain from it)). Sometimes that’s just how it goes. Equally they will all benefit the project ultimately, but the payoff both for the individual and the project is very drawn out. <ref>https://sourceforge.net/p/flightgear/mailman/message/37077158/</ref>

In 10/2020, the estimation is that PUI should be going away really ‘soon’, the replacement code is already in next / 2020.2. (There’s no plan to actually /use/ the new UI code in 2020.2, but if the bugs in it prove simple, we could actually turn it for specific dialog: it seems very unlikely this makes sense for a stable release however)<ref>https://sourceforge.net/p/flightgear/mailman/message/37123818/</ref>

The fixed-function removal, is actively in hand (Gaetan is working on the 2D panel part, and James is going to focus on PUI in the rest of 2020). James hopes that means next year he can focus on Vulkan, or at least, using OSG as if /were/ VSG, so the migration in a year or two when VSG is stable, is not so painful.<ref>https://sourceforge.net/p/flightgear/mailman/message/37129098/</ref>

The PUI UI and replacement can co-exist in the same build (they already do, effectively.<ref>https://sourceforge.net/p/flightgear/mailman/message/37131297/</ref>

In 11/2020, James suggested not to worry about details such as PUI styling/theming etc: we’re not making such changes for the LTS, and PUI should be gone before the next release.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142225/</ref> Also, he recommended (to everyone) to stop touching GUI stuff for a few weeks, as he's about to turn it all on its head.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142356/</ref>

=== 2019 ===
The new GUI has been incubating for a few years, but there's apparently been a lot of progress as of 10/2019.

It is likely the new GUI will be a user opt-in feature - at least initially. The sunset of the PLIB library _could_ happen relatively soon, but
people will need to see the new GUI and react to it before we could commit to PLIB removal <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36784489/
|title = <nowiki>Re: [Flightgear-devel] in Flightgear/Simgear C++ Code: What needs Doing? What are YOU Doing? What would you do if you had the time? </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Oct 14th, 2019
|added = Oct 14th, 2019
|script_version = 0.50
}}</ref>.

In 02/2019, James stated that the new UI is coming quite soon. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36589420/
|title = <nowiki> Re: [Flightgear-devel] Lagging </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Feb 17th, 2019
|added = Feb 17th, 2019
|script_version = 0.40
}}</ref>

=== 2018 ===
{{See also|QtQuick use in FlightGear}}

According to James, we have to accept that changes like testing or making [[PUI]] a modular thing or moving the JS code tend to have an immediate pain for some people (because strange stuff gets broken, and takes some time to get fixed), whereas the payoff in terms of improved joystick handling or replacing the UI or testing of all subsystems will take some months or years to be felt.<ref>https://sourceforge.net/p/flightgear/mailman/message/36323240/</ref>

James said he was in the middle of porting the launcher’s final tab (location) to the new UI scheme, once that’s done he will start sketching out the ‘in sim’ settings UI using the same pieces. He’ll send a request for contributions around about that in the next three-four weeks, once he has enough templates & examples that there is a clear pattern to follow.<ref>https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/2d10f16c-ddc8-07f3-07e7-eca2a0a0d55f%40zaretto.com/#msg36293586</ref>

James announced that the launcher is now feature complete with the QtQuick UI, he’ll keep making bug-fixes of course as people report them, but my todo list for the core features is now done<ref>https://sourceforge.net/p/flightgear/mailman/message/36355833/</ref>.

=== 2017 ===

In 10/2017, James said he was getting really close to having the PUI replacement UI suitable for beta-testing.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36067646/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 7th, 2017
|added = Oct 7th, 2017
|script_version = 0.40
}}</ref>

Originally, James was hoping to land the PUI replacement GUI in the last dev cycle in 2017 (at least as a proof-of-concept, probably not as the default UI), so wouldn’t expend lots of effort on things like collapsible sections which might be a lot of work with the current PUI/Canvas approaches, but are trivial with the new [[QtQuick use in FlightGear|QtQuick based UI scheme]].<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36059822/
|title = <nowiki> Re: [Flightgear-devel] Canvas MapLayer for OpenStreetMap, OpenAIP,
VFR Sectionals </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 1st, 2017
|added = Oct 1st, 2017
|script_version = 0.40
}}</ref>

Once the basic new UI is in place we can experiment with different re-arrangements easily, without being limited by PUI. (James expects PUI to live on as the default / alternate UI while this happens)<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36061229/
|title = <nowiki> Re: [Flightgear-devel] FGFS macOS Menubar </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 2nd, 2017
|added = Oct 2nd, 2017
|script_version = 0.40
}}</ref>

Technically, this entails replacing dialog.cxx with some code which builds up some special ‘PUI-Emulation’ QtQuick controls, so that existing dialogs (especially from Aircraft) continue to work. This mode will look somewhat ugly but hopefully no more ugly than PUI! And it helps that the set of widgets we have in PUI is limited, and the ‘tricky’ widgets (map, scrolling list, etc) are in the dialogs will will replace with new ones first.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068767/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

This PUI emulation isn't going to use any code from PLIB<ref>https://sourceforge.net/p/flightgear/mailman/message/36985303/</ref>, so what will remain from it in FG afterwards will be the FNT and JS components (reworked).<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068817/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> Florent Rougon </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

=== 2016 ===
We need to explore if Qt Quick or widgets is the better way to go, with a preference towards Qt Quick, since it will allow things closer to current PUI (semi-transparent widgets on top of the 3D content). It still allows creating separate windows too (Erik’s use case), but means we get consistent, custom theming on all platforms, since standard desktop look is not so nice for a flight-sim.

James intention is to make a QML-hosting OSG-drawable, and add this as a concept in Qt-enabled builds, then port some PUI dialogs to it, and see how easy / painful the process is. Hell create some QObjects which expose commands and the property tree and Nasal.

This has the advantage of not touching the OSG window at all, QtQuick simply provides some additional OpenGL rendering on top, which we pass events to - pretty much exactly the same as what we already do for PUI, and hopefully can co-exist with it. James got this working in a local OSG tree in a standalone demo, but that’s based on osgQt - he wants to see if he can make it work on a normal, non-Qt OSG window inside FlightGear.<ref>https://sourceforge.net/p/flightgear/mailman/message/35156051/</ref>

The idea is to host an XML dialog (Currently done with PUI) from Qt also. The question is if that can be done keeping ‘source compatibility’ exactly with the current UI XML and Nasal interface. It probably can be, but many of the PUI widgets have really ugly APIs, especially for combo-boxes, drop-down menus and scrolling lists, where it makes sense to map a Nasal class to a Qt ItemModel, which would be more elegant and easy to work with in both Nasal and integrate on the Qt side. But obviously would mean changing the dialog sources.

Of course, aircraft dialogs tend to be simpler, and not use the more complex PUI widgets, precisely for reasons like this, but that’s a limitation it would be best to remove.<ref>https://sourceforge.net/p/flightgear/mailman/message/35155721/</ref>


== References ==
{{Appendix}}

[[Category:PUI| ]]
[[Category:Rendering roadblocks]]

PUI

2023-04-22T08:16:32Z

Hooray: /* Canvas Emulation */ add screen shot

{{Feature to be removed|version=2023.3|reason=[[Plib]]/PUI is to be removed and replaced by a [[Canvas widget matrix|Canvas/Nasal based solution]] to help improve compatibility with [[OSG]] 3.6+ and [[OpenGL]] 4.x ([[Core Profile support|OpenGL Core Profile]], see [[2022.X Release plan]] ) and improve performance by [[Unifying the 2D rendering backend via canvas|phasing out legacy OpenGL code]]. Therefore, people should be careful when extending the '''PUI''' based legacy GUI engine<ref>https://sourceforge.net/p/flightgear/mailman/message/34921495/</ref><ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35157325/
|title = <nowiki> Re: [Flightgear-devel] GUI options (Was: Aircraft center) </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jun 14th, 2016
|added = Jun 14th, 2016
|script_version = 0.40
}}</ref> and coordinate any related work with the devel mailing list first-this applies particularly to adding any [[Template:PUI_widget|additional hard-coded PUI widgets]]. }}
[[File:Exit.png|thumb|FlightGear GUI dialog (exit.xml)stored in $FG_ROOT/gui/dialogs]]
{{GUI Navbar}}

[[File:Custom-autopilot-dialog.png|right|200px]]
[[PUI]] is the standard GUI engine used in FlightGear, it is part of [[PLIB]] and is using raw, fixed-pipeline, [[OpenGL]] code internally (no [[OpenSceneGraph]]). As of mid 2021, FlightGear is in the process of working towards adopting the OpenGL Core Profile, this means that [[PUI]] is causing trouble and needs to be replaced/disabled or ported.

PUI provides a fairly basic, but robust, set of widgets. PUI is also used for rendering the [[Menubar]].

FlightGear uses a GUI widget set that is implemented on top of raw (legacy) [[OpenGL]]. This has many advantages from a portability standpoint and from the standpoint of integrating with window systems. [[PUI]] doesn't have every feature under the sun, but it was never meant to. It's relatively small, lean, mean, and written on top of [[OpenGL]] which makes life *much* easier for us.

[[PUI]] already is a separate distinct library within Plib. It depends on some central utility stuff, but that's about it. So it is pretty stripped down and separate already.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg26011.html</ref>

We are to some extent hamstrung by the rather old GUI toolkit we use. However, replacing that is going to be non-trivial, and it would affect not just the core GUI but also all the dialog boxes that have been set up for particular aircraft.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg25985.html</ref>

Flightgear can look amazing when you use the HDR pipeline. We absolutely need this to stay relevant. The problem is that HDR is not compatible with OpenGL1 PUI. Work on getting rid of PUI has been going on for over a decade (longer than it took to implement it).<ref>https://sourceforge.net/p/flightgear/mailman/message/37727346/</ref>

[[File:menubar2.jpg|517px]]

== Replacement status ==
{{See also|FlightGear_and_OpenGL_ES#Example:_disabling_PUI}}

{{Note| Update 09/2022: The PUI replacement [[QtQuick_use_in_FlightGear#Background|was going to be Qt]] but it started to get very complicated with changes in Qt 5.15 + Qt 6, so James is going with a more light-weight Canvas based approach now.

Qt added support for Vulkan / Metal / D3D starting in 5.15, but FlightGear / OpenSceneGraph can’t support those, so integrating the two renderers went from being ‘complicated but ok’ to ‘very very complicated’.

So now James is going with something much more lightweight using some C++ compatibility code, some Nasal for styling and the existing [[Canvas widgets|Canvas widget rendering]] from Thomas Geymayer (TheTom) with [[Canvas Widget Matrix|some extensions and additions]], based on the [[Howto:Processing_legacy_PUI_dialogs_using_Canvas#Original_Discussion|plans originally discussed when the Canvas GUI system was added to FlightGear]]: some pieces are in FlightGear & FGData already.

James has basic dialogs working okay but not the more complex ones and everything looks kind of ugly, he needs to improve the visual look before he shares screenshots to avoid everyone freaking out :) The disadvantage of this approach is James is far from expert at creating visual appearances this way, so it’s kind on unrewarding and slow for him. If someone likes messing with CSS-type styling, border-images and hover-states, ping him since we could probably move things also faster <ref>https://sourceforge.net/p/flightgear/mailman/message/37701750/</ref>}}

=== Motivation ===
{{Main article|Core Profile support}}

The bigger issue here is we need to ditch [[PUI]] (which is in progress) and some OpenGL 1.0 code (HUD, 2D panels especially - can be #ifdef for now) so we can enable Core profile on Mac - since Mac 4.x support (we only hit about 4.3 alas, but with some extensions to get in sight of 4.5) is Core profile only, no Compatability mode.

Improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, many people are convinced PUI needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

While most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so [using Qt5] would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

== Canvas Emulation ==
{{See also|Canvas widget matrix}}
'''Last updated: 04/2023 <ref>https://sourceforge.net/p/flightgear/mailman/message/37805054/</ref>
'''
[[File:Environment-dlg-via-canvas-bridge-04-2023.png|thumb|Screen shot showing the XMLDialog.nas in use to parse/render the environment.xml PUI/XML dialog (unmodified)]]
=== Status ===
As of 01/2023, the replacement for PUI is making good progress<ref>https://sourceforge.net/p/flightgear/mailman/message/37765706/</ref>.

In February 2022, James reported having something in progress locally, and that should even be something we can try in March/April 2022. Hopefully that’s quick enough, knowing it has been a long time coming.<ref>https://sourceforge.net/p/flightgear/mailman/message/37606439/</ref>

There's now an XML to Nasal bridge, to keep PUI dialogs working (Disabled by a CMake option)
This is implemented on top of the [[Canvas]] system.

This builds equivalent C++ objects to what the [[PUI]] dialogs build, with properties exposed to Nasal.
Peer objects are created by Nasal [[callbacks]], which can implement the various dialog functions needed to keep compatibility, especially the [[#Background|‘update’ and ‘apply’ hooks]].<ref>https://sourceforge.net/p/flightgear/flightgear/ci/cbd5ef9e7b8f433dbc1ba97bae7d7cfc894e7cef/</ref>

{{Note|The PUI Compatible Canvas GUI is a compile time option: Use the following [[Building using CMake|cmake option]] to enable this code: {{CMake Build Option|option=ENABLE_PUICOMPAT|default=ON|description=This requires latest SG/FG AND FGDATA}}. But this is all highly fluid and most of it really developer only. At one point they will become default or be accessible in the launcher.<ref>https://sourceforge.net/p/flightgear/mailman/message/37834004/</ref>

If you compiled with PUICompatibility enabled, but still don't see any dialogs - only the menubar, you might need to enable the GUI module in defaults.xml<ref>https://sourceforge.net/p/flightgear/mailman/message/37833149/</ref>}}

The new Compatibility files can now be found in $FG_SRC/GUI:

* {{flightgear file|src/GUI/FGPUICompatDialog.cxx }}
* {{flightgear file|src/GUI/FGPUICompatDialog.hxx }}
* {{flightgear file|src/GUI/PUICompatObject.cxx }}

01/2023: James is slowly working on creating the pop-up menu and combo-box widgets [...]

One of the major things slowing down James' work on the popup-menu and combo box is time to restart the simulator for each change, he is looking for some solution to re-load the widget Nasal code independently. <ref><https://sourceforge.net/p/flightgear/mailman/message/37756183/</ref>

James has done about 75% (hah!) of the C++ work to enable live reloading of modules this way, but unfortunately there are some code paths that would become crashy if you use the feature for the Canvas: because it would reference the ‘old’ (pre-reload) Nasal code, and not the new one, and therefore you’d get a weird mix of old and new, and then just crash the sim. To fix it properly I need to track down those places that store a reference to Canvas and give them a re-init method, so we don’t keep the stale references.

The general non-fun-ness of that kind of debugging is James has been making such slow progress on my PUI replacement widgets recently <ref>https://sourceforge.net/p/flightgear/mailman/message/37756263/</ref>

=== Todo ===
Nothing in particular: help debugging the grid layout (which is in simgear) would be good. For now, you could create a grid layout manually using some Nasal.

For the menubar, we need to expose the C++ data to Nasal: we need a FGCompatMenuBar (alongisde FGPUIMenuBar) implementing FGMenubar which calls _createMenuObject in MenuBar.nas, using the same way I lookup and call _createDialogPeer in XMLDialog.nas

(Make sure you don’t break the macOS native menubar in the process!)

You can probably pass a wrapped SGpropertyNode into this, and then fill in the stubs in that file to use the Menu widgets Frederic has written.

Global menu keybindings won’t worry but don’t touch that, I have a separate plan for it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37805736/</ref>

As of 04/2023, remaining items on the todo list are: <ref>https://sourceforge.net/p/flightgear/mailman/message/37805060/</ref>

* Grid layout
** GridLayout needs debugged: After this, the basic UI is usable, would probably make it a switchable option on ‘next’ (I can already use the simulator with the new UI today, but all the sizes are off in the grid layouts which we use everywhere)

* list
* table (and tree ?) models corresponding views
* waypoint list
* Re-write the waypoint list and airport dialog to work again (since these use custom widgets):
** log list
** airport-list equivalents
* Nasal access to the menu i18n functions
* selection support for single- and multi-line text (which is being worked on -> CanvasPangoText)
* Keyboard shortcut handling, although this is not really a PUI vs replacement issue, to me we should handle UI shortcuts in the same was normal keyboard.xml shortcuts
** this previously worked because PUI got ‘first chance’ at handling key input. But we always had duplication between keyboard.xml and other places, so I would rather standardise on keyboard.xml, but allow a UI element to set a scope for shortcuts. (So that Copy/paste shortcuts etc can work in a text input, at least … but probably some other standard ones) <ref>https://sourceforge.net/p/flightgear/mailman/message/37805188/</ref>
* Ensure all the places which use the PUI combo-box and list-widget work : there’s a few of these.

The CanvasPangoText stuff is needed but we can perfectly well run the UI on next without it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37805176/</ref>

=== Parser ===
{{Main article|pui2canvas}}
The corresponding Nasal/Canvas module to dynamically "translate" legacy PUI/XML dialogs into Canvas dialogs (at runtime), is to be found in {{fgdata file|Nasal/gui/XMLDialog.nas}} <ref>https://sourceforge.net/p/flightgear/fgdata/ci/fe7c87b21a69f88ddb87d89453c48d12b69660e2/</ref>

=== Widgets ===
{{Main article|Howto:Creating a Canvas GUI Widget}}

It’s split between Simgear (see classes with widget / layout in the name) and in FGData. (Eg widgets/Button.nas) To be able to use the existing dialog XML files un-modified (which is a design goal), James is extending the widget types with many additional ones (eg PUI has slider, dial, combo-box, checkbox, all of which need to be created, see [[Canvas widget matrix]].

This is about 30% done and is the bit he's very slow at). Thomas’s canvas widgets have a very good separation of API + state from appearance, so all styling is in its own file, and James is being very strict about maintaining this separation, so we also retain the re-styling feature of the PUI UI, which many people also rely on. This does make the process of adding new widgets more complex, however.

{{See also|Canvas widgets}}

=== Layouting ===
The other thing is to preserve all the layouting: James has added a grid layout to Simgear, since that is supported by the existing PUI code (even though the layouts are not actually part of PUI itself). The problem is getting the sizing / hinting of all the widgets to match the PUI values, so that dialogs look approximately the same under the new UI as they did with PUI; again this a design goal so that all existing dialogs in aircraft and add-ons, which we can’t update, continue to work and be usable. Debugging that is also proving quite tricky, since there’s all kinds of hard-coded assumptions built into PUI widgets about pixels, font-sizes etc which are not true in the new system.<ref>https://sourceforge.net/p/flightgear/mailman/message/37701792/</ref>

== Background ==
In FlightGear, PUI dialogs are standard [[PropertyList XML File]]s that are stored in $FG_ROOT/gui/dialogs, they can contain the widgets mentioned in {{readme file|gui}}, using a simple layout engine discussed in {{readme file|layout}}, and bindings using a combination of so called fgcommands operating on properties (see {{readme file|commands}}) and custom [[Nasal]] (FlightGear scripting) code.

In addition, each PUI/XML dialog may contain Nasal script sections that are executed when opening/closing the dialog, a feature which is commonly used for procedurally creating/updating widgets using the [[Nasal_library#cmdarg.28.29|cmdarg() API]], which allows the dialog tree to be traversed and manipulated prior to the dialog being rendered.
Widgets can be conditionally hidden/shown using a wrapper for [[Conditions|SGCondition]] in [[Nasal_library/props|props.nas]]
The <code>canvas</code> widget also supports its own embedded Nasal code section to execute arbitrary widget specific Nasal code upon opening/closing the dialog/widget.

PUI/XML dialogs can be loaded, dynamically created, updated and closed using a handful of fgcommands:
* {{fgcommand|dialog-new}}
* {{fgcommand|dialog-show}}
* {{fgcommand|dialog-update}}
* {{fgcommand|dialog-apply}}
* {{fgcommand|dialog-close}}

PUI related OpenGL code is particularly infamous for causing rendering artifacts for people on AMD/ATI and Intel hardware (especially in combination with certain fonts/styles and [[Effects|effects]]/[[Shaders|shaders]]), see {{Issue|2213}}.

PUI is also known to affect rendering performance quite significantly (see {{search |keywords=anthrax+gui}}), while also preventing FlightGear from using a more recent version of OpenGL<ref>http://sourceforge.net/p/flightgear/mailman/message/34532040/</ref><ref>http://forum.flightgear.org/viewtopic.php?f=71&t=24046</ref>.

However, improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Besides, while most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

But given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, graphics folks are also convinced it needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

In addition, [[OpenSceneGraph]] (OSG) can obviously not help optimize any PUI related GL code and PUI widgets are generally considered to be pretty archaic and not easy to extend<ref>http://sourceforge.net/p/flightgear/mailman/message/26832164/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587120/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587272/</ref>.

{{Note|We use the GUI code from PLIB, which doesn't know anything about OSG. See the SGPuDrawable class in $FG_SRC/Viewer/renderer.cxx for the implementation. The one catch is that OSG has a strong notion of separation between the update of a "scene" and its rendering, and that might not play well with arbitrary existing OpenGL code. }}

As of late 2015, there is heavy activity towards providing alternatives to a PUI-based UI:
* [[Integrated Web GUI]] (external, browser-based - fully asynchronous)
* [[Howto:Processing legacy PUI dialogs using Canvas]] (internal, using the [[Canvas]] system and a simple [[Nasal]] parser to deal with existing PUI/XML dialogs)

<gallery mode="packed">
Early-Phi-screen shot.PNG|Screenshot showing [[Phi]]
About-dialog-rendered-by-canvas.png|Screenshot showing a dialog rendered by the [[Howto:Processing legacy PUI dialogs using Canvas|pui2canvas parser]]
</gallery>

== History ==
{{See also|QtQuick use in FlightGear}}
{{Caution|This is merely kept for future reference, many of the ideas discussed below have become obsolete as of 09/2022, if in doubt, please get in touch via devel-list.}}
=== 2021 ===
In early 2021, James did a brief evaluation of [https://github.com/ocornut/imgui ImGUI] as a possibility - he's also evaluating it in some projects at his day job.

The API is interesting if you’re starting from scratch and only exclusively in C++, but it’s not a great fit for how we define GUIs in FG (via [[XML]]/[[Nasal]]): there is no back door that he could find, to access the persistent state of the GUI, or build it up in a data-driven way. So making a mapping to keep our existing GUI XML working (and updating correctly) becomes a bit of a chore.<ref>https://sourceforge.net/p/flightgear/mailman/message/37295586/</ref>

Pretty much all of the FlightGear GUI is defined in XML space, except for a few oddments. Let’s say 95% at this point.

Additionally, even if we were to change that for the core sim (and James' current plan is to keep the XML syntax and just extend it), the installed base of '''aircraft''' ship their own XML dialogs (eg., replacing the autopilot dialog with a custom one, or just adding their own aircraft-specific helper controls for doors / lights / cargo / whatever). So even if we found the most sublimely beautiful, intuitive, compact GUI description language in the world, we have to keep the XML syntax working as-is, for the foreseeable future.

Given this, James' intention is to replace the output side [[PUI]] but keep the front-end side (XML / properties / bindings) unchanged, and therefore backwards compatible, and simply add some new types / options / widget types going forward. This will mean we still have to deal with the slightly cumbersome XML+Nasal syntax, but, well, it’s not *that* cumbersome. <ref>https://sourceforge.net/p/flightgear/mailman/message/37296280/</ref>

In mid 2021, James reported that he is working on some ‘PUICompat’ classes which hold/own/represent the GUI state in C++, but which can be used with [[Nasal/CppBind|Nasal CppBind]]. And of course we could indeed expose those later on. <ref>https://sourceforge.net/p/flightgear/mailman/message/37297727/</ref>

In July 2021, James suggested not to worry about the existing GUI code, it’s going in the bin.<ref>https://sourceforge.net/p/flightgear/mailman/message/37325905/</ref>

For the time being, the in-sim GUi can’t do Unicode yet, but James is working on it, hopefully available soon.<ref>https://sourceforge.net/p/flightgear/mailman/message/37328200/</ref>
Also, the in-sim menubar will change with the new GUI, *and* we use a native menubar on macOS. Until James replaces the PUI fonts we can’t use Unicode symbols. So, will have to come back to it once the new GUI is merged.<ref>https://sourceforge.net/p/flightgear/mailman/message/37327237/</ref>

=== 2020 ===
As of 03/2020, the PLIB replacement was reported to be in the backlog <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36951255/
|title = <nowiki>Re: [Flightgear-devel] C++ and/or OSG question </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Mar 18th, 2020
|added = Mar 18th, 2020
|script_version = 0.50
}}</ref>.

With PLIB replacement work likely being re-scheduled for [[Post FlightGear 2020.2 LTS changes]] <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36985375/
|title = <nowiki>Re: [Flightgear-devel] Working Group Proposal - Boost and PLIB replacement - Delegation and Teamwork </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = April 18th, 2020
|added = April 18th, 2020
|script_version = 1.10
}}</ref>.

In 08/2020, James stated that he was still working (exceptionally slowly!) on replacing PUI (as part of removing legacy OpenGL code (PUI, HUD, 2d panels, porting Canvas away form ShivaVG), so we can switch to Vulkan/VSG at some point (ideally at some point before Apple turn off OpenGL support…)), and that he doesn't think /any/ of us *want* to be working on these features particularly, but projects like these need to be done before anyone can have fun with VSG or Vulkan (personally James would be very enthusiastic about working on VSG support (being on macOS, I also have the most to lose / gain from it)). Sometimes that’s just how it goes. Equally they will all benefit the project ultimately, but the payoff both for the individual and the project is very drawn out. <ref>https://sourceforge.net/p/flightgear/mailman/message/37077158/</ref>

In 10/2020, the estimation is that PUI should be going away really ‘soon’, the replacement code is already in next / 2020.2. (There’s no plan to actually /use/ the new UI code in 2020.2, but if the bugs in it prove simple, we could actually turn it for specific dialog: it seems very unlikely this makes sense for a stable release however)<ref>https://sourceforge.net/p/flightgear/mailman/message/37123818/</ref>

The fixed-function removal, is actively in hand (Gaetan is working on the 2D panel part, and James is going to focus on PUI in the rest of 2020). James hopes that means next year he can focus on Vulkan, or at least, using OSG as if /were/ VSG, so the migration in a year or two when VSG is stable, is not so painful.<ref>https://sourceforge.net/p/flightgear/mailman/message/37129098/</ref>

The PUI UI and replacement can co-exist in the same build (they already do, effectively.<ref>https://sourceforge.net/p/flightgear/mailman/message/37131297/</ref>

In 11/2020, James suggested not to worry about details such as PUI styling/theming etc: we’re not making such changes for the LTS, and PUI should be gone before the next release.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142225/</ref> Also, he recommended (to everyone) to stop touching GUI stuff for a few weeks, as he's about to turn it all on its head.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142356/</ref>

=== 2019 ===
The new GUI has been incubating for a few years, but there's apparently been a lot of progress as of 10/2019.

It is likely the new GUI will be a user opt-in feature - at least initially. The sunset of the PLIB library _could_ happen relatively soon, but
people will need to see the new GUI and react to it before we could commit to PLIB removal <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36784489/
|title = <nowiki>Re: [Flightgear-devel] in Flightgear/Simgear C++ Code: What needs Doing? What are YOU Doing? What would you do if you had the time? </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Oct 14th, 2019
|added = Oct 14th, 2019
|script_version = 0.50
}}</ref>.

In 02/2019, James stated that the new UI is coming quite soon. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36589420/
|title = <nowiki> Re: [Flightgear-devel] Lagging </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Feb 17th, 2019
|added = Feb 17th, 2019
|script_version = 0.40
}}</ref>

=== 2018 ===
{{See also|QtQuick use in FlightGear}}

According to James, we have to accept that changes like testing or making [[PUI]] a modular thing or moving the JS code tend to have an immediate pain for some people (because strange stuff gets broken, and takes some time to get fixed), whereas the payoff in terms of improved joystick handling or replacing the UI or testing of all subsystems will take some months or years to be felt.<ref>https://sourceforge.net/p/flightgear/mailman/message/36323240/</ref>

James said he was in the middle of porting the launcher’s final tab (location) to the new UI scheme, once that’s done he will start sketching out the ‘in sim’ settings UI using the same pieces. He’ll send a request for contributions around about that in the next three-four weeks, once he has enough templates & examples that there is a clear pattern to follow.<ref>https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/2d10f16c-ddc8-07f3-07e7-eca2a0a0d55f%40zaretto.com/#msg36293586</ref>

James announced that the launcher is now feature complete with the QtQuick UI, he’ll keep making bug-fixes of course as people report them, but my todo list for the core features is now done<ref>https://sourceforge.net/p/flightgear/mailman/message/36355833/</ref>.

=== 2017 ===

In 10/2017, James said he was getting really close to having the PUI replacement UI suitable for beta-testing.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36067646/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 7th, 2017
|added = Oct 7th, 2017
|script_version = 0.40
}}</ref>

Originally, James was hoping to land the PUI replacement GUI in the last dev cycle in 2017 (at least as a proof-of-concept, probably not as the default UI), so wouldn’t expend lots of effort on things like collapsible sections which might be a lot of work with the current PUI/Canvas approaches, but are trivial with the new [[QtQuick use in FlightGear|QtQuick based UI scheme]].<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36059822/
|title = <nowiki> Re: [Flightgear-devel] Canvas MapLayer for OpenStreetMap, OpenAIP,
VFR Sectionals </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 1st, 2017
|added = Oct 1st, 2017
|script_version = 0.40
}}</ref>

Once the basic new UI is in place we can experiment with different re-arrangements easily, without being limited by PUI. (James expects PUI to live on as the default / alternate UI while this happens)<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36061229/
|title = <nowiki> Re: [Flightgear-devel] FGFS macOS Menubar </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 2nd, 2017
|added = Oct 2nd, 2017
|script_version = 0.40
}}</ref>

Technically, this entails replacing dialog.cxx with some code which builds up some special ‘PUI-Emulation’ QtQuick controls, so that existing dialogs (especially from Aircraft) continue to work. This mode will look somewhat ugly but hopefully no more ugly than PUI! And it helps that the set of widgets we have in PUI is limited, and the ‘tricky’ widgets (map, scrolling list, etc) are in the dialogs will will replace with new ones first.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068767/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

This PUI emulation isn't going to use any code from PLIB<ref>https://sourceforge.net/p/flightgear/mailman/message/36985303/</ref>, so what will remain from it in FG afterwards will be the FNT and JS components (reworked).<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068817/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> Florent Rougon </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

=== 2016 ===
We need to explore if Qt Quick or widgets is the better way to go, with a preference towards Qt Quick, since it will allow things closer to current PUI (semi-transparent widgets on top of the 3D content). It still allows creating separate windows too (Erik’s use case), but means we get consistent, custom theming on all platforms, since standard desktop look is not so nice for a flight-sim.

James intention is to make a QML-hosting OSG-drawable, and add this as a concept in Qt-enabled builds, then port some PUI dialogs to it, and see how easy / painful the process is. Hell create some QObjects which expose commands and the property tree and Nasal.

This has the advantage of not touching the OSG window at all, QtQuick simply provides some additional OpenGL rendering on top, which we pass events to - pretty much exactly the same as what we already do for PUI, and hopefully can co-exist with it. James got this working in a local OSG tree in a standalone demo, but that’s based on osgQt - he wants to see if he can make it work on a normal, non-Qt OSG window inside FlightGear.<ref>https://sourceforge.net/p/flightgear/mailman/message/35156051/</ref>

The idea is to host an XML dialog (Currently done with PUI) from Qt also. The question is if that can be done keeping ‘source compatibility’ exactly with the current UI XML and Nasal interface. It probably can be, but many of the PUI widgets have really ugly APIs, especially for combo-boxes, drop-down menus and scrolling lists, where it makes sense to map a Nasal class to a Qt ItemModel, which would be more elegant and easy to work with in both Nasal and integrate on the Qt side. But obviously would mean changing the dialog sources.

Of course, aircraft dialogs tend to be simpler, and not use the more complex PUI widgets, precisely for reasons like this, but that’s a limitation it would be best to remove.<ref>https://sourceforge.net/p/flightgear/mailman/message/35155721/</ref>


== References ==
{{Appendix}}

[[Category:PUI| ]]
[[Category:Rendering roadblocks]]

File:Environment-dlg-via-canvas-bridge-04-2023.png

2023-04-22T08:16:18Z

Hooray: Uploaded own work with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=Screen shot showing the XMLDialog.nas in use to parse/render the environment.xml PUI/XML dialog (unmodified)}}
|date=2023-04-21
|source={{own}}
|author=[[User:Hooray|Hooray]]
|permission=
|other versions=
}}

=={{int:license-header}}==
{{self|cc-by-sa-4.0}}

[[Category:Canvas GUI]]

Howto:Processing legacy PUI dialogs using Canvas

2023-04-21T10:45:54Z

Hooray: https://forum.flightgear.org/viewtopic.php?f=71&t=25087&hilit=LOC+PUI&start=30#p260327

{{Note|This discusses an outdated, but functional, prototype of a pui2canvas Nasal module originally drafted back in 2015<ref>https://forum.flightgear.org/viewtopic.php?f=71&t=25087&&start=30#p260327</ref> <ref>https://forum.flightgear.org/viewtopic.php?f=71&t=25087&&start=30#p260484</ref> <ref>https://forum.flightgear.org/viewtopic.php?f=71&t=29789</ref>, in response to talks on the devel list at the time, discussing various pros&cons of different approaches. In the meantime, since mid 2022, there's now an actual pui2canvas module being implemented by core developers, available in $FG_ROOT/Nasal/gui/XMLDialog.nas - therefore, this article is primarily useful for future reference, or to look up some of the original ideas/approaches. For recent developments, please refer to [[PUI#2022]].}}


[[File:About-dialog-rendered-by-canvas.png|thumb|Screen shot showing the FlightGear about dialog procedurally created and rendered by a Nasal/Canvas parser that turns [[PUI]]/XML markup into Canvas widgets/properties. The about dialog is making heavy use of dynamic text labels using printf formatting for displaying OpenGL related info, so needs to be mapped to Nasal sprintf/getprop calls]]
{{Canvas Navigation}}
{{FGCquote|1= Qt widgets can be drawn into OpenGL buffers. That doesn't change the fact that it would be a great deal of work to port our GUI to Qt, and it would introduce a very large external dependency. Having seen the fit pitched when I started using boost... Now, big projects can get done, and motivated individuals with time on their hands can work wonders. We should keep in mind the relative importance of the GUI system to the whole flying experience and judge whether it would be worth the effort to do a huge rewrite in this area.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/24467194/ | title = <nowiki>Re: [Flightgear-devel] GUI dialogs suck</nowiki> | author = <nowiki>Tim Moore</nowiki> | date = Jan 30th, 2010 }}}}

As of 05/2017, James is still very much undecided about which technology to use for in-sim GUI, he is somewhat inclined towards using the Canvas, because it avoids some rendering issues (but exposes a few more, + some performance ones) but the problem is James is fairly unhappy with the GUI / widget API in the Canvas right now - it does not satisfy his ideas about how simple + robust such an API should be, James needs to evaluate if the current API can be improved or needs to be drastically changed. The other issue is to use QtQuick rendered into OpenGL, which has a very nice robust and well-designed API, but adds some dependencies and complicates the rendering architecture, which makes him nervous about multi-window setups and other more esoteric OSG configs.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35863607/
|title = <nowiki> Re: [Flightgear-devel] KBOS runway list? are there 10 or are there
12? </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = May 28th, 2017
|added = May 28th, 2017
|script_version = 0.40
}}</ref>

FlightGear's rudimentary gui ([[PUI]]) is written all in opengl so it works fine in full screen and doesn't need tricky interactions with the underlying OS (the details of which often vary wildly from one OS or window system to the next.) Qt has taken great strides in lowering this barrier and James is a Qt expert, but it's still a massive amount of work with a lot of build/dependency implications to convert a whole gui system (and test all the edge cases.)<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=296166#p296166
|title = <nowiki> Re: Nasal must go </nowiki>
|author = <nowiki> curt </nowiki>
|date = Oct 6th, 2016
|added = Oct 6th, 2016
|script_version = 0.40
}}</ref>

Improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, many people are convinced PUI needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

While most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so [using Qt5] would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Obviously, it’s most important that people feel able to use and contribute to the project, far more so that whether a particular feature gets implemented or not.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

If you plan a solution to a problem, but it might get ready in two years (or not), we still may want/need something now. So could create some quick hack filling the gap with the expectation that the hack gets replaced once a proper solution is there <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35631515/
|title = <nowiki> Re: [Flightgear-devel] Fwd: Canvas-svg parsing breakage </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 28th, 2017
|added = Jan 28th, 2017
|script_version = 0.40
}}</ref>

pui2canvas.nas is a viable replacement - once finished, it will render every existing dialog, not pretty but working - 95% of the pain for maintainers is gone because no immediate action is required, everything still works, PUI can go<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

The point is that the parser can parse/translate a subset of PUI xml and make a viable dialog composed of canvas elements out of it. Any graphics artist can now make better elements, changing colors and fonts is down to a .setColor() or .setFont(), so the whole thing is as configurable as any canvas element.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=300640#p300640
|title = <nowiki> Re: More realistic Blackout/Redout </nowiki>
|author = <nowiki> Thorsten </nowiki>
|date = Dec 5th, 2016
|added = Dec 5th, 2016
|script_version = 0.40
}}</ref>

James would be delighted if someone is serious about working on the Canvas-based UI, replacing PUI and so on. If there’s people really interested in that, he would much rather help them out, than duplicate their efforts in his limited spare time. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35150746/
|title = <nowiki> Re: [Flightgear-devel] Aircraft center </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jun 10th, 2016
|added = Jun 10th, 2016
|script_version = 0.40
}}</ref>

In 01/2018, James said that he would not be especially invested in a QQ2 UI - it’s his ‘day job’ work - but obviously he also knows the technology. What he doesn't want to feel, is that he is forcing his approach on the community if people think a Canvas-based solution (or a Phi-based one or anything else) would be easier and also deliver a long-term basis for our UI. And he would be much happier if the Ui was a collaborative effort, since there are other areas he would much sooner focus on than 'more of his day job' <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36195299/
|title = <nowiki> Re: [Flightgear-devel] QtQuick UI - current status + plans </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 18th, 2018
|added = Jan 18th, 2018
|script_version = 0.36
}}</ref>

Furthermore stating, that his basic feeling is to step back and say, let’s see if a pure Canvas UI will work<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36197666/
|title = <nowiki> Re: [Flightgear-devel] QtQuick UI - current status + plans </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 20th, 2018
|added = Jan 20th, 2018
|script_version = 0.36
}}</ref>

James also said that his impression was that if someone makes a Canvas UI option, the Qt based solution will be still-born almost by default - because he won’t be able to create any enthusiasm or interest around it. But for sure Canvas based approaches attract a lot more support and man-power very easily (than a Qt5/QQ2 option). And his guess each person who works on the Canvas based Ui is one fewer who might ever help out with the Qt based one. (That is not probably 100% true, but there is some correlation) <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36199572/
|title = <nowiki> Re: [Flightgear-devel] QtQuick UI - current status + plans </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 22nd, 2018
|added = Jan 22nd, 2018
|script_version = 0.36
}}</ref>

The basic thinking being let’s say the Qt UI is 1/4 of James' time per week spent on FG (might be a little more, but he's got lots of other things to work on), vs Thorsten’s time and 4 or 8 enthusiastic people he can recruit - Qt5/QQ2 is obviously going to fall massively behind in comparison - within three or six months they might build a complete replacement UI. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36199712/
|title = <nowiki> Re: [Flightgear-devel] QtQuick UI - current status + plans </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 22nd, 2018
|added = Jan 22nd, 2018
|script_version = 0.36
}}</ref>

It is also worth noting that we don't really need a 1:1 mapping between PUI and Canvas, because we can usually emulate/approximate most PUI widgets rather easily using similar workarounds - as a matter of fact, the whole PUI widget set is rather archaic, and we really only need 2-3 additional Canvas widgets to approximate the full set of supported widgets without much of an effort.
For instance, there are a number of hard-coded widgets, such as the airport-list, waypoint-list or the property-browser - under the hood however, all of these end up just being combo/select boxes with items that respond to clicks<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=302709#p302709
|title = <nowiki> Re: GUI Combo: How to control so it drops down not up </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Jan 4th, 2017
|added = Jan 4th, 2017
|script_version = 0.40
}}</ref>

== Addon ==
[[File:Runtime-gui-selection.png|thumb|Screenshot showing a FlightGear GUI dialog that allows switching between different built-in GUI engines (PUI, Qt5 and Canvas for now).]]

[[File:Pui2canvas-preview-select.png|thumb|Conventional PUI dialog for selecting dialogs to be processed by the pui2canvas parser]]

[[File:Pui2canvas-preview.png|thumb|FlightGear PUI/XML dialog showing an embedded CanvasWidget for previewing PUI/XML dialogs parsed by the [[Pui2canvas]] parser - this is mainly intended for testing/development purposes.]]

[[File:Map-canvas-via-pui2canvas.png|thumb|Screenshot showing a [[Canvas]] GUI dialog created by the [[Pui2canvas]] parser mapping a subset of PropertyList [[PUI]]/XML markup to Canvas widgets, showing a MapStructure map]]

{{Main article|Addon}}

This section documents the necessary changes to turn the pui2canvas module into an addon using Torsten's addon framework.

Specifically, this involves the following changes:
* creating a pui2canvas addon
* providing a property for enabling/disabling this via <code>--prop:</code>
* registering a listener to easily enable/disable the module at runtime
* adding a blacklist/whitelist of supported/working dialogs/widgets (think exit.xml, about.xml for starters)
* provide an in-sim UI to easily enable/disable pui2canvas for certain dialogs using checkboxes with the userarchive attribute set
* provide a menubar parser [[Howto:Making a Canvas Menubar]]
* provide an option to re-instate the Canvas aircraft center [https://forum.flightgear.org/viewtopic.php?f=71&t=33023&p=319732#p319732]

=== Whitelist ===
List of dialogs that are simple enough to be displayed "as is" using the pui2canvas parser:
* {{Dialog file|dialog=about}}
* {{Dialog file|dialog=exit}}
* {{Dialog file|dialog=scenario}}
* {{Dialog file|dialog=view}}
* {{Dialog file|dialog=logging}}

== Objective ==
{{See also|Pui2Canvas Maintenance Guide}}
This article is intended to demonstrate how '''existing [[PUI]] dialogs can be easily processed using FlightGear scripting (via [[Nasal]]) and the [[Canvas]] 2D rendering API''', and be turned into [[Canvas]] widgets and dialogs.

This will enable the removal of [[PUI]]-related OpenGL code, which is known for using inefficient legacy OpenGL code that is not suitable to be used in conjunction with OSG, and also let existing dialogs be supported without having to manually update/port, or separately maintain, them.

In its current form, this is not intended to be a completely functional alternative to [[PUI]], but just intended to document the necessary steps for supporting the existing PUI dialogs (and widgets), without having to adopt an external UI library like Qt5.

Simple dialogs are likely to work, while more sophisticated dialogs may require some additional work, especially when it comes to layouting and styling (including PUI themes).

This extra work would typically involve extending or creating custom Canvas widgets for wrapping PUI widgets, and integrating those with the parser shown below.

The main motivation here is to ensure that there are no regressions introduced and to ensure that existing dialogs continue to work, no matter if they live inside $FG_ROOT or not, but also because it is generally not a good idea to rewrite working systems from scratch<ref>http://www.joelonsoftware.com/articles/fog0000000069.html</ref><ref>http://vibratingmelon.com/2011/06/10/why-you-should-almost-never-rewrite-code-a-graphical-guide/</ref><ref>http://onstartups.com/tabid/3339/bid/2596/Why-You-Should-Almost-Never-Rewrite-Your-Software.aspx</ref>.

<references/>

== Gallery & Status ==
we have a demo up and running which can be refined and extended within days/weeks. Presumably, if we really wanted and would focus efforts, [[PUI]] could go by the next release and we'd have a rough replacement.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35157133/
|title = <nowiki> Re: [Flightgear-devel] GUI options (Was: Aircraft center) </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jun 14th, 2016
|added = Jun 14th, 2016
|script_version = 0.40
}}</ref>

Given this, probably nobody objects against removing PUI and replace it by CUI, keeping the old syntax. At least for a while. Dropping PUI would be a huge step forward.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35157325/
|title = <nowiki> Re: [Flightgear-devel] GUI options (Was: Aircraft center) </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jun 14th, 2016
|added = Jun 14th, 2016
|script_version = 0.40
}}</ref>

As of mid 2016, it is pretty safe to say that it's less than a handful of widgets that are now missing to be able to approximate most PUI widgets/dialogs - it goes without saying that this won't look as good as a Qt5 UI, but it also won't have the costs (amount of work) associated with it - i.e. you could say, the pui2canvas approach is merely a simple fasttrack concept to get rid of PUI completely, without having to manually port any of the existing resources necessarily.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=289322#p289322
|title = <nowiki> Re: Aircraft Center | pui2canvas parser (devel-list follow-u </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Jun 21st, 2016
|added = Jun 21st, 2016
|script_version = 0.40
}}</ref>

if the xml format changes (which is reasonable if you want to make use of Qt capabilities), it should be documented. Based on this documentation, the maintainer(s) of the parser make the required changes. It's not rocket science because it's a minimal solution based on fairly simple Nasal code (~500 LOC). Since Qt is envisioned to be the default solution and Canvas a minimal fallback, that is the proper way to do it.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35157133/
|title = <nowiki> Re: [Flightgear-devel] GUI options (Was: Aircraft center) </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jun 14th, 2016
|added = Jun 14th, 2016
|script_version = 0.40
}}</ref>

As far as aircraft dialogs are concerned [...] the parser has to be backward-compatible no matter what unless someone actually wants to go manually through old aircraft and fix. Also - what's the idea with Phi for aircraft access? A separate set of special dialogs aircraft-side? It's basically the same challenge.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35157133/
|title = <nowiki> Re: [Flightgear-devel] GUI options (Was: Aircraft center) </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jun 14th, 2016
|added = Jun 14th, 2016
|script_version = 0.40
}}</ref>

As of 06/2016, the built-in [[Aircraft Center|Canvas-based Aircraft Center]] has been entirely removed from the FlightGear GUI, and replaced with the Qt5-based GUI, the commit message saying<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=288198#p288198
|title = <nowiki> Re: How do I enable aircraft center? </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Jun 9th, 2016
|added = Jun 9th, 2016
|script_version = 0.40
}}</ref>

https://sourceforge.net/p/flightgear/fgdata/ci/654a343bbb7eb51b387060515e3415e152d12c2a/
<pre>Needs a lot of testing, but aircraft can be installed / changed and
location adjusted from within the sim. After some number of times the
sim will crash.
</pre>

Note that this means that Aircraft Center functionality will no longer be available to people if they don't also happen to use Qt5 and/or Phi (not sure if package manager functionality is provided there?).

{{Note|when adding new/updated screenshots, please be sure to show the corresponding PUI dialog side-by-side for comparison.}}

<gallery widths=400>
Scenarios-via-pui2canvas.xml.png|AI {{GUI dialog|dialog=scenario}} dialog parsed/processed by pui2canvas converter
View-dialog-generated-by-canvas.png|Screen shot showing the procedurally generated Canvas dialog, based on parsing a PUI subset of {{GUI dialog|dialog=view}}
Jetways-pui2canvas.png|{{GUI dialog|dialog=jetways}} dialog parsed/processed by the pui2canvas parser (no layouting applied)
Nasal-console-via-canvas.png|Screenshot showing the [[Nasal Console]] GUI dialog processed by the pui2canvas parser (with functional bindings)
Time-dialog-via-pui2canvas.png|approximation of the FlightGear [[Time in FlightGear|Time]] dialog via [[Howto:Processing legacy PUI dialogs using Canvas|pui2canvas]] parser
Gps-dialog-via-pui2canvas.png|gps dialog via pui2canvas
Earthview-dialog-via-pui2canvas.png|[[Earthview]] PUI/XML dialog rendered via the [[Howto:Processing legacy PUI dialogs using Canvas|pui2canvas parser]] (with table support)
Instruments-xml-via-pui2canvas.png|instruments.xml vila pui2canvas
Radios-via-pui2canvas.png|radios.xml via pui2canvas
Logging-dialog-via-pui2canvas.png|logging.xml PUI/XML GUI dialog parsed via pui2canvas
Weather-dialog-via-pui2canvas.png|weather dialog via pui2canvas
Shuttle-dps-dialog-via-pui2canvas.png|aircraft-specific GUI dialog (shuttle) rendered by the pui2canvas parser
Wildfire-dialog-via-pui2canvas.png|Procedurally created [[Wildfire simulation|wildfire]] UI dialog that is rendered using the [[Howto:Processing legacy PUI dialogs using Canvas|pui2canvas parser]]
View-dialog-comparison-pui2canvas.png|side-by-side comparison pui vs. pui2canvas for view.xml dialog <ref>https://forum.flightgear.org/viewtopic.php?f=71&p=289322#p289321</ref>
Pui2canvas dialog served via httpd.png|FlightGear [[PUI]] XML dialog rendered via [[Pui2canvas]] and [[Read canvas image by HTTP|served via httpd]] to a running firefox instance.
Pui2canvas-rendering-dialog.png|Screenshot showing the Canvas pui2Canvas parser parsing rendering.xml
Pui2canvas-button-preview.png|Button configuration dialog processed by pui2canvas
</gallery>
As of 10/2015, a simple framework is being prototyped to serve as a proof-of-concept and demonstrate how existing PUI dialogs can be processed by a parser written in Nasal, which turns PUI/XML markups into the corresponding Canvas widgets/properties.

At the time of writing, it isn't clear if this approach is going to be actually used anywhere-but that doesn't really matter, because the parser is fairly straightforward and simple, which makes it an excellent stress test to exercise the underlying Canvas/C++ code.

So running the parser and benchmarking/[[Built-in Profiler|profiling]] FlightGear is a pretty good way to determine bottlenecks and come up with ideas for extending/optimizing the Canvas C++ code a little, which will be beneficial to unrelated efforts (including any aircraft/dialogs using Canvas/[[MapStructure]] based displays), but also the long-term idea to help unify the 2D rendering back-end by porting the HUD/2D panels code to use Canvas.

Creating a Canvas property tree hierarchy for even simple PUI/XML dialogs will easily cause the creation of dozens of layout instances and hundreds of Canvas groups in the tree, many of which may have attached listeners/timers for event handling purposes. The Nasal/Property Tree overhead is fairly remarkable, and also noticeable on older systems.

For the time being, the parser correctly supports:
* embedded nasal/close blocks (code executed prior to dialog creation, and cleanup code executed when closing the dialog)
* bindings in the form of fgcommands and Nasal scripts
* C-format style labels/legends
* dynamically patched fgcommands to transparently dispatch PUI fgcomands to their Canvas equivalents (e.g. dialog-close)

Upcoming features will include:
* support for table layouts (heavily used by most PUI/XML dialogs)
* PUI widget visibility controlled via props.nas (conditions)
* integration with the <code>canvas</code> tag to fully support recursion

== Widget Matrix ==
{{Main article|Canvas Widget Matrix}}

== Before this gets committed ... ==
For this to be committed, even just as an option, a few things should happen first of all:

* the whole thing should be turned into an optional Nasal submodule
* loading it should be configurable via preferences.xml
* it would make sense to introduce a $FG_ROOT/pui2canvas.xml file included via preferences.xml, which contains script specific settings
* such settings could be a list of dialogs/widgets known to work well enough already (think about.xml, view.xml, scenarios.xml etc)
* menubar.xml could be edited to replace <code>dialog-show</code> entries with a <code>gui.dialog-show</code> entry
* this could transparently let the user decide whether he wants to use PUI, Qt5 or the pui2canvas parser (think [[Aircraft Center]])
* provide an in-sim option to easily toggle between all options, set the userarchive attribute
* provide an option to unload/reload the module at runtime (for people wanting to help troubleshoot/develop this without having to exit/restart)
* testing should take place with a focus on complex dialogs (joysticks, tutorials, checklists), and functionality of the parser should probably be reviewed by Stuart (who created all those dialogs)

== Why Nasal and Canvas ? ==
Let's uppose we get super-fancy weather dialog. But the current weather dialog also works - because at the end of the day, what the dialogs do is set properties, execute FGCommands or start Nasal scripts. The fact that you have created a super-fancy dialog to do these tasks doesn't mean the simple one stops working. While the visuals of the dialogs can be really complicated, how the dialog communicates with FG is very well defined.
It's like saying Phi will stop working because there's Qt - it won't, because internally it also sets properties, executes FGCommands or scripts. New widgets don't equal new ways to interact with FG for your module - how you interact with FG is determined by what the subsystems understand, not what your dialog does.
The same way as a launcher is just a fancy way of assembling a commandline, and... you can just skip it and type the commandline.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=288966#p288966
|title = <nowiki> Re: Aircraft Center | pui2canvas parser (devel-list follow-u </nowiki>
|author = <nowiki> Thorsten </nowiki>
|date = Jun 17th, 2016
|added = Jun 17th, 2016
|script_version = 0.40
}}</ref>

there are different components available in FlightGear - as in an existing "Canvas GUI" SGSubsystem that runs inside the main loop, which all Canvas code can leverage - aside from that, there are widgets, and a framework to easily create new widgets - including a SVG parser that can reuse JavaScript/HTML based widgets.

Apart from that, there is the pui2canvas parser that maps a subset of the legacy PUI markup to this existing infrastructure.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=289032#p289032
|title = <nowiki> Re: Aircraft Center | pui2canvas parser (devel-list follow-u </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Jun 18th, 2016
|added = Jun 18th, 2016
|script_version = 0.40
}}</ref>

Any UI talks to FG in terms of setting properties, calling FGcommands and Nasal scripts. Pretty much anyone who has done a glass cockpit for FG has solved the task.
In fact, the Shuttle UI with the combination of MEDS/DPS pages, the keypad entry, the various keyboard to IDP to screen mappings and the major function/major mode constraints is ''much'' more complicated than FGs PUI. It'd be trivial (and amusing) to let some fictional Shuttle DPS pages control FG settings - it'd be straighforward to do because the DPS does what any GUI does - it communicates with FG via properties, FGCommands and scripts.
So what some may call a 'mammoth' task (providing a graphical representation for communication with the rest of FG) is in fact exactly what canvas is for and what it does in every aircraft that uses a more advanced glass cockpit. Without any major problems really... Really all that is needed is the xml parser and the widgets - the rest is all there and has been used for years.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=289037#p289037
|title = <nowiki> Re: Aircraft Center | pui2canvas parser (devel-list follow-u </nowiki>
|author = <nowiki> Thorsten </nowiki>
|date = Jun 18th, 2016
|added = Jun 18th, 2016
|script_version = 0.40
}}</ref>

that also means that the pool of experienced Nasal/Canvas contributors (i.e. those who have done some Nasal/Canvas hacking for their aircraft), and thus potential UI contributors is much larger in the FlightGear community compared to, say, people familiar with the FlightGear/SimGear code base, and Qt5 development in particular.
Like Thorsten said, the bottleneck is creating a parser that supports a sufficiently complete subset of PUI/XML as it is used in FlightGear, and coming up with the corresponding widgets provided/used by FlightGear's PUI/XML interface.

<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=289091#p289091
|title = <nowiki> Re: Aircraft Center | pui2canvas parser (devel-list follow-u </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Jun 19th, 2016
|added = Jun 19th, 2016
|script_version = 0.40
}}</ref>

Bottom line, the Canvas UI SGSubsystem is there, it's existing C++ code, that has been integrated years ago - it's used every day - whenever you're seeing a tooltip, a Canvas GUI dialog or a CanvasWidget, it's all there and just works.
If people find it challenging to render a webkit or Qt5 widget into FlightGear, they'd be well-advised to simply come up with a custom Canvas::Element child class - which I also understand how to do, and James has previously done that, too (he implemented/prototyped Canvas::Image for handling raster images), so he understaands perfectly how to extend the Canvas system to support other "elements".
This path is unrelated to PUI or pui2canvas - it's just a way of rendering into the FligthGear window, without having to do much homework - it'll just work, which includes event handling etc - Tom implemented that almost half a decade ago, indeed at the encouragement of James and others back then ...<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=289032#p289032
|title = <nowiki> Re: Aircraft Center | pui2canvas parser (devel-list follow-u </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Jun 18th, 2016
|added = Jun 18th, 2016
|script_version = 0.40
}}</ref>

replacing the PUI menubar with a Canvas-based one is trivial - the code on the wiki actually worked, i.e. is parsing menubar.xml and creates buttons that create popups with the corresponding entries.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=289032#p289032
|title = <nowiki> Re: Aircraft Center | pui2canvas parser (devel-list follow-u </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Jun 18th, 2016
|added = Jun 18th, 2016
|script_version = 0.40
}}</ref>

you don't even need to "entirely strip out PUI from any source code" to see that this works, because you can use the corresponding fgcommands to remove the entire PUI subsystem at runtime - e.g. using what you referred to as "segfault heaven":
[[Howto:Reset/re-init Troubleshooting]]

[[File:Reset-reinit-control-panel.png|250px]]<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=289033#p289033
|title = <nowiki> Re: Aircraft Center | pui2canvas parser (devel-list follow-u </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Jun 18th, 2016
|added = Jun 18th, 2016
|script_version = 0.40
}}</ref>

In other words, pui2canvas can be solely implemented in fgdata space, and it can even remove PUI at runtime ...<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=289033#p289033
|title = <nowiki> Re: Aircraft Center | pui2canvas parser (devel-list follow-u </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Jun 18th, 2016
|added = Jun 18th, 2016
|script_version = 0.40
}}</ref>

== FAQs ==
The new Qt5 functionality is seeing improvements in areas for which there is no mapping outside Qt5, namely no PUI/Canvas or Phi bindings to bring features like the package manager up to par with the Qt5 code.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=282077#p282077
|title = <nowiki>Re: OSGearth as default scenery?</nowiki>
|author = <nowiki>Hooray</nowiki>
|date = Apr 10th, 2016
|added = May 7th, 2016
|script_version = 0.35
}}
</ref>

It seems increasingly likely that the Qt5 launcher will continue to developed, and it may even make built-in features obsolete, so it is a good idea to be proactive whenever you notice anything missing/broken or incomplete, because all the ongoing Qt5 work is likely to be the foundation for what FG is going to look like a few years from now - to see that that's the case, you only need to look at new developments that are solely integrated with the Qt5 front-end - thus, sooner or later, certain desirable functionality will be tied to Qt5, and you should not expect fgrun to support all features that the Qt5 launcher does/will support.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=276623#p276623
|title = <nowiki>Re: FG 2016,1.1</nowiki>
|author = <nowiki>Hooray</nowiki>
|date = Feb 19th, 2016
|added = May 7th, 2016
|script_version = 0.35
}}
</ref>

As of mid 2016, it is becoming clear that the Qt5 launcher and the way it is integrated, is having ramifications for features that are otherwise unrelated to the launcher, and Qt5 as a whole.
For example, the reason end-users have an empty aircraft list in the [[Aircraft Center]] seems to be tied to the fact they do not use the Qt Launcher.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=284606#p284606
|title = <nowiki>Re: Tutorial: How to get Aircraft Center to work</nowiki>
|author = <nowiki>jaxsin</nowiki>
|date = May 7th, 2016
|added = May 7th, 2016
|script_version = 0.35
}}
</ref>

People have to get the built-in launcher to setup the catalog. The canvas Aircraft center works fine, it just depend on the catalog being setup first, which is done by the build-in launcher.

<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=284608#p284608
|title = <nowiki>Re: Tutorial: How to get Aircraft Center to work</nowiki>
|author = <nowiki>Necolatis</nowiki>
|date = May 7th, 2016
|added = May 7th, 2016
|script_version = 0.35
}}
</ref>

The package manager is the back-end built into fgfs - but it's connecting to a website (see the xml file I mentioned above) hosted byakalawe - and previously, that xml file (and related data) hasn't been updated in a while<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=276478#p276478
|title = <nowiki>Re: Aircraft Center</nowiki>
|author = <nowiki>Hooray</nowiki>
|date = Feb 17th, 2016
|added = May 7th, 2016
|script_version = 0.35
}}
</ref>

This is pretty unfortunate, because one of the main reasons for encouraging the Qt5-based development of a launcher was indeed that it would remain 100% optional, and that it would NOT have ramifications for unrelated features, i.e. those '''not''' requiring/using Qt5 - accordingly, we might as well dispense with the fiction that this is not a dependency.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34537005/
|title = <nowiki>Re: [Flightgear-devel] GUI questions (again)</nowiki>
|author = <nowiki>Thorsten Renk</nowiki>
|date = Oct 13th, 2015
|added = May 7th, 2016
|script_version = 0.35
}}
</ref>

Qt5 is not intended to be required for building FG, even though useful functionality is going to be increasingly tied to it (think launcher, in-sim UI, package manager, AircraftCenter UI).<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=260557#p260557
|title = <nowiki>Re: New Canvas GUI</nowiki>
|author = <nowiki>Hooray</nowiki>
|date = Oct 14th, 2015
|added = May 7th, 2016
|script_version = 0.35
}}
</ref>

=== Yet another GUI effort ? ===
Nope, this is not a separate GUI, it is primarily a module to translate existing GUI files to use the integrated Canvas 2D drawing system. Also, to be absolutely fair, the whole Canvas UI debate took place several years prior to the development of a Phi/Qt5 based UI, and it was in fact inspired and encouraged by a number of core developers back then (as you can see below).

=== What about PUI ? ===
{{FGCquote
|1= Another option is to move /all/ the remaining pieces of PLIB we use (actually just FNT, PUI and JS) into 3rdparty, and drop our dependency on external PLIB.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34921429/
| title = <nowiki>[Flightgear-devel] Joystick support code location</nowiki>
| author = <nowiki>James Turner</nowiki>
| date = Mar 9th, 2016
| added = Mar 9th, 2016
| script_version = 0.25
}}
}}

{{FGCquote
|1= Rolling the portions of plib that we still use into our own code base is a topic worth discussing. With a small bit of thought, I don't see a downside. Plib development/support ended long ago.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34921495/
| title = <nowiki>Re: [Flightgear-devel] Joystick support code location</nowiki>
| author = <nowiki>Curtis Olson</nowiki>
| date = Mar 9th, 2016
| added = Mar 9th, 2016
| script_version = 0.25
}}
}}

{{FGCquote
|1= PUI is scheduled to disappear anyway, I don't think anyone will invest much time trying to fix it.
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=268828#p268828
| title = <nowiki>Re: AMD Radeon R9 – Massive text flickering again</nowiki>
| author = <nowiki>Thorsten</nowiki>
| date = Dec 16th, 2015
| added = Dec 16th, 2015
| script_version = 0.25
}}
}}

{{FGCquote
|1= At least for the time being, PUI doesn't seem to become obsolete anytime soon, according to James Turner's continuing preference to hack/extend and maaintain custom PUI widgets:
http://sourceforge.net/p/flightgear/mailman/message/34747786/
This observation is also in line with numerous PUI related commits that he made despite his ongoing Qt5 work: http://wiki.flightgear.org/Canvas_GUI#PUI_Widgets
For a more recent example, look at the waypointlist commits that are using neither Qt5, Phi or Canvas at all: http://sourceforge.net/p/flightgear/flightgear/ci/846fd2
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=272148#p272148
| title = <nowiki>Re: Can't install FGRun package (+ rant about Qt5 launcher)</nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Jan 9th, 2016
| added = Jan 9th, 2016
| script_version = 0.23
}}
}}

{{FGCquote
|1= I am strongly against using a very non-standard UI (a text box + slider) to achieve that interaction. I’d much rather we add a spin-box to PUI, which is not especially hard, and give it the ‘click and drag’ mouse interaction which some spinboxes in other apps have, to give similar UI to the sliders without the visual clutter.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34747786/
| title = <nowiki>Re: [Flightgear-devel] Speed-up vs time-warp</nowiki>
| author = <nowiki>James Turner</nowiki>
| date = Jan 7th, 2016
| added = Jan 7th, 2016
| script_version = 0.23
}}
}}

{{FGCquote
|1= I frantically code up a tweaked PUI text-input/spin-box with press-and-drag to adjust, effectively a slider’s mouse interaction
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34762785/
| title = <nowiki>Re: [Flightgear-devel] Speed-up vs time-warp</nowiki>
| author = <nowiki>James Turner</nowiki>
| date = Jan 13th, 2016
| added = Jan 13th, 2016
| script_version = 0.23
}}
}}

<references/>

=== What is it really ? ===
It is a parser/convertor (written in Nasal) to deal with existing PUI/XML files, which are dynamically translated to Canvas widgets, so that a corresponding dialog can be shown.

{{FGCquote
|1= the idea of replacing the PUI GUI with a Canvas-based GUI.
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=264825#p264825
| title = <nowiki>Re: version checking for matching fgfs and -set.xml files</nowiki>
| author = <nowiki>bugman</nowiki>
| date = Nov 17th, 2015
| added = Nov 17th, 2015
| script_version = 0.25
}}
}}

{{FGCquote
|1= The only real advantage that the Nasal/Canvas approach brings with it is that it is a completely different approach to update the integrated UI: It just involves writing a "converter" (translator) to read existing GUI dialog files and turn those into Canvas graphics (textures) at runtime (procedurally).
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=272314#p272314
| title = <nowiki>Re: Aircraft reselection </nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Jan 10th, 2016
}}
}}
{{FGCquote
|1= Which means that there will only ever need to be a parser written/maintained to deal with our existing set of GUI dialogs, i.e. we don't need to integrate an external GUI library (think Qt5), and certain challenges simply would not show up at all (think the multi-threading issues that bugman mentioned), simply because Canvas is already a technology stack and subsystem that is available in FlightGear, so all that the parser is doing is to read XML dialogs and turn them into their Canvas equivalent.
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=272314#p272314
| title = <nowiki>Re: Aircraft reselection </nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Jan 10th, 2016
}}
}}

=== How is this any different from Qt5/Phi? ===
So far, the discussions revolving around Qt5/Phi were mainly about coming up with a new GUI from scratch, which would be a lot of work, and probably introduce a bunch of regressions along the way. Parsing a sufficiently large subset of PUI using Nasal/Canvas however is not so much work in comparison.

{{FGCquote
|1= It's most likely a problem with the PUI (the current GUI), and the plan is to discontinue using it. There are experimental canvas GUIs which don't show the flickering (look around in the forum for some pointers), there's Phi as external GUI option and James' plan is to create a new GUI using Qt5.
So it's not really that no one cares, GUI is about the most active part of core development at the moment.
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=268743#p268743
| title = <nowiki>Re: AMD Radeon R9 – Massive text flickering again</nowiki>
| author = <nowiki>Thorsten</nowiki>
| date = Dec 16th, 2015
| added = Dec 16th, 2015
| script_version = 0.25
}}
}}

{{FGCquote
|1= Qt5 is always going to be superior, but is going to cause tons of work, too - Phi will be able to satisfy use-cases that Qt5 cannot support (external/browser-based UI), Canvas can really only help with the integrated UI - but at the cost of creating widgets from scratch, i.e. equivalents of existing PUI widgets (including those that were custom coded for FlightGear specifically).
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=272314#p272314
| title = <nowiki>Re: Aircraft reselection </nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Jan 10th, 2016
}}
}}

Also, there are some key features that simply rely on the way PUI/XML and Nasal work together, such as [[Aircraft Checklists]] and [[Tutorials]], as well as a plethora of aircraft-specific dialogs, many of which contain huge blobs with embedded Nasal code that needs to just work.

It is simply not feasible to support/rewrite all these dialogs from scratch, the only feasible approach is parsing PUI/XML and translating this at run-time (no matter if that is done via Canvas, Phi or Qt5).

{{FGCquote
|1= The same approach (writing just a parser instead of a new UI framework from scratch) would work for the Qt5/Phi efforts (including even support for embedded Nasal code in existing dialogs), but so far the people working on those have prioritied their resources differently, so that it is likely that sooner or later there will be a regression in terms of functionality, unless the parser/translator approach is also embraced by them.
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=272314#p272314
| title = <nowiki>Re: Aircraft reselection </nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Jan 10th, 2016
}}
}}

=== Does it work ? ===
Yes, in fact it does - even pretty well, despite the Canvas system not having been designed/developed with this particular use-case in mind.

=== Isn't this tons of work ? ===
Actually, the parser started out at 150 LOC, and is now ~300 LOC - in comparison to the dialogs that it can process, it is pretty straightforward-even trivial. Keep in mind that a typical PUI/XML dialog is several thousands lines in size, and often has tons of custom Nasal code in embedded sections.

In other words, literally "porting" an existing dialog manually to Phi/Qt5 (think airports.xml) is likely to be much more work than coming up with a parser, which can be refined over time to support other widgets/dialogs or layouting directives.

The parser in its current form was prototyped by single person over the course of just a few days of spare-time hacking, with most time spent creating/maintaining this wiki article. At no point in time did the FlightGear binary (fgfs) have to be rebuilt or any libraries changed/added.

Now, on contrast to this, look at the Qt5/Phi efforts: two of the most active FlightGear core developers (James and Torsten) are now both involved in developing, very much overlapping, but entirely optional components (separately) that will not even be executed normally, using two incompatible technology stacks.

So, the increasing interest in revamping the FlightGear UI is likely to drain resources from other core development efforts (just look at the track record, i.e. plethora of components, touched by both, James & Torsten prior to their interest in moderniing the UI).

With Canvas/Nasal, there is not much needed in terms of C++ level changes, it requires mainly Nasal code, i.e. roughly 300-500 lines of additional code could make PUI obsolete so that it can be phased out, without any core developers having to review C++ level changes.

=== What's wrong with Phi/Qt5 ? ===
Nothing. Both solutions just satisfy different use-cases, including use-cases that don't cover certain Canvas use-cases (e.g. rendering UI widgets to a MFD and vice versa), as well as supporting use-cases that Canvas cannot cover, i.e. providing a remote UI (Phi) or providing a rich UI experience without requiring OpenGL/FBO support, including tons of excellent tools and support/documentation (Qt5).

While a parser, similar to this one, could indeed be implemented for Phi/Qt5, the staggering amount of Nasal code is complicating matters for any external solution, and in the Qt5 case there still would be the issue of an "optional" dependency being required for an in-sim UI.
While Phi would, for the time being, not be able to satisfy the in-sim use case, unless people are serious about adding a Webkit dependency to FlightGear, so that Phi can also serve as the built-in UI.

{{FGCquote
|1= there is [[Phi|Phi]] if you can have a second window open or have a second screen - that works via html interface.
Or you can wait for Qt5 to come along, but that seems to have run into problems even with just the launcher, so it's hard to guess when it will be there.
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=268828#p268828
| title = <nowiki>Re: AMD Radeon R9 – Massive text flickering again</nowiki>
| author = <nowiki>Thorsten</nowiki>
| date = Dec 16th, 2015
| added = Dec 16th, 2015
| script_version = 0.25
}}
}}

{{FGCquote
|1= The main points being 1) PUI is unmaintained and OpenGL specific, i.e. fixed-function pipeline, does not work well with other OSG code running in SG/FG, 2) Qt5 is a separate extremely well-maintained GUI platform, not specific to any particular use-case.
1) PUI is archaic and is known to affect rendering performance, and causing graphics artifacts

2) Qt5 could solve all problems, but is a massive dependency that is intended to remain optional - however, useful functionality is increasingly added/implemented solely in Qt5 space (think catalog/package manager related functionality)

3) Phi does not introduce any bloat at all, and is comparatively lightweight, but requires a browser to control FlightGear, which makes it asynchronous, but also not that suitable for certain features that an integrated UI could provide
Finally, Canvas is a niche-technology only used/available in SimGear/FlightGear, not unlike Nasal scripting.

Thus, anything involving Canvas is a homegrown thing that is unlikely to be able to "compete" with external UI efforts, such as Qt5 or Phi (it using a bunch of different DHTML frameworks), and that even applies to some PUI functionality.
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=272314#p272314
| title = <nowiki>Re: Aircraft reselection </nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Jan 10th, 2016
}}
}}

=== What are the pros & cons ? ===
{{FGCquote
|1= With Canvas/Nasal, there is not much needed in terms of C++ level changes, it requires mainly Nasal code, i.e. roughly 300-500 lines of additional code could make PUI obsolete so that it can be phased out, without any core developers having to review C++ level changes.
Then again, it would be a niche solution - but it could be implemented using factories/delegates, so that adopting a native code UI library (qt5/wxwidgets etc) would be possible anyway.

|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=272314#p272314
| title = <nowiki>Re: Aircraft reselection </nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Jan 10th, 2016
}}
}}

The major drawback is obviously that it is using Nasal and Canvas, both could be said to be home-grown niche solutions only used/available in FlightGear.

So, this approach cannot realistically "compete" with HTML5/JavaScript (Phi) or Qt5.
In particular, this comes to bear when creating/extending widgets, because for JavaScript/Qt5 there are literally thousands of existing solutions widely available. With Canvas, we typically have to create widgets from scratch, and also continue developing/maintaining those.

The other major issue is performance obviously, i.e. the parser being implemented in Nasal and using Canvas, does have a certain overhead.

Equally, Qt5/Phi would work for most hardware, while any Canvas-based solution would inevitably require FBO (RTT) support, i.e. a Canvas UI will only ever work for OSG/OpenGL windows.

The main advantage really is that a simple fallback UI can be provided in Nasal space, so that the underlying UI files can be directly used "as is" -so that these can be incrementally optimized, i.e. to identify huge custom Nasal blobs and come up with leaner dialogs during the transition to a more powerful UI solution using Qt5.

However, a Nasal/Canvas based approach is likely to just work for most people that are able to run FG (that is, if their GPU provides FBO support).

Equally, people interested in modern avionics (MFDs on airliners, bizjets, spacecraft) will need a way to render UI widgets to a MFD, and would also greatly benefit from being able to treat their MFDs as UI widgets, e.g. to show avionics in GUI dialogs - possibly as part of a tutorial, or post-flight evaluation. Such use-cases are only supported by true recursion, i.e. a widget being a Canvas and a Canvas being a widget.

{{FGCquote
|1= If you care about simulating modern avionics in FlightGear (think MFDs with ARINC 661-level features), e.g. modern airliners (737, 747, 767, 777, 787, any Airbus), bijets or even spacecraft, you likely want to ensure that a Canvas-based feature can be treated as a "widget" by the integrated UI - so that a MFD can be shown in a dialog. Equally, you will want to be able to render GUI widgets to a Canvas, without duplicating code unnecessarily.
As long as these two use-cases are supported, we can trivially implement built-in editors for things like 2D panels, HUDs or MFDs (imagine having a PFD/ND editor which includes styling).

|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=272314#p272314
| title = <nowiki>Re: Aircraft reselection </nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Jan 10th, 2016
}}
}}

{{FGCquote
|1= At the end of the day, it is your call, i.e. depending on whether you care about the use-cases discussed above, or if you'd like to see increasingly diverging/incompatible features being implemented, which may not seem like much of a showstopper currently, but which is going to cause a lot of whining once aircraft developers begin to notice that a non-Qt5 build will not support certain Canvas MFDs.
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=272314#p272314
| title = <nowiki>Re: Aircraft reselection </nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Jan 10th, 2016
}}
}}

=== Nasal overhead ===
it is true that there are PUI widgets that are not currently available via Canvas and which would need to be implemented, which would usually mean additional Nasal overhead (mainly timers and listeners).

However, that is not inevatibly the case - before the Canvas UI effort got declared dead, we talked about using Torsten's autopilot/property-rule subsystems to dynamically instantiate "property controllers" on-demand as part of the /canvas sub-tree (per Canvas or per element) to help update/animate Canvas elements - this would mean that the degree of added Nasal overhead would be kept to an absolute minimum that would only come to bear during initialiation of the corresponding C++ data structures, but afterwards everything would be pure C++ code
The main thing that prevented us from adding more widgets at the time was the degree of artwork needed, which is why Tom ended up borrowing artwork from Ubuntu, and we contemplated using a JavaScript/HTML widget set using SVG artwork, so that we would not have to draw dozens of widgets ...<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=288469#p288469
|title = <nowiki> Aircraft Center | pui2canvas parser (devel-list follow-up) </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Jun 12th, 2016
|added = Jun 12th, 2016
|script_version = 0.40
}}</ref>

the main loop/async point remains valid, but it would be possible for the Nasal/Canvas route to learn from Phi and use the same mongoose/httpd layer to run its property I/O and fgcommands asynchronously, at the mere cost of requiring the httpd service to be up and running for the UI to work in async mode. After all, all Nasal http I/O is already async anyway...
The best way to reduce Nasal overhead is expose more SimGear/FlighGear subsystems to scripting/Canvas space, so that e.g. property rules and state machines can be used for updating/animating Canvas elements - at that point, there's really no added Nasal overhead at all. Equally, it would be possible to not just support event handlers in the form of Nasal callbacks, but just fgcommands - which work without Nasal entirely.
The major benefit this would have is that Canvas is modern OpenGL/OSG code, and that it's integrated in an OSG--aware fashion, while also being property-tree enabled, which means that remote interaction scenarios can be easily implemented, which includes remote replication of UIs/MFDs etc.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=288469#p288469
|title = <nowiki> Aircraft Center | pui2canvas parser (devel-list follow-up) </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Jun 12th, 2016
|added = Jun 12th, 2016
|script_version = 0.40
}}</ref>

=== Moving GUI functionality back into C++ ===
In addition, there is the issue that the existing UI scheme can be mostly maintained by fgdata developers, i.e. people don't need to be proficient in C++ to add/extend existing GUI dialogs:

{{FGCquote
|1= what is currently happening is that functionality existing in Nasal/Canvas space is duplicated in C++ space - which is also introducing regressions, and added maintenance workload, because anything in Nasal/Canvas space can be maintained by fgdata committers, while C++ stuff can obviously only be maintained by core developers.
This is an advantage that the Phi and Canvas approaches have in common.
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=272314#p272314
| title = <nowiki>Re: Aircraft reselection </nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Jan 10th, 2016
}}
}}

=== Why should I care ? ===
Extending the Canvas system so that a PUI/XML parser can be provided in Nasal space can help address a number of long-standing issues. For instance, particularly people with AMD/ATI hardware are likely to greatly benefit from this effort, because ATI/AMD drivers are particularly prone to be incompatible with much of the existing legacy OpenGL code that exists today in FlightGear:

{{FGCquote
|1= I suspect something related to the way that the built in bitmap font is built or rendered - maybe an interaction with PUI.
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=268456#p268456
| title = <nowiki>Re: AMD Radeon R9 – Massive text flickering again</nowiki>
| author = <nowiki>Richard</nowiki>
| date = Dec 13th, 2015
}}
}}

{{FGCquote
|1= it has to be something related to the OpenGL usage within FlightGear or a fault within the implementation in the driver
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=268456#p268456
| title = <nowiki>Re: AMD Radeon R9 – Massive text flickering again</nowiki>
| author = <nowiki>Richard</nowiki>
| date = Dec 13th, 2015
}}
}}
{{FGCquote
|1= It's most likely a problem with the PUI (the current GUI), and the plan is to discontinue using it. There are experimental canvas GUIs which don't show the flickering
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=268743#p268743
| title = <nowiki>Re: AMD Radeon R9 – Massive text flickering again</nowiki>
| author = <nowiki>Thorsten</nowiki>
| date = Dec 16th, 2015
}}
}}

While FlightGear is using OpenSceneGraph these days, there is tons of legacy OpenGL code accumulated over the course of almost two decades of development. Unfortunately, this legacy code has to run within the fgfs main loop, and it is complicating matters for OpenSceneGraph/OpenGL - not just for buggy drivers, but also more lenient drivers that may provide much worse performance due to all this legacy OpenGL code.

While an alternate GUI could indeed be just as well provided by Phi/Qt5, that would not help address ATI/AMD issues existing elsewhere, such as compatibility with other legacy code (splash screen, 2D panels, HUD, MFDs).

Canvas can however help unify related features, so that these can be re-implemented and maintained in scripting space (fgdata), and legacy C++ code can be removed.

While it is true that future ATI/AMD driver updates may make drivers more lenient, extending the Canvas system will still be beneficial for other reasons, such as anybody interested in MFDs (airliner, biz jets).

=== Is this going to be committed ? ===
It depends. In its current form this is a proof-of-concept, and it would definitely need some TLC to be ready for prime time. Equally, getting more people involved would be helpful, but most contributors are hesitant to get involved in something like this due to the Phi/Qt5 efforts, which could quickly make this whole thing obsolete.

As of mid 2016, the general consensus seems that if it is true that this could help deprecating PUI, probably nobody would object against removing PUI and replace it by CUI, keeping the old syntax. At least for a while. Dropping PUI would be a huge step forward <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35157325/
|title = <nowiki> Re: [Flightgear-devel] GUI options (Was: Aircraft center) </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jun 14th, 2016
|added = Jun 14th, 2016
|script_version = 0.40
}}</ref>, i.e. the status is that since there has not been a fundamental objection against this on the mailing list and several people have said they can live with the option as long as it remains an option, ThorstenR offered to commit pui2canvas to FGData in the form of a Nasal module that gets loaded 'on demand' dependent on a set property (similar to AW).
We'll then see whether people find it more widely useful etc. and whether FG more generally relies on it for fixing certain PUI bugs/issues or not.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=289910#p289910
|title = <nowiki> Re: canvas vs. on-screen messages - 1:0 </nowiki>
|author = <nowiki> Thorsten </nowiki>
|date = Jul 2nd, 2016
|added = Jul 2nd, 2016
|script_version = 0.40
}}</ref>

{{FGCquote
|1= As far as I am concerned, most of the people that I have been in touch with about this, are very much hesitant to adopt, let alone get involved in, this - because the ongoing Phi/Qt5 efforts are considered to possibly make the Nasal/Canvas based parser obsolete sooner or later.
I have yet to see any definite statement about the future of Qt5 adoption in FlightGear, and if/how this will affect overlapping efforts that are considered "dead-ends" by other core developers. Thus, for understandable reasons, I am not prioritiing the whole thing currently.
But should the situation regarding segfaults related to the Qt5 integration layer in FlightGear not improve anytime soon, we may want to revisit the whole parser approach.
In the meantime, the wiki article contains all the info, pointers and code snippets to extend this, should the need arise.
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=268807#p268807
| title = <nowiki>Re: AMD Radeon R9 – Massive text flickering again</nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Dec 16th, 2015
| added = Dec 16th, 2015
| script_version = 0.25
}}
}}

In summary, the pui2canvas effort does not need to be used, supported, endorsed or even just reviewed/committed by any core developers, because it's just a tiny, and optional, Nasal/Canvas module that can be added to fgdata by fgdata contributors - or even just distributed as a self-contained Nasal module that can be dropped into $FG_HOME/Nasal - and it just works, so there really is no "disconnect" or "communication barrier" here - that debate took place years ago, and James himself came up with most of the ideas related to this, we're really just implementing his original proposal - regardless of his Qt5 work, and regardless of his current priorities - he not only came up with these ideas, but approved them and encouraged this work, just like he encouraged the development of the Canvas based aircraft center<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=289032#p289032
|title = <nowiki> Re: Aircraft Center | pui2canvas parser (devel-list follow-u </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Jun 18th, 2016
|added = Jun 18th, 2016
|script_version = 0.40
}}</ref>

=== How can this be helpful to Phi/Qt5 ? ===
Modernizing the UI is long overdue, but our existing GUI dialogs are frankly a huge mess.
It is far from trivial to just "port" the UI to a different framework.

Realistically, we cannot easily phase out PUI anytime soon, because we need to maintain parity with existing features support by the combination of PUI/XML and Nasal.

The main challenge is the excessive amount of embedded Nasal code in dialogs, as well as property/fgcommand-based hacks to work around PUI limitations (e.g. tabs implemented as buttons hiding widgets using SGConditions).

Thus, writing/maintaining a parser is the only feasible thing to do, and it would allow us to identify problematic dialogs, and incrementally rewrite those to reduce the amount of Nasal code and "widget hacks", so that dialogs would later become much leaner over time, which would make it much easier for Qt5/Phi to support such dialogs.

In the meantime, the parser could help provide an integrated non-PUI solution while transitioning to a new scheme, i.e. a "fallback" scheme that does not require tons of efforts/dependencies.

=== How is this useful regardless of the UI ? ===
It's a pretty awesome way to exercise, stress-test and benchmark the Canvas engine, especially in conjunction with running the [[Built-in Profiler]]-which is to say that Canvas engine may be further optimized based on the findings made through this parser, which may eventually translate into better performance for other Canvas-related features (e.g. MFDs).

Furthermore, a few core developers have expressed an interest in phasing out other modules using legacy OpenGL code, e.g. the HUD and 2D panels - which could be equally parsed/re-implemented using a Nasal/Canvas approach.

regardless of the outcome of this, this work is fairly self-contained and instructional for other reasons, i.e. helping unify the 2D rendering back-end (2D panels, HUD, splash screen, osgText animation) for better OpenGL compatibility, as per James' original proposal: [[Unifying the 2D rendering backend via canvas]]
In other words, the whole approach could be adapted to also parse legacy 2D panels and HUD XML files to use modern OSG-aware OpenGL code, and any improvements to the lower-level C++ code would obviously not be specific to just the UI use-case.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=289322#p289322
|title = <nowiki> Re: Aircraft Center | pui2canvas parser (devel-list follow-u </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Jun 21st, 2016
|added = Jun 21st, 2016
|script_version = 0.40
}}</ref>

== Development ==

In general, people familiar with basic Nasal skills should have no problems picking up the concepts introduced here. In particular, people will want to read up on:
=== Property Processing ===
* XML parsing/processing using io.read_properties() {{Fgdata file|Nasal/io.nas}}
* {{Fgdata file|Nasal/props.nas}} (Nasal module wrapping the Property Tree APIs)

=== PLIB PUI ===
[[File:Exit.png|thumb|FlightGear GUI dialog (exit.xml)stored in $FG_ROOT/gui/dialogs]]
* [[Howto:Editing and creating GUI dialogs in FlightGear]]
* {{readme file|gui}}
* [[Bindings]]
* {{readme file|layout}} ({{Flightgear file|src/GUI/layout.cxx}} and {{Flightgear file|src/GUI/layout-props.cxx}})
* {{Fgdata file|gui/dialogs}} (folder containing existing PUI/XML dialogs)

=== Canvas Widgets ===
* {{Flightgear file|src/GUI/FGPUIDialog.cxx|l=853}} (the PUI widget factory)
* [[Canvas]]
* [[Canvas Snippets]]
* [[Howto:Creating a Canvas GUI Widget]] (recently received a major update by Red Leader)
* {{Fgdata file|Nasal/canvas/gui/Widget.nas}} (this is the baseclass that needs be inherited from for each widget)
* {{Fgdata file|Nasal/canvas/widgets}} (and {{Fgdata file|Nasal/canvas/dialogs}} for existing examples)
* [[Canvas Event Handling]] (to map mouse/keyboard events to the Canvas system)
* [[Canvas Layout System]] (this will be needed to map PUI layouts to Canvas layouts, e.g. a table consists of rows and columns)

=== Nasal Internals ===
* Nasal APIs like {{func link|call()}}, {{func link|compile()}}, {{func link|bind()}} (specifically useful to deal with embedded Nasal sections, e.g. load/close sections)

So far, this represents roughly 1-2 hours of hacking, with most of the time spent documenting the process for people wanting to adopt/extend the concept.

The parser will be extended with a focus on:
* supporting localized dialogs using a propertylist xml overlay from $FG_ROOT/Translations
* identifying extensive use of Nasal, to introduce helper widgets/tags (e.g. a multiplayer pilot list)
* supporting versioning (e.g. to easily be able to extend the underlying PUI/XML subset)
* benchmarking and stress-testing different aspects of Canvas (Nasal, Property Tree, Canvas)
* supporting dynamic PUI dialogs and the corresponding fgcommands (which may need to be patched at run-time)
* supporting Nasal-based (procedural) PUI dialogs (think checklists/tutorials)
* identifying opportunities for optimizing Canvas further

=== Roadmap ===


* support {{tag|live}} properties
* implement support for table layouts {{Progressbar|70}}
* map alignments to layouts and widgets {{Not done}}
* extend/fix up the parser for any dialogs that are breaking it for the time being
* implement fgcommand patching for PUI related fgcommands {{Progressbar|40}}
* adapt the parser to work for aircraft dialogs, i.e those outside $FG_ROOT/gui/dialogs (easy) {{Not done}}
* implement missing widgets (radio, combo, slider/dial, various lists, e.g. file-picker) {{Not done}}
* review/implement use of <code>/sim/gui/dialogs</code> idiom
* implement support for conditions {{Not done}}
* stress-test dialogs with embedded Nasal code (make bind/compile work correctly) {{Not done}}
* fgcommand/script blocks must be bound to the dialog's nasal/open block
* implement support for the {{tag|canvas}} tag {{Progressbar|40}}
* review gui.nas and screen.nas uses of {{fgcommand|dialog-show}}, {{fgcommand|dialog-new}} etc
** <code>gui.showHelpDialog()</code>
** <code>gui.propertyBorwser()</code>
** seapport
** wildfire
** multiplayer/pilot list
** performance monitor
** review [[Tutorials]] and [[Aircraft Checklists]] {{Not done}}
** joystick config dialog
* the loglist widget APIs needs to be exposed via cppbind so that the widget can be recreated
* implement support for the {{tag|color}} tag and a pui-to-canvas font mapping {{Not done}}
* implement styling/theming (not sure...?)

=== Milestones ===

# come up with a io.read_properties() based parser framework to process PUI/XML files {{Done}}
# create a widget factory that maps common PUI/XML tags to existing Canvas widgets {{Done}}
# begin supporting PUI vbox/hbox layouts by mapping those to Canvas layouts {{Done}}
# review what's needed for supporting a minimal subset of PUI/XML and widgets {{Done}}
# come up with missing widgets

=== Issues ===

==Motivation==
{{FGCquote
|1= Generally, might I suggest to carefully consider gain to pain ratio before changing dependencies even if it looks cool and promising. Maybe I'm the only one, maybe not, but at least I am usually not on the latest and greatest Linux distribution. The reason is that I need to be able to run some pretty old software (some libs I only have in binary format), I need to be able to compile 25 year old Fortran code, and I have plenty of custom-rigged stuff on my box, including a heavily modified LaTeX framework for typesetting my Elvish work. Historically, every time I had to update Linux, I ended up doing two weeks of doing nothing else before everything worked again, and it doesn't get easier as time passes. So if a change in a dependency ends up forcing me to upgrade my Linux distribution, there might be a situation in which FG has to give and I simply don't do it for a long time. And if some cool novel C++ feature saves someone else ten hours, but costs hundred hours of my work, the project doesn't exactly end up winning. So please, don't do such things because it's cool or neat, do it only if there's a clear use case and this is a true enabler for new potential.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34522465/
| title = <nowiki>Re: [Flightgear-devel] C++11</nowiki>
| author = <nowiki>Thorsten Renk</nowiki>
| date = Oct 7th, 2015
| added = Oct 7th, 2015
| script_version = 0.23
}}
}}
{{FGCquote
|1= I'm worried that we end up with a situation in which developers on the latest Linux distros happily write code utiliing the newest of the newest and people on systems 2-3 years behind (like myself for reasons elaborated elsewhere) have to acquire random stuff to make a particular aircraft / feature work despite being able to compile and having a running FG.
Basically I want FG to work out of the box once it's compiled, and talk about a huge collection of libraries to be utilized worries me.
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=270822#p270822
| title = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki>
| author = <nowiki>Thorsten</nowiki>
| date = Dec 31st, 2015
| added = Dec 31st, 2015
| script_version = 0.23
}}
}}
{{FGCquote|1= There is 100% agreement that FlightGear will never require Qt, the only question is if the GUI requires Qt|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/34532040/ | title = <nowiki>[Flightgear-devel] GUI questions (again)</nowiki> | author = <nowiki>James Turner</nowiki> | date = Oct 11th, 2015 }}}}

{{FGCquote|1= note that Qt is supposed to be optional - so what do we do if Qt isn't added at compile time?|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/34536489/ | title = <nowiki>Re: [Flightgear-devel] GUI questions (again)</nowiki> | author = <nowiki>Thorsten Renk</nowiki> | date = Oct 13th, 2015 }}}}

{{FGCquote
|1= making Qt5 an optional dependency - de-facto it's not really as there's no alternative provided and very few people will write their own or have a two-monitor setup and use Phi.
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=270808#p270808
| title = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki>
| author = <nowiki>Thorsten</nowiki>
| date = Dec 31st, 2015
| added = Dec 31st, 2015
| script_version = 0.23
}}
}}

{{FGCquote|1= Again, there is /no/ problem at all making a Qt runtime that supports the current dialog XML syntax, with some enhancements to make richer widgets work. My problem is that doesn’t solve the ‘non-Qt’ setup, and I agree [...] that this use case is worth worrying about for aircraft dialogs.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/34537052/ | title = <nowiki>Re: [Flightgear-devel] GUI questions (again)</nowiki> | author = <nowiki>James Turner</nowiki> | date = Oct 13th, 2015 }}}}

{{FGCquote|1= building a QT based GUI is not in any way meant to obstruct the further development of a Canvas based GUI.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/34196458/ | title = <nowiki>Re: [Flightgear-devel] Policy Document and V4.X Roadmap</nowiki> | author = <nowiki>Durk Talsma</nowiki> | date = Jun 11th, 2015 }}}}

{{FGCquote|1= the design goal of Phi was never to be a fully featured replacement for the PUI GUI and the windowing system|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/34536582/ | title = <nowiki>Re: [Flightgear-devel] GUI questions (again)</nowiki> | author = <nowiki>Edward d'Auvergne</nowiki> | date = Oct 13th, 2015 }}}}

{{FGCquote|1= I agree that separate user interface windows would be nice in several interesting use cases, but I don't think the default single-screen case is one of them.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/29588512/ | title = <nowiki>Re: [Flightgear-devel] Switching from PUI to osgWidget</nowiki> | author = <nowiki>Tim Moore</nowiki> | date = Jul 25th, 2012 }}}}

{{FGCquote|1= I doubt that using Phi as the interface to control a Space Shuttle will ever take off, and that a WebUI would ever be comparable to a true GUI. |2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/34536582/ | title = <nowiki>Re: [Flightgear-devel] GUI questions (again)</nowiki> | author = <nowiki>Edward d'Auvergne</nowiki> | date = Oct 13th, 2015 }}}}

{{FGCquote|1= Personally I find a separate browser instance rather ugly and unfortunate - I want a single FlightGear window running fullscreen and having to switch desktops to use UI is not good for me.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/34534194/ | title = <nowiki>Re: [Flightgear-devel] GUI questions (again)</nowiki> | author = <nowiki>James Turner</nowiki> | date = Oct 12th, 2015 }}}}

{{FGCquote|1= That is a valid point and for this we need an embedded UI.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/34534338/ | title = <nowiki>Re: [Flightgear-devel] GUI questions (again)</nowiki> | author = <nowiki>Torsten Dreyer</nowiki> | date = Oct 12th, 2015 }}}}

{{FGCquote|1= I'm most worried about aircraft-side dialogs in this scenario. All sim-specific dialogs can be taken care of by the respective GUI creators, and for instance it doesn't really matter how the detailed implementation of, say the weather selection, is in Phi vs. Qt as long as they do the same thing. But aircraft-specific dialogs are not under the control of the GUI creators.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/34532750/ | title = <nowiki>Re: [Flightgear-devel] GUI questions (again)</nowiki> | author = <nowiki>Thorsten Renk</nowiki> | date = Oct 12th, 2015 }}}}

{{FGCquote|1= even if we manage to come up with a way to define dialogs such that they can be parsed and executed in both Phi and Qt, someone would have to do this for possibly unmaintained aircraft as well and bring them up to speed. Makes a lite GUI which shows an unassuming version of the current xml definitions somewhat more attractive perhaps.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/34534099/ | title = <nowiki>Re: [Flightgear-devel] GUI questions (again)</nowiki> | author = <nowiki>Thorsten Renk</nowiki> | date = Oct 12th, 2015 }}}}

{{FGCquote|1= If we have to provide customied dialog definitions for every possible GUI module, it's not going to make me happy because dialog creation isn't my favorite activity. At which point an aircraft-side completely canvas-based GUI starts to look like an attractive option because it's going to run whatever module takes care of the GUI otherwise.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/34535800/ | title = <nowiki>Re: [Flightgear-devel] GUI questions (again)</nowiki> | author = <nowiki>Thorsten Renk</nowiki> | date = Oct 13th, 2015 }}}}

{{FGCquote|1= Any in-sim GUI using Qt will exist in parallel to the PLIB/PUI one for at least one major release, although this may mean maintaining two sets of dialogs, unless the XML-translation-tool is good enough that we can use it at run-time for aircraft dialogs.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/34532040/ | title = <nowiki>[Flightgear-devel] GUI questions (again)</nowiki> | author = <nowiki>James Turner</nowiki> | date = Oct 11th, 2015 }}}}

{{FGCquote|1= One concern I have though, from the discussions over the last year, is that the PUI->Qt migration plan is not a direct one-to-one migration. I.e. to have a main Qt window providing the main FlightGear window by containing a top menu bar followed by a QtWindow GL widget underneath, in which the FG main execution loop is run as a thread from within the Qt main loop. My impression was that the GUI will be a secondary window or dialog that you have to switch to. But one problem I see with this design is that all modern GUI toolkits (Qt, GTK, metro, Cacoa, Carbon, etc.) suffer from racing and segfaulting issues if the GUI main thread or main loop/event handler is not thread number 1.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/34536197/ | title = <nowiki>Re: [Flightgear-devel] GUI questions (again)</nowiki> | author = <nowiki>Edward d'Auvergne</nowiki> | date = Oct 13th, 2015 }}}}

{{FGCquote|1= My general impression with the phi effort is that has great possibilities, but has no documentation and requires an in-depth knowledge of HTML5, CSS, SVG, javascript and countless javascript addons/libraries.|2= {{cite web | url = http://forum.flightgear.org/viewtopic.php?p=261083#p261083 | title = <nowiki>Re: Heaven or Hell? Phi sneak preview.</nowiki> | author = <nowiki>Alant</nowiki> | date = Oct 19th, 2015 }}}}

{{FGCquote|1= Phi is using a large number of HTML5 technologies. My list is HTML5, Javascript, SVG, CSS. On top of this there the Javascript addons Jquery, Knockout, Leaflet, Sammy, Clockpicker, Flot, Require, Jquery-ui, etc etc etc.|2= {{cite web | url = http://forum.flightgear.org/viewtopic.php?p=261115#p261115 | title = <nowiki>Re: Heaven or Hell? Phi sneak preview.</nowiki> | author = <nowiki>Alant</nowiki> | date = Oct 20th, 2015 }}}}

{{FGCquote|1= The data flow and linkage between all of these packages and Flightgear is very well hidden.Yes I have searched for and looked at countless tutorials on the web, but have found very little of direct relevance.|2= {{cite web | url = http://forum.flightgear.org/viewtopic.php?p=261115#p261115 | title = <nowiki>Re: Heaven or Hell? Phi sneak preview.</nowiki> | author = <nowiki>Alant</nowiki> | date = Oct 20th, 2015 }}}}

{{FGCquote|1= In comparison Canvas GUI, even in its current state is perhaps easier to handle for many purposes.|2= {{cite web | url = http://forum.flightgear.org/viewtopic.php?p=261252#p261252 | title = <nowiki>Re: Heaven or Hell? Phi sneak preview.</nowiki> | author = <nowiki>Johan G</nowiki> | date = Oct 21st, 2015 }}}}

{{FGCquote|1= Given the state of plans as outlined on the mailing list, I think this would be most useful to have, if only for a transition period.|2= {{cite web | url = http://forum.flightgear.org/viewtopic.php?p=260845#p260845 | title = <nowiki>Re: New Canvas GUI</nowiki> | author = <nowiki>Thorsten</nowiki> | date = Oct 17th, 2015 }}}}

The whole point of this is to provide a sane migration path for our existing PUI/PropertyList-based XML dialogs.
Regardless of the GUI solution that will be in use 5+ years from now, we will need a way to deal with our existing UI once PUI is gone.

It has been made clear by the Qt5/Phi developers that the large share of custom [[Nasal]] code is complicating porting efforts.

Ironically, the most straightforward dialogs to "port" are exactly those using "just" PUI markup, without '''any''' Nasal code at all.

However, none of the discussions revolving around Qt5/Phi have addressed the fact that a large share of FlightGear dialogs that exist today, are in fact using Nasal for creating semi-dynamic, or even procedural dialogs.

This can be easily seen by running <code>cd $FG_ROOT/gui/dialogs && grep -nr cmdarg *</code> as well as <code>cd $FG_ROOT/Nasal && grep -nr dialog-show *</code>. In other words, these dialogs cannot be easily converted to a different UI framework short of rewriting them from scratch, or introducing support for embedded Nasal (Qt5)/JavaScript (Phi) code, too.

Looking at the staggering amounts of Nasal code in existing dialog files (referring just to $FG_ROOT), it is neither feasible to automatically port all those dialogs, nor to port them manually. And even if someone should volunteer their time to do so, this would very likely take at least 2-3 release cycles, or introduce major regressions in the meantime.

==Background ==
At the end of 2015, it became clear that a number of core developers were contemplating to phase out our integrated legacy GUI engine (PLIB PUI) in favor of external solutions using Qt5 and Phi (browser-based).

Subsequently, it was also made clear that there were plans being discussed not to provide any built-in GUI solution at all, and to phase out existing PUI dialogs, too.

According to discussions in 10/2015, there was no plan in place to deal with existing dialogs, short of rewriting them from scratch or converting them to the new GUI scheme using a scripted converter.

Which means that the primary means for interacting with the simulator would then either be a Qt5-enabled build of FlightGear, or a web-browser using Phi.

It is foreseeable that given the different technology stacks involved in the Qt5/Phi efforts (but also the added maintenance overhead due to having to maintain separate front-ends), FlightGear UI capabilities will increasingly begin to diverge over time, with certain features and use-cases being possibly only supported by one of the two main alternatives at some point.

Just like the functionality of the plethora of existing external FlightGear GUI front-ends is diverging strongly.

However, Canvas -our hardware-accelerated 2D rendering API- is there to stay:
{{FGCquote
|1= There's no serious 'no canvas' mode forseen as far as I know - so 'no canvas' pretty much is 'no rendering'.
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=264824#p264824
| title = <nowiki>Re: version checking for matching fgfs and -set.xml files</nowiki>
| author = <nowiki>Thorsten</nowiki>
| date = Nov 17th, 2015
| added = Nov 17th, 2015
| script_version = 0.25
}}
}}
So it makes sense to explore using Canvas for providing a Nasal/Canvas parser than can deal with existing PUI dialogs (without having to modify those) to procedurally interpret them and turn those into Canvas Widgets, and GUI dialogs - using modern OSG code, that is directly integrated with the scene graph.

The intention is not to conflict or compete with the Qt5/Phi efforts, but to provide an alternative for those end-users, and aircraft developers, who may still want to run an internal UI, without having to link against the Qt5 dependency, and without having to use a browser to interact with the simulator.

For the time being, it isn't clear if the approach described and used below will be too well embraced, or even just supported - let alone committed to the base package. So this serves primarily as a reference for those wanting to use existing dialog files using Canvas.

The approach detailed below is sufficiently losely coupled, so that it does not depend on core developers having to review/approve of this technique. It provides a straightforward mechanism for people wanting to get rid of PUI, without necessarily having to use an external GUI like Phi or Qt5.

== Original Discussion ==
{{FGCquote|1= FlightGear uses a gui widget set that is implemented on top of OpenGL. This has many advantages from a portability standpoint and from the standpoint of integrating with window systems. "Pui" doesn't have every feature under the sun, but it was never meant to. It's relatively small, lean, mean, and written on top of OpenGL which makes life *much* easier for us.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/24461156/ | title = <nowiki>Re: [Flightgear-devel] GUI dialogs suck</nowiki> | author = <nowiki>Curtis Olson</nowiki> | date = Jan 29th, 2010 }}}}

{{FGCquote|1= If you know something about gui systems, something about portability of code across all our supported platforms, and something about flightgear. Then post a proposal for a change. Better yet, post patches with a new gui system that doesn't suck, runs efficiently, supports all platforms, integrates cleanly with FlightGear, doesn't add a nightmare of new library dependencies, isn't chock full of bugs, does everything the current system does, and does everything you think a gui system should do, etc. etc.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/24461156/ | title = <nowiki>Re: [Flightgear-devel] GUI dialogs suck</nowiki> | author = <nowiki>Curtis Olson</nowiki> | date = Jan 29th, 2010 }}}}

{{FGCquote|1= the current solution based on PUI really needs to go away for plenty reasons, especially the horrible OpenGL code it runs. |2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/34532040/ | title = <nowiki>[Flightgear-devel] GUI questions (again)</nowiki> | author = <nowiki>James Turner</nowiki> | date = Oct 11th, 2015 }}}}

{{FGCquote|1= Using the Canvas also for the GUI would give us the advantage of a unified rendering backend for any type of GUI/text rendering and also the ability to use the same widgets everywhere - eg. use them also inside aircrafts for CDU GUIs or other displays...|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/29584553/ | title = <nowiki>Re: [Flightgear-devel] Switching from PUI to osgWidget</nowiki> | author = <nowiki>Thomas Geymayer</nowiki> | date = Jul 24th, 2012 }}}}

{{FGCquote|1= Keeping the current XML format is really a requirement - improving that format, especially handling of layouts, is another task, but there's too many existing dialogs to really break compatibility.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/29583931/ | title = <nowiki>Re: [Flightgear-devel] Switching from PUI to osgWidget</nowiki> | author = <nowiki>James Turner</nowiki> | date = Jul 24th, 2012 }}}}

{{FGCquote|1= of course it should be possible to support the current XML syntax using any toolkit, it just's a question of how hard it is.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/29583931/ | title = <nowiki>Re: [Flightgear-devel] Switching from PUI to osgWidget</nowiki> | author = <nowiki>James Turner</nowiki> | date = Jul 24th, 2012 }}}}

{{FGCquote|1= so long as you keep XML compatibility most of the current Nasal interaction with the GUI will work. There is great scope to make /better/ Nasal APIs for items such as combo-boxes and pickers, especially ICAO and radio frequency pickers, but that's all 'improving the GUI' work than can happen once we've ditched PLIB and have something hackable.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/29583931/ | title = <nowiki>Re: [Flightgear-devel] Switching from PUI to osgWidget</nowiki> | author = <nowiki>James Turner</nowiki> | date = Jul 24th, 2012 }}}}

{{FGCquote|1= The long term idea is to eventually port some other 2D elements to this backend (eg the HUD and 2D panels) so they use OSG (and osgText) natively, and hence reduce the amount of C++ code we have for these jobs. (And increase our chances of working with never OpenGL versions that forbid old style GL calls) |2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/29335901/ | title = <nowiki>Re: [Flightgear-devel] Canvas (2D drawing API) - Testing needed</nowiki> | author = <nowiki>James Turner</nowiki> | date = May 30th, 2012 }}}}

{{FGCquote|1= I'd also like to see / understand how we manage XML / property-list file processing in a nice way, to support the various formats we want to create canvas elements from - GUI dialogs, 2D panels and HUDs.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/29588419/ | title = <nowiki>Re: [Flightgear-devel] Switching from PUI to osgWidget</nowiki> | author = <nowiki>James Turner</nowiki> | date = Jul 25th, 2012 }}}}

{{FGCquote|1= In particular I'm interested to see what aspects of XML -> building canvas elements are common between 2D panels, the GUI dialogs and HUD code.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/29588418/ | title = <nowiki>Re: [Flightgear-devel] Switching from PUI to osgWidget</nowiki> | author = <nowiki>James Turner</nowiki> | date = Jul 25th, 2012 }}}}

{{FGCquote|1= I'm even more convinced now that we should move the 2D panel and HUD rendering over to this approach, since that would get rid of all the legacy OpenGL code besides the GUI.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/29584988/ | title = <nowiki>Re: [Flightgear-devel] Switching from PUI to osgWidget</nowiki> | author = <nowiki>James Turner</nowiki> | date = Jul 24th, 2012 }}}}

{{FGCquote|1= We could for example just add some more parseXXX functions (like parsesvg) which parse a dialog/hud/whathever file and create a canvas from it. So we would just have to modify eg. the show-dialog command to create a canvas and call the parser.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/29589689/ | title = <nowiki>Re: [Flightgear-devel] Switching from PUI to osgWidget</nowiki> | author = <nowiki>Thomas Geymayer</nowiki> | date = Jul 25th, 2012 }}}}

{{FGCquote|1= We need to keep the existing way of specifying GUI files via XML - it's a nice, declarative way of building the dialogs. Switching to an imperative system would be a step backwards. I do like the idea of a gui/widget/widgetname.nas structure so we can easily create a factory function and hack / add widgets.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/29592603/ | title = <nowiki>Re: [Flightgear-devel] Switching from PUI to osgWidget</nowiki> | author = <nowiki>James Turner</nowiki> | date = Jul 26th, 2012 }}}}

{{FGCquote|1= I didn't mean to replace the existing way, but instead only changing the implementation to use the Canvas system in Nasal space. Just mapping the existing dialog-show command to a Nasal function which creates a window and parses a GUI xml file. This wouldn't change anything on how dialogs are specified and shown.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/29592872/ | title = <nowiki>Re: [Flightgear-devel] Switching from PUI to osgWidget</nowiki> | author = <nowiki>Thomas Geymayer</nowiki> | date = Jul 26th, 2012 }}}}

{{FGCquote|1= I think the best place would be doing it with Nasal, as there is already all the information needed available. C++ doesn't know anything about widgets...|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/29592872/ | title = <nowiki>Re: [Flightgear-devel] Switching from PUI to osgWidget</nowiki> | author = <nowiki>Thomas Geymayer</nowiki> | date = Jul 26th, 2012 }}}}

{{FGCquote|1= As you say, so long as we're going through show-dialog it should be fine.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/29592939/ | title = <nowiki>Re: [Flightgear-devel] Switching from PUI to osgWidget</nowiki> | author = <nowiki>James Turner</nowiki> | date = Jul 26th, 2012 }}}}

{{FGCquote|1= Of course, it’s great if Canvas is as the point that we can actually consider such things, and hopefully the actual arrangement of screens + widgets is easy to evaluate and adjust. |2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/33055321/ | title = <nowiki>Re: [Flightgear-devel] Features for 3.4 please</nowiki> | author = <nowiki>James Turner</nowiki> | date = Nov 19th, 2014 }}}}

{{FGCquote|1= I don't want to spend too much work in getting PUI and Canvas dialogs working at the same time. The layout and widget systems is now maturing, so I think after 3.2 I can start with porting PUI. Just one major component is missing, namely keyboard input and the according input focus. I guess this will take one or two more releases.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/32457866/ | title = <nowiki>Re: [Flightgear-devel] Notes on Aircraft Center...</nowiki> | author = <nowiki>Thomas Geymayer</nowiki> | date = Jun 13th, 2014 }}}}

== Implementation ==
Our existing PUI/XML files can be broadly classified to support the following types of tags:
* layouting related (group, frame, layout, hbox, vbox etc)
* widgets - (checkbox, combo, text etc) these are actual PUI widgets with their associated properties and attributes (as per README.gui)
* bindings - these are "actions" that are triggered
* conditions (used to conditionally hide/show widgets)
* embedded scripts - used for pretty much everything else, e.g. to manipulate the dialog tree before it is shown
* styling/theming related (not discussed here)

In general, the parser is a foreach-loop that uses the props.nas APIs to get a list of XML tags and it will recursively check a map (Nasal hash) with PUI tags and then invoke the callback registered there - as the "context", it will pass the canvas/layout/group etc. to be modified/updated.

So, adding support for a new tag would require navigating to the "WidgetFactory" hash, which contains key/value pairs - each key is a valid PUI tag, and the value is a callback that will be invoked once the tag is encountered in the xml dialog.

Some of the more tricky things are "bindings", fgcommands and layouting (table layouts), and conditions - the latter need to be mapped to the props.nas stuff.

=== Approach ===
{{Note|This is using ''exactly'' the approach originally [[#Original Discussion|discussed on the devel mailing list]], and agreed to be used by the core developers involved in that discussion.}}
[[File:Nasal-console-running-pui-parser.png|thumb|Nasal Console used for testing a custom fgcommand that turns PUI/PropertyList markup into Canvas widgets]]

All PUI/XML dialogs are currently handled by a handful of fgcommands, it has meanwhile become possible to also register/override fgcommands via Nasal code. Which in turn makes it possible to prototype new fgcommands in Nasal space, but also to completely override hard-coded fgcommands once the prototype works sufficiently well (at that point, there would be no patching of XML files required anymore).

For prototyping purposes, we will be registering [[Howto:Add new fgcommands to FlightGear#Background|a custom fgcommand]] in [[Nasal]] using the {{func link|addcommand()}} API and patch [[Menubar|menubar.xml]] to change <code>dialog-show</code> fgcommands (as per {{readme file|commands}}) into <code>canvas-dialog-show</code> for each dialog whose widgets are supported/ported.

For starters, we will focus on simple dialogs, such as {{GUI dialog|dialog=about}} and {{GUI dialog|dialog=exit}} — however, the framework will be sufficiently generic to also support other widgets/dialogs (as per README.gui).

Once a sufficiently-large subset of PUI widgets are supported by the parser, it would also be possible to override the {{fgcommand|dialog-show}} command directly to circumvent the underlying PUI C++ code, which could then also be disabled, phased out/removed in its entirety.

In theory, the same approach could be used for writing Nasal parsers that turn our existing [[HUD]] and 2D panel files into their Canvas equivalents, so that we can [[Unifying the 2D rendering backend via canvas|get rid of other legacy OpenGL code in the process]], too.

=== Challenges ===
{{FGCquote|1= I have played a little with a PUI-XML interpreter for Phi. It worked pretty well for simple and basic dialogs. For complex dialogs like the weather dialog, this approach failed completely as there is too much Nasal involved which I can't (read: don't want to) port over to javascript. My proposal is to drop all existing PUI dialogs and recreate them from scratch.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/34532860/ | title = <nowiki>Re: [Flightgear-devel] GUI questions (again)</nowiki> | author = <nowiki>Torsten Dreyer</nowiki> | date = Oct 12th, 2015 }}}}

The staggering amount of custom Nasal code sections (read:hacks) in some dialog files is astonishing and a challenge not just for the Phi/Qt5 efforts, but also not exactly thrilling for people wanting to interpret dialogs using Nasal/Canvas.
Equally, many PUI Widgets can be trivially ported/re-implemented using Nasal/Canvas, while others are more sophisticated - e.g. the airport-list and property-list widgets. Also, a number of PUI widgets are unfortunately not even documented in README.gui, but still used by some dialogs.

While that does apply to the <canvas> tag, too - that is fortunately straightforward to support using a Nasal/Canvas parser.

Otherwise, it is obviously true that this Nasal/Canvas-based approach will add to the Property Tree/Nasal overhead. However, the number of PUI widgets is comparatively small. So supporting a safe subset of PUI, and adapting a few existing dialogs accordingly should be relatively straightforward.

Nevertheless, it would make sense to modify the parser so that it can analyse each dialog and dump some stats to the console, e.g. to identify dialogs with lots of embedded Nasal blocks (or conditionally-shown widgets), which is typically the case for dialogs that are working around PUI limitations. Which means that it would make sense to identify the underlying use-case/scenario (such as missing support for tabs) and introduce custom tags that are mapped to a Canvas equivalent, to incrementally phase out huge Nasal sections in favor of custom widgets that are implemented elsewhere, e.g. a pilot-list widget (and which could also be wrapped much more easily by Phi/Qt5).

Ideally, the parser would dump a number of metrics to the console, such as:
* number of layouts created
* number of widgets
* number of Nasal callbacks (timers/listeners)
* size of embedded code blocks

=== Hooking into the menubar ===
First, we will patch menubar.xml for the dialog that we want to display using Canvas (this could be done during startup to the in-memory copy of menubar.xml):

<syntaxhighlight lang="diff">
diff --git a/gui/menubar.xml b/gui/menubar.xml
index e0a1bf5..6050429 100644
--- a/gui/menubar.xml
+++ b/gui/menubar.xml
@@ -89,7 +89,7 @@
<name>exit</name>
<key>Esc</key>
<binding>
- <command>dialog-show</command>
+ <command>canvas-dialog-show</command>
<dialog-name>exit</dialog-name>
</binding>
</item>

</syntaxhighlight>

This will ensure that the corresponding dialog will be passed to a custom fgcommand.

Next, we need to register a new fgcommand that will be invoked:

<syntaxhighlight lang="diff">
diff --git a/Nasal/canvas/gui/../pui-wrapper.nas b/Nasal/canvas/gui/../pui-wrapper.nas
new file mode 100644
index 0000000..009d172
--- /dev/null
+++ b/Nasal/canvas/gui/../pui-wrapper.nas
@@ -0,0 +1,9 @@
+var PUI = {
+showDialog: func(node) {
+ print("Custom PUI/Canvas translator");
+ props.dump(node);
+},
+
+};
+
+addcommand("canvas-dialog-show", PUI.showDialog);

</syntaxhighlight>

This adds a new file to $FG_ROOT/Nasal/canvas, named pui-wrapper.nas, which will be loaded into the canvas namespace. Next, it declares a sub-namespace named PUI, and implements a showDialog() function that merely dumps the fgcommand arguments to the console using the props.nas helpers.

Finally, it uses the addcommand API to register this function as a new fgcommand.

In its current form, this is not yet particularly useful, but it demonstrates how to map the handling of legacy GUI dialogs to the Canvas system. For now, the output will look like this:

<pre>
Custom PUI/Canvas translator
binding[9] {NONE} = nil
binding[9]/command {UNSPECIFIED} = canvas-dialog-show
binding[9]/dialog-name {UNSPECIFIED} = exit
</pre>

As can be seen, each fgcommand receives a full Property Tree node containing its arguments (command, dialog-name in this case).

=== Parsing the dialog node ===

First of all, we will need to parse the <code>dialog-name</code> property and append the .xml suffix so that we can build a file name and load the dialog file from the base package:

<syntaxhighlight lang="diff">
diff --git a/Nasal/canvas/gui/../pui-wrapper.nas b/Nasal/canvas/gui/../pui-wrapper.nas
new file mode 100644
index 0000000..26703b2
--- /dev/null
+++ b/Nasal/canvas/gui/../pui-wrapper.nas
@@ -0,0 +1,19 @@
+var PUI = {
+showDialog: func(node) {
+ var filename = node.getNode('dialog-name').getValue() or die("Missing file name");
+ # append .xml suffix:
+ filename ~= ".xml";
+
+ # build path relative to $FG_ROOT
+ var path = getprop("/sim/fg-root")~"/gui/dialogs/"~filename;
+
+ print("Custom PUI/Canvas translator for dialog:", filename);
+ # load the dialog from the base package
+ var dlgNode = io.read_properties(path);
+ # dump it to the console
+ props.dump(dlgNode);
+},
+
+};
+
+addcommand("canvas-dialog-show", PUI.showDialog);

</syntaxhighlight>

We can now also easily turn the dlgNode into a hash using the getValues() API provided by props.nas, and use that to e.g. read out the name/title of the dialog and use that to actually create a corresponding Canvas dialog:

<syntaxhighlight lang="diff">
diff --git a/Nasal/canvas/gui/../pui-wrapper.nas b/Nasal/canvas/gui/../pui-wrapper.nas
new file mode 100644
--- /dev/null
+++ b/Nasal/canvas/gui/../pui-wrapper.nas
@@ -0,0 +1,24 @@
+# beginning of canvas.PUI namespace
+var PUI = {
+showDialog: func(node) {
+ var filename = node.getNode('dialog-name').getValue() or die("Missing file name");
+ # append .xml suffix:
+ filename ~= ".xml";
+
+ # build path relative to $FG_ROOT
+ var path = getprop("/sim/fg-root")~"/gui/dialogs/"~filename;
+
+ print("Custom PUI/Canvas translator for dialog:", filename);
+ # load the dialog from the base package
+ var dlgNode = io.read_properties(path);
+ # dump it to the console
+ # props.dump(dlgNode);
+
+ dlgHash = dlgNode.getValues();
+ var window = canvas.Window.new([200,150],"dialog")
+ .set('title',dlgHash.name);
+}, # showDialog
+
+}; # end of PUI namespace
+
+addcommand("canvas-dialog-show", PUI.showDialog);
</syntaxhighlight>

=== Parsing widgets ===

[[File:Canvas-parser-for-pui-dialogs.png|thumb|Screen shot showing a Canvas dialog procedurally generated by parsing legacy/PUI dialogs]]

Next, we need to take a look at exit.xml to see what widgets/tags are used there, so that these can be incrementally added to our custom, Canvas-based, dialog handler:

<syntaxhighlight lang="xml"><?xml version="1.0"?>
<PropertyList>
<name>exit</name>
<modal>false</modal>
<layout>vbox</layout>

<text>
<label>Exit FlightGear?</label>
</text>

<group>
<layout>hbox</layout>
<halign>fill</halign>
<default-padding>10</default-padding>
<empty><stretch>true</stretch></empty>

<button>
<legend>Exit</legend>
<default>true</default>
<equal>true</equal>
<binding>
<command>exit</command>
</binding>
<binding>
<command>dialog-close</command>
</binding>
</button>
<empty><stretch>true</stretch></empty>

<button>
<legend>Cancel</legend>
<equal>true</equal>
<key>Esc</key>
<binding>
<command>dialog-close</command>
</binding>
</button>

<empty><stretch>true</stretch></empty>
</group>
</PropertyList>

</syntaxhighlight>

=== Coming up with a widget factory ===
Processing tags is pretty straightforward, as is mapping them to those Canvas widgets that exist already, as can be seen below.

{{collapsible script|type=Nasal code|title=|intro=So, now we need to come up with a hash to serve as a factory for all important XML tags (widgets/layouting primitives) - i.e. to map a button tag to a class creating a Canvas widget for each button:
|lang=nasal|script=
##
# maps PUI tags ($FG_ROOT/Docs/README.gui) to callbacks/widgets implementing the Canvas equivalent
TagFactory: {
'text': func(root, layout, node) {
var label = canvas.gui.widgets.Label.new(root, canvas.style, {wordWrap: 0});
label.setText(node.label);
layout.addItem(label);
}, # text

'group': func(root, layout, node) {
var myLayout = PUI.newLayout(node.layout);
layout.addItem(myLayout);
# TODO: recursively call other factory helpers (button, text etc)
}, # group

'button': func(root, layout, node) {
var button = canvas.gui.widgets.Button.new(root, canvas.style, {})
.setText(node.Legend);
layout.addItem(button);
}, # button
'input:' func(root, layout,node) {
}, # input
'checkbox': func(root, layout, node) {
}, # checkbox
'combo': func(root, layout, node) {
}, # combo
'list': func(root, layout, node) {
}, # list
'airport-list': func(root, layout, node) {
}, # airport-list
'property-list': func(root, layout, node) {
}, # property-list
'select': func(root, layout, node) {
}, # select
'slider':func(root, layout, node) {
}, # slider
'dial': func(root, layout, node) {
}, # dial
'textbox':func(root, layout, node) {
}, # textbox
'hrule': func(root, layout, node) {
}, #hrule
'vrule': func(root, layout, node) {
}, # vrule
'canvas': func(root, layout, node) {
}, # canvas
}, # TagFactory
</syntaxhighlight>
|conc=}}

[[File:Fgfs-canvas-dialog-parsing-pui-text-labels.png|thumb|Procedurally generated Canvas dialog by parsing legacy/PUI dialog markup]]

Basically, this is just a lookup table (in the form of a hash) that contains keys (PUI widget names) that are mapped to callbacks for instantiating the corresponding Canvas Widgets.

Our parser then merely needs to process the PropertyNode object and traverse all child nodes to look for supported tags, and call the corresponding callback then, which will be responsible for coming up with a Canvas equivalent of the corresponding PUI widget.

For the time being, the majority of these callbacks are just empty placeholders, because we still need to populate them - but the underlying idea can be seen in the implementations of the button/text and label widgets respectively.

=== Supporting Recursion ===

We also need to make sure that our parser can recursively call the factory helpers, i.e. for dealing with groups/frames and other layouting directives that may have arbitrary widgets as child nodes, including other groups/frames.

In this case, we need to register a group/frame helper that recursively processes any other widgets it encounters, to ensure that the buttons are properly aligned:

[[File:Exit-dialog-generated-by-canvas-parser.png|thumb|Screen shot showing a procedurally-generated dialog, based on parsing exit.xml]]

=== Layouting ===
The main layouting mechanism supported by Canvas are the vbox/hbox layouts, so there is currently no direct support for the table layout supported by PUI. Obviously, we can still implement a table layout using a vector of vbox/hbox layouts.
Equally, layouting using absolute positions must be supported (i.e. translations).

=== Supporting Bindings ===
Next, we need to make sure that we also support [[bindings]], i.e., commands that may be triggered, for example, when clicking on a button. An arbitrary number of bindings can be added, so this needs to be be a vector of callbacks in Nasal. Bindings come in two forms: [[Fgcommands]] and Nasal scripts. Both can be easily supported.
<syntaxhighlight lang="nasal">
setupCommandBinding: func(node){
var command = node.getNode("binding/command").getValue();
if (command == "nasal") return PUI.setupScriptBinding(node);
# TODO: fgcommands relating to PUI must be dynamically patched/overridden (e.g. dialog-close)
return func(){
fgcommand(command, node);
};
},

setupScriptBinding: func(node) {
var code = node.getNode("binding/script").getValue();
var codeObj = compile(code, "a binding"); # FIXME: should use file name, line number, binding name
return codeObj;
},

# returns a vector of bindings (fgcommands and nasal script)
setupBindings: func(node) {
var callbacks = [];
foreach(var binding; node.getChildren("binding")) {
append(callbacks, PUI.setupCommandBinding(node));
}
return callbacks;
},
</syntaxhighlight>

=== PUI related bindings ===
There is a handful of fgcommands that are PUI related, those need to be dynamically patched to be mapped to their Canvas equivalents. Specifically, these are:

* {{fgcommand|dialog-apply}}
* {{fgcommand|dialog-update}}
* {{fgcommand|dialog-close}} (trivial}
* {{fgcommand|dialog-show}} (trivial)
* {{fgcommand|gui-redraw}} <ref>https://forum.flightgear.org/viewtopic.php?f=30&t=29264&p=305509&hilit=redraw#p305509</ref>

{{Fgdata file|gui/dialogs/airports.xml}}
<syntaxhighlight lang="xml">
<input>
<name>input</name>
<pref-width>120</pref-width>
<halign>fill</halign>
<stretch>true</stretch>
<property>/sim/gui/dialogs/airports/list</property>
<binding>
<command>dialog-apply</command>
<object-name>input</object-name>
</binding>
<binding>
<command>dialog-update</command>
<object-name>airport-list</object-name>
</binding>
</input>

</syntaxhighlight>

With dialog-apply and dialog-update being the most important ones, because they are using an object-name child to address other widgets on the same dialog, i.e. quoting {{readme file|gui}}:

<pre>
airport-list
------------

like "list", but fills the list automatically with all airports known
to FlightGear. Calls bindings on airport selection and returns the
selected entry in <property> on dialog-apply. Interprets <property>
as search term on dialog-update.
</pre>

=== /sim/gui/dialogs ===

=== Conditions ===
PUI/XML markup is using a few helpers (via SGCondition, see $FG_ROOT/Docs/README.condtions) to decide if a widget is to be shown/hidden, this needs to be wrapped using the corresponding APIs in props.nas, e.g. compileCondition()

At the Canvas level, this would merely need to be wrapped to call the .hide() .show() methods respectively for the corresponding Canvas widget/group, so is straightforward to do.

=== Embedded Nasal ===
[[File:Tutorials-pui.png|thumb|c172p [[Tutorials]] dialog via [[PUI]]]]
[[File:Aircraft Checklists dialog.jpg|thumb|[[Aircraft Checklists]] dialog rendered by [[PUI]] ]]

(open/close tags may be used to manipulate the dialog tree, so take precedence, i.e. must be processed first, cmdarg() must be overridden via bind, fgcommand() must be wrapped too, to ensure that GUI related fgcommands (dialog-close) can be patched in bindings.)

Nasal code embedded in nasal/open sections needs to be executed first, with cmdarg() wrapped to return the props.Node object, so that the tree can be manipulated - i.e. something along the lines of:

<syntaxhighlight lang="nasal">
##
# handles non-widget aspects, i.e. dialog header and embedded Nasal (must take precedence!)
#
MetaTags: {
'nasal-open': func(node) {
print("nasal open!");
var ns = {cmdarg: func node};
var source=node.getNode("nasal/open").getValue();
var code=compile(source, node.getNode("name").getValue() ~ ".xml: (nasal/open)");
call(code,[],nil,ns,var err=[]);
}, # nasal open tag
'nasal-close': func(node) {
print("nasal close!");
}, # nasal close tag
}; # MetaTags

# ...

if(dlgNode.getNode("nasal/open")!=nil)
PUI.MetaTags["nasal-open"] (dlgNode);

</syntaxhighlight>

=== Embedded Canvas ===

[[File:Canvas-ND-resizable.png|thumb|right]]
[[File:Airport-selection-dialog.png|thumb|right]]
[[File:StuartsSlippyMap1.png|thumb|Stuart pushed some changes to fgdata with OpenStreetMap, OpenAIP and VFRMap layers for the Canvas Map Layer system, which can be seen on the canvas map dialog. They use a generic Slippy Map OverlayLayer Map Layer. Additional web-based mapping can be trivially added by creating a new lcontroller. See Nasal/Canvas/map/OpenAIP.lcontroller for an example.I've also added a Web Mercator Projection to the Canvas Map support.The wiki will be updated shortly.<ref>{{cite web |url = https://forum.flightgear.org/viewtopic.php?p=319545#p319545 |title = <nowiki> Re: Canvas G1000 </nowiki> |author = <nowiki> stuart </nowiki> |date = Sep 28th, 2017 |added = Sep 28th, 2017 |script_version = 0.40 }}</ref>]]

Some dialogs making use of embedded CanvasWidget widgets are:

* {{GUI dialog|dialog=airports}}
* {{GUI dialog|dialog=map-canvas}}
* [[Howto:Prototyping_a_new_NavDisplay_Style#Code]]

We will need to add a raster image child to the layout, and execute the nasal/load section, while overriding cmdarg() to return .getPath() accordingly. The only dialog using this is the airports.xml file

So we only need to populate our factory/canvas stub to read out the relevant tags, create a new Canvas, wrap the cmdarg() arg API and add the raster image child:

<syntaxhighlight lang="nasal">
'canvas': func(root, layout, node) {
var tmp=node.getValues();
var (w,h) = (tmp['pref-width'], tmp['pref-height']);

var newCanvas = canvas.new({
"name": "embedded",
"size": [512, 512],
"view": [512, 512],
});

# need to wrap cmdarg to return the node for the Canvas (which is currently hard-coded)
var cmdarg = func newCanvas._node;
# run the nasal/load block, must override cmdarg()
PUI.MetaTags["nasal-open"](node:node, cmdarg: cmdarg, tag:"nasal/load", filename:"canvas/nasal/load block");

# add a label widget to serve as the container for an embedded canvas
var label = canvas.gui.widgets.Label.new(root, canvas.style, {wordWrap: 0});
label.setImage( newCanvas.getPath() );
label.setFixedSize(256,256);
layout.addItem(label);
}, # canvas

</syntaxhighlight>

To see if the parser can correctly deal with an embedded canvas, we can use the PUI/XML dialog from [[Howto:Adding a canvas to a GUI dialog]]:

<gallery>
Fgplot-canvas.png|Simple PUI/XML dialog containing an embedded Canvas
Pui2canvas parser-showing-embedded-canvas.png|Screen shot showing a PUI/XML dialog with an embedded dialog, processed by a pui2canvas parser to render a corresponding Canvas dialog with widgets.
</gallery>

{{collapsible script|type=Parsing a PUI/XML dialog|title=with embedded Canvas/Nasal block|lang=xml|script=
<?xml version="1.0"?>
<PropertyList>
<name>fgplot</name>
<modal>false</modal>
<layout>vbox</layout>

<text>
<label>FGPlot</label>
</text>

<group>
<layout>hbox</layout>
<halign>fill</halign>
<default-padding>10</default-padding>
<empty><stretch>true</stretch></empty>

<empty><stretch>true</stretch></empty>

<canvas>
<name>fgplot</name>
<valign>fill</valign>
<halign>fill</halign>
<stretch>true</stretch>
<pref-width>600</pref-width>
<pref-height>400</pref-height>
<nasal>

<load>
<![CDATA[
# you can add your canvas-specific code here
var my_canvas = canvas.get( cmdarg() ); # this will get a handle to the parent canvas:

var root = my_canvas.createGroup();
var text = root.createChild("text")
.setText("Hello world from FGPlot v. 0.1 !")
.setTranslation(10, 30)
.setAlignment("left-top")
.setFontSize(20)
.setFont("LiberationFonts/LiberationSans-Regular.ttf")
.set("max-width", 380)
.setColor(1,0,0);

var graph = root.createChild("group");

var x_axis = graph.createChild("path", "x-axis")
.moveTo(10, 150)
.lineTo(380, 150)
.setColor(1,0,0)
.setStrokeLineWidth(3);

var y_axis = graph.createChild("path", "y-axis")
.moveTo(10, 30)
.lineTo(10, 250)
.setColor(1,0,0)
.setStrokeLineWidth(3);

var plot = graph.createChild("path", "data")
.setStrokeLineWidth(2)
.setColor(0,0,1)
.moveTo(10,150); # origin

var samples = [ # absolute coordinates
[50, 150], [100,140], [200,110], [270, 55]
];

foreach(var set; samples) {
plot.lineTo( set[0], set[1] );
}
]]>
</load>
</nasal>
</canvas>

<button>
<legend>Exit</legend>
<equal>true</equal>
<key>Esc</key>
<binding>
<command>dialog-close</command>
</binding>
</button>

<empty><stretch>true</stretch></empty>
</group>
</PropertyList>
}}

=== Supporting Translations ===
{{Stub}}
Our existing GUI is fairly simple, but it all goes through XML and the/a property tree, which is an advantage here.This was previously discussed on the issue tracker a while ago:
So with some work, anything that uses PropertyList/XML can still be localied by using "post-processing hooks", i.e. you first load the actual file (e.g. about.xml) and then load a localized version of the same file (with just the strings replaced) into the same props.Node/SGPropertyNode. Given James' work on Nasal-based fgcommands, we can trivially overwrite fgcommands like '''show-dialog''' with our own implementation (wrapping the original fgcommand, or using a custom '''show-localized-dialog''') that basically:
* load a GUI dialog like about.xml
* check if there is a matching XML file in $FG_ROOT/Translations/it/gui/dialogs/about.xml
* if so, load it into the same tree, basically replacing those original English strings

Et voila, you'll end up with a very simple localization method without having to edit any C++ code
Alternatively, we could use the include/params construct to overwrite/replace default strings with stuff from $FG_ROOT/Translations
I don't even think that it requires much in terms of Nasal, it's probably under 100 lines of code to do it this way.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=207989#p207989
|title = <nowiki> Re: Total translation of the simulator in Italian </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = May 3rd, 2014
|added = May 3rd, 2014
|script_version = 0.40
}}</ref>

$FG_ROOT/Translations contains references that are looked up by the menubar - so the menubar merely contains property references, not the strings - the translated strings are then looked up using those properties - e.g. see $FG_ROOT/Translations/en/menu.xml (?)
Next, check preferences.xml for the <intl> tag that includes Translations/locale.xml
At that point, you should understand how the existing scheme works, and how you can use the same mechanism to also localie Canvas dialogs accordingly, even without hard-coding any language into the code.

<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=292526#p292526
|title = <nowiki> Re: User language </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Aug 14th, 2016
|added = Aug 14th, 2016
|script_version = 0.40
}}</ref>

there should be some kind of /sim/intl and /locale tree somewhere in the global tree, have you checked if that's the case or not?

There should also be a vector with <lang> nodes for each supported locale.
The whole locale handling stuff is fairly old code, but I do remember that most strings read during startup are mapped that way, which is why I suggested to do a reverse lookup to obtain the information that you need, i.e the translated strings should be also available there.
And even if something should be missing all those files are PropertyList files that can be read/processed using 10 lines of Nasal code (via io.read_properties)<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=292846#p292846
|title = <nowiki> Re: User language </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Aug 20th, 2016
|added = Aug 20th, 2016
|script_version = 0.40
}}</ref>

you don't need much more than 20 lines of Nasal code to get a vector with files/directories from $FG_ROOT/Translations via the directory() API, and then use the io.read_properties() API to processs such files, and use the .getValues() method to obtain a corresponding hash that you can then traverse using a foreach() loop.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=292580#p292580
|title = <nowiki> Re: User language </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Aug 14th, 2016
|added = Aug 14th, 2016
|script_version = 0.40
}}</ref>

The safest way for frontends like fgrun/fgX and friends would be to process a file from $FG_ROOT that details possible startup options (options.xml) and simply provides a UI on top of these, so that there would be no tight coupling at all: [http://sourceforge.net/p/fgrun/feature-requests/22/ http://sourceforge.net/p/fgrun/feature-requests/22/]
options.xml and $FG_ROOT/Translations would need to be extended a little - but otherwise that could even be useful for the Phi/Qt5 efforts, i.e. a front-end agnostic mechanism for describing startup, and run-time, options that supports localiations, and that has otherwise no tight integration with the underlying binaries (i.e. no hard-coded assumptions).
Short of doing something along these lines, it is extremely likely that with the increasing plethora of FG front-ends, the functionality/features and use-cases supported by each will be more and more diverging over time.
Basically, options.xml would need to be extended to classify startup/run-time options, and to encode compatibility/exclusivity of options (think YaSim vs. JSBSim, AW vs. BW, ALS vs. Rembrandt) so that the UI front-end (Phi, Qt, Canvas, fgX, fgrun etc) would simply process an XML file and procedurally create a UI based on a PropertyList-encoded list of supported features/options and heuristics/rules.
The underlying control logic would ideally not use any custom Nasal blocks at all, but merely resort to property rules and XML state machine rules. That way, the UI would no longer matter.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=260383#p260383
|title = <nowiki> Re: New Canvas GUI </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Oct 12th, 2015
|added = Oct 12th, 2015
|script_version = 0.40
}}</ref>

=== Regression Testing ===
We can do a simple form of regression testing by adding a new dialog to $FG_ROOT/gui/dialogs called <code>pui2canvas-test.xml</code> and loading that as a self-test while executing pui2canvas.nas. This would work by rendering everything to an invisible Canvas (one with no window or dialog associated with it) and check for any runtime errors using the Nasal {{func link|call()}} API:

<syntaxhighlight lang="xml">
<?xml version="1.0"?>

<PropertyList>

<name>pui2canvas-test</name>
<modal>false</modal>
<layout>vbox</layout>

<nasal>
<open><![CDATA[
var x = 100;
# TODO: check bindings/fgcommands
]]></open>

<close><![CDATA[
if (x != 200) die("pui2canvas: Embedded Nasal broken");
]]></close>
</nasal>

<canvas>
<nasal>
<load><![CDATA[
if (x != 100) die ("pui2canvas: Embedded Nasal broken");
x = 200;
]]></load>
</nasal>
</canvas>

</PropertyList>
</syntaxhighlight>

The same thing can be accomplished by creating the dialog procedurally (in-memory) using the props.nas helpers:

<syntaxhighlight lang="nasal">
var testDlg = props.Node.new({ .... });
</syntaxhighlight>

== Procedural Dialogs ==
[[File:C172p-checklist-via-pui.png|thumb|FlightGear [[Aircraft Checklists]] [[PUI]] dialog]]
[[File:FGFS-Joystick-Info.png|thumb]]
[[File:FlightGear 2.7 - Joystick information 01.png|thumb|FlightGear PUI dialog showing joystick information]]
[[File:YZZzz7K.png|thumb|Screenshot showing [[PUI]] joystick configuration dialog]]

== Styling & Themes ==

== Layout Support ==
{{WIP}}
[[File:Pui-time-dialog.png|thumb]]
[[File:Time.png|thumb|New Time dialog in FlightGear]]
The most important layouting directive that needs to be supported is the table {{tag|layout}} - the least complex dialog to see tables at work is the gui/dialos/timeofday.xml dialog, this is a rather simple dialog with just a few static buttons and a few dynamic labels (well, the most recent version actually contains a few dropdown menus for picking a date).

<syntaxhighlight lang="nasal">var dialog = 'timeofday';
fgcommand("canvas-dialog-show", props.Node.new({'dialog-name':dialog}) );
</syntaxhighlight>

As can be seen, a typical table layout will look like this:

<syntaxhighlight lang="xml">
<group>
<layout>table</layout>
<halign>center</halign>

<text>
<row>0</row>
<col>0</col>
<halign>left</halign>
<default-padding>0</default-padding>
<label>UTC</label>
</text>
<text>
<row>0</row>
<col>1</col>
<halign>left</halign>
<default-padding>0</default-padding>
<label>00:00:00</label>
<live>true</live>
<property>/sim/time/gmt-string</property>
</text>

<text>
<row>1</row>
<col>0</col>
<halign>left</halign>
<default-padding>0</default-padding>
<label>Local</label>
</text>
<text>
<row>1</row>
<col>1</col>
<halign>left</halign>
<default-padding>0</default-padding>
<label>00:00</label>
<live>true</live>
<property>/instrumentation/clock/local-short-string</property>
</text>
</group>
</syntaxhighlight>

This means that groups with a table layout must be pre-processes to pre-allocate the corresponding Canvas layout structures (hbox/vbox).

<syntaxhighlight lang="nasal">

foreach(var child; tableGroup ) {
# get the row/col of each child
# set up vector of vbox/box layouts
}

</syntaxhighlight>

== Dialog Support ==
Table of existing PUI dialogs, detailing degree of support (missing/incomplete features).

{| class="wikitable"
! Dialog !! Description !! Status !! Notes

|-
| $FG_ROOT/gui/dialogs/about.xml || About dialog || {{Progressbar|80}} || -
|-

|-
| $FG_ROOT/gui/dialogs/scenario.xml || AI scenarios dialog || {{Progressbar|70}} || is missing support for layouting directives
|-

|-
| $FG_ROOT/gui/dialogs/view.xml || view dialog || {{Progressbar|60}} || is missing support for layouting directives
|-

|}

== Implementing missing Widgets ==
A few required PUI widgets are currently not yet implemented for Canvas, so we need to provide our own implementation. To do this, we can look at existing widgets and see how these are implemented, i.e. by looking at $FG_ROOT/Nasal/canvas/gui/widgets. All widgets inherit from the superclass in $FG_ROOT/Nasal/canvas/Widget.nas

As can be seen by looking at our WidgetFactory, we are also missing some fairly simple widgets, like the {{tag|vrule/}} and {{tag|hrule/}} widgets supported by PUI, which are fairly straightforward to implement by inheriting from the Widget superclass and wrapping OpenVG path/line drawing accordingly, honoring $FG_ROOT/Nasal/canvas/gui/DefaultStyle.nas

== Use Case: airports.xml ==

[[File:Airport-selection-dialog.png|300px|right|The new Airport Selection dialog with Canvas display of the airport]]

For the time being, {{GUI dialog|dialog=airports}} is easily one of the most sophisticated/complex dialogs to parse/process, mainly because of the following features it is using:
* table-based layouting, using property conditions to hide/show widgets
* embedded Nasal sections (open/close) that must be executed while opening/closing the dialog
* Nasal code that dynamically modifies the dialog tree prior to being created
* fgcommands that must be bound to the Nasal code in the open block
* unsupported widgets (e.g. airport-list, radio button, combo)
* an embedded Canvas with its own nasal/load section that must be bound to the Nasal/open section of the whole dialog to be functional
* PUI related fgcommands that must be dynamically patched to be mapped to their Canvas equivalents

In other words, a parser that can successfully parse/process and render {{Fgdata file|gui/dialogs/airports.xml}} can be considered to be pretty functional already, and should be easy to extend for other dialogs.

=== Coming up with an airport-list widget ===

[[File:Canvas-snippets-scrollArea-demo.png|right|Screen shot showing a Canvas ScrollArea populated with different splash screens, loaded from $FG_ROOT/Textures]]

We can use/extend the [[Canvas_Snippets#Canvas_ScrollArea|ScrollArea widget]] in $FG_ROOT/Nasal/canvas/gui/widgets/ScrollArea.nas, and simply add a vbox layout to it, with each button representing an airport - i.e. instead of the splash screens added to the ScrollArea example shown in the example on the right, we will be adding buttons to the layout, each button representing one airport:

<syntaxhighlight lang="nasal">
var vbox = canvas.VBoxLayout.new();
myCanvas.setLayout(vbox);

var scroll = canvas.gui.widgets.ScrollArea.new(root, canvas.style, {size: [96, 128]}).move(20, 100);
vbox.addItem(scroll, 1);

var scrollContent =
scroll.getContent()
.set("font", "LiberationFonts/LiberationSans-Bold.ttf")
.set("character-size", 16)
.set("alignment", "left-center");

var list = canvas.VBoxLayout.new();
scroll.setLayout(list);

var airports = findAirportsWithinRange(25, "KSFO");
# debug.dump(airports);
foreach(var apt; airports) {
var AirportButton = canvas.gui.widgets.Button.new(scrollContent, canvas.style, {})
.setText(apt.id)
.setFixedSize(50, 25);
list.addItem(AirportButton);
}
</syntaxhighlight>

[[File:Canvas-airport-list-widget-prototype.png|right|screen shot showing a simple ScrollArea-based Canvas widget for wrapping the PUI airport-list widget using ~10 lines of Nasal code]]

In its current form, this isn't even a widget yet - it is simply using the existing ScrollArea widget and adds a few buttons to it.

Bindings-wise, this is straightforward to hook up to the parser, because each button will merely have a Nasal callback that sets the corresponding PUI property:

[[File:Pui-airport-list-widget-in-canvas.png|right|airport-list widget re-implemented using Canvas ScrollArea and Buttons arranged in a VBox layout]]

Equally, this approach can be used to come up with a simple property-list equivalent.

== Coming up with a property-list ==

One of the most common hard-coded widgets implemtented in C++ are custom '''list''' widgets, namely:
* list
* property-list
* airport-list
* waypointlist
* loglist

Thus, it makes sense to provide a common Canvas widget that can be reused for all these purposes.
We can easily implement this by reusing the ScrollArea widget we have already, and by adding a vertical box layout to it with buttons/labels for each list entry.

[[File:Crude-canvas-property-parser.png|thumb|crude property-browser approximation using the pui2canvas parser (unmodified dialog), no layouts or sorting applied]]

For dialogs like the [[property browser]] (property-browser.xml), we need to implement the hard-coded property-list widget.

From the Canvas standpoint, it really doesn't matter what kind of list we're displaying - all that matters is having a container that implements a vertical scroll area, with buttons added for each entry, and a corresponding binding for applying the selected button - thus, we can adapt the airport-list code to become the foundation for arbitrary PUI list widgets.

For each button's label, we merely need to call the getPath() method for each property in the currently shown tree, and add it to the scroll area, which can be implemented using roughly 20 lines of code:

<syntaxhighlight lang="nasal">
'property-list': func(window, root, layout, node) {
var vbox = canvas.VBoxLayout.new();
layout.addItem(vbox);

var scroll = canvas.gui.widgets.ScrollArea.new(root, canvas.style, {size: [96, 128]}).move(20, 100);
vbox.addItem(scroll, 1);

var scrollContent =
scroll.getContent()
.set("font", "LiberationFonts/LiberationSans-Bold.ttf")
.set("character-size", 16)
.set("alignment", "left");

var list = canvas.VBoxLayout.new();
scroll.setLayout(list);

var updateList = func(node) {
# TODO: should add ./.. first
foreach(var n; node.getChildren() ) {
# TODO: should probably use label instead here ?
var PropertyButton = canvas.gui.widgets.Button.new(scrollContent, canvas.style, {})
.setText(n.getPath() )
.setFixedSize(200, 25);

# save the node in a closure for later use
(func() {
var n = n;

var bindings = PUI.setupBindings(window, node);
# FIXME: this needs to use the patched fgcommand bindings ... for dialog-apply etc
PropertyButton.listen("clicked", PUI.makeBindingsCallback(bindings));

PropertyButton._view._root.addEventListener("click", func() {
print("click event:",n.getPath() );
});
# this will clear the list and call the function with the selected new node
PropertyButton._view._root.addEventListener("dblclick", func() {
print("double click event",n.getPath() );
# clear list
list.clear();
updateList( n );
});
}()); # call the anonymous function

list.addItem(PropertyButton);
} # foreach child
}

updateList( props.getNode("") );

}, # property-list
</syntaxhighlight>

For that, we need a generic List widget inherited from Canvas.Widget, which can be populated with buttons.

== Source Code ==
The code shown below is fairly simple (under 300 LOC), and lacking some of the enhancements shown/discussed above (e.g. embedded Canvas support, table layouts, custom widgets etc), but it can already be used to display dialogs like view.xml, scenario.xml or about.xml - for example:

{{Caution|While standard fgcommands are likely to work "as is", most PUI related fgcommands need special treatment, which isn't implemented in the code shown below. For starters, you may want to try the about dialog, refer to the screenshots/gallery section above for other working examples}}

<syntaxhighlight lang="nasal">
fgcommand('canvas-dialog-show', props.Node.new({'dialog-name':'view'}) );
</syntaxhighlight>

{{collapsible script|type=Nasal code|title=pui2canvas.nas|intro=The following code needs to be dropped into $FG_ROOT/Nasal/pui2canvas/pui2canvas.nas
|lang=nasal|script=
# beginning of PUI namespace
var PUI = {
# static
unsupported: func(tag, what="Widget") {
print("PUI/XML ",what," not yet supported:", tag);
},
##
# call with exception handling (stub)
#

safeCall: func(codeObj, namespace=nil) {
var retval = call(codeObj, [], nil, namespace, var err=[]);
if (size(err)) {
debug.dump(err);
}
return retval;
},

##
# generator for creating callbacks used for all Nasal compilation
#
makeTagCompiler: func(codeTag, description=nil) {
if (description==nil) description = codeTag ~" block";
return func(node, namespace=nil) {
var codeSrc = node.getNode(codeTag).getValue();
return func PUI.safeCall(compile(codeSrc),namespace);
};
}, # makeTagCompiler

setupCommandBinding: func(window, node) {
var command = node.getNode("command").getValue();
if (command=="nasal") return PUI.setupScriptBinding(node);
# TODO: fgcommands relating to PUI must be dynamically patched/overridden (e.g. dialog-close)
if (contains(PUI.fgcommandPatches, command)) {
print("Most PUI related fgcommand patching not yet implemented");
# returns a patched fgcommand (Nasal callback) for the window/node
return PUI.fgcommandPatches[command](window, node);
}
# else print("Returning non-PUI fgcommand");
# standard fgcommand, wrapped in a Nasal func
return func() {
fgcommand(command, node);
};
}, # setupCommandBinding

setupScriptBinding: func(node) {
# TODO: needs to be bound to the dialogs open block
return PUI.nasalBindingCompiler(node);
}, # setupScriptBinding

# returns a vector of callback bindings (fgcommands and nasal scripts)
setupBindings: func(window, node) {
var callbacks=[];
var b=node.getChildren("binding");
foreach(var binding; b) {
append(callbacks, PUI.setupCommandBinding(window, binding));
}
return callbacks;
}, # setupBindings

makeBindingsCallback: func(bindingsVec) {
return func() {
foreach(var b; bindingsVec) {
# bindings are invoked via call to ensure that
# runtime errors don't block other bindings
# PUI.safeCall(b);
b();

} # foreach binding
} # return anonymous func
}, # makeBindingsCallback

###
# TODO remove default PUI close button based on heuristic ?

###
# TODO: Some PUI fgcommands may need to be patched/replaced dynamically
# and mapped to their Canvas equivalents - e.g. to call a window.del() destructor
fgcommandPatches: {
'dialog-close': func(window, node) {
return func window.del();
},
'dialog-apply': func(window, node) {
return func;
},
'dialog-update': func(window, node) {
return func;
},
'dialog-show': func(window, node) {
return func;
},
}, # fgcommandPatches

###
# TODO: unify node checking (vector], callback to be invoked if found
applyPUIAttributes: func(widget, layout, node) {
var width = node.getNode('pref-width');
var height = node.getNode('pref-height');
if (width!=nil and height!=nil)
widget.setFixedSize(width.getValue(), height.getValue());

# TODO: visible & enable, live
var visible = node.getNode("visible");
if (visible != nil) print("visible tag not yet supported");

var format = node.getNode('format');
if (format !=nil) {
var property=node.getNode('property').getValue();
var legend=sprintf(format.getValue(), getprop(property));
widget.setText(legend);
}
},

##
# deals with different layouts (group/frame)
# and creates a table layout using Canvas vbox/hbox layouts
LayoutFactory: {
'hbox': func(window, root, layout, node) {
var myLayout = canvas.HBoxLayout.new();
PUI.parseWidgets(window, root, myLayout, node);
layout.addItem(myLayout);
}, # hbox

'vbox': func(window, root, layout, node) {
var myLayout = canvas.VBoxLayout.new();
PUI.parseWidgets(window, root, myLayout, node);
layout.addItem(myLayout);
}, #vbox

'table': func(window, root, layout, node) {
# this requires additional work, see $FG_SRC/GUI/Layout.cxx
}, #table
}, # LayoutFactory

##
# maps PUI tags ($FG_ROOT/Docs/README.gui) to callbacks/widgets implementing the Canvas equivalent
# each widget may need access to dialog specifics, such as thee window, root group, layout and node to be processed
# thus, these are passed as args
WidgetFactory: {
'frame': func(window, root, layout, node) {
# groups and frames are equivalent
PUI.WidgetFactory.group(window, root, layout, node);
}, # frame
'group': func(window, root, layout, node) {
var mode = node.getValues().layout;
var myLayout = PUI.LayoutFactory[mode](window, root, layout, node);
}, # group

'dummy': func(window, root, layout, node) {
PUI.WidgetFactory.button(window, root, layout, node);
}, # dummy widget, adds a button
'text': func(window, root, layout, node) {
var legend = node.getNode('label').getValue();
var label = canvas.gui.widgets.Label.new(root, canvas.style, {wordWrap: 0});
label.setText(legend);
PUI.applyPUIAttributes(label, layout, node);
layout.addItem(label);
}, # text

'button': func(window, root, layout, node) {
var legend = node.getNode('legend').getValue();
var button = canvas.gui.widgets.Button.new(root, canvas.style, {})
.setText(legend);
layout.addItem(button);
PUI.applyPUIAttributes(button, layout, node);
# set up bindings: (should be moved to applyPUI*)
var bindings = PUI.setupBindings(window, node);
button.listen("clicked", PUI.makeBindingsCallback(bindings));
}, # button
'input': func(window, root, layout, node) {
var input = canvas.gui.widgets.LineEdit.new(root, canvas.style, {});
PUI.applyPUIAttributes(input, layout, node);
layout.addItem(input);
}, # input
'checkbox': func(window, root, layout, node) {
var hbox=canvas.HBoxLayout.new();
var checkbox = canvas.gui.widgets.CheckBox.new(root, canvas.style, {});
hbox.addItem(checkbox);
# add a label
PUI.WidgetFactory.text(window, root, hbox, node);
layout.addItem(hbox);
}, # checkbox
'radio': func(window, root, layout, node) {
}, # radio
'combo': func(window, root, layout, node) {
PUI.unsupported("combo");
}, # combo
'list': func(window, root, layout, node) {
}, # list
'airport-list': func(window, root, layout, node) {
}, # airport-list
'property-list': func(window, root, layout, node) {
PUI.WidgetFactory.list(window, root, layout, node);
}, # property-list
'waypointlist': func(window, root, layout, node) {
}, # waypointlist
'select': func(window, root, layout, node) {
}, # select
'slider':func(window, root, layout, node) {
}, # slider
'dial': func(window, root, layout, node) {
}, # dial
'textbox':func(window, root, layout, node) {
# TODO: should be list wrapping a label ...
PUI.WidgetFactory.list(window, root, layout, node);
}, # textbox
'hrule': func(window, root, layout, node) {
PUI.unsupported("hrule");
}, #hrule
'vrule': func(window, root, layout, node) {
PUI.unsupported("vrule");
}, # vrule
'canvas': func(window, root, layout, node) {
}, # canvas
'map': func(window, root, layout, node) {
# must be mapped to a Canvas that instantiates a MapStructure map
}, # map
'loglist': func(window, root, layout, node) {
die("loglist widget cannot be reimplemented due to missing C++ hooks: logstream");
}, # loglist
'empty': func(window, root, layout, node) {
layout.addStretch(1);
}, # empty

}, # WidgetFactory

parseWidgets: func(window, root, layout, node) {
# this is a very simple parser
# it will check the whole XML tree against the WidgetFactory hash
# which is why some tags get wrongly reported as unsupported, despite being honored elsewhere ...
foreach(var tag; node.getChildren()) {
var t=tag.getName();
# see if the tag has an associated callback in the WidgetFactory hash
if(contains(PUI.WidgetFactory, t)) {
# if there is a matching callback, look it up and call it passing the current window, root, layout, tag
PUI.WidgetFactory[t](window, root, layout, tag);
# TODO: applyPUIAttributes
# TODO: addItem/layout here
# TODO: process bindings
}
else PUI.unsupported(t, "Tag"); # not quite correct for top-level layout tags
} # foreach tag
},

showDialog: func(node) {
var filename = node.getNode('dialog-name').getValue() or die("Missing dialog file name");
# append .xml suffix:
filename ~= ".xml";

# build path relative to $FG_ROOT
var path = getprop("/sim/fg-root")~"/gui/dialogs/"~filename;

print("Custom PUI/Canvas parser for dialog:", filename);
# load the dialog from the base package
var dlgNode = io.read_properties(path);

# turn the property node into a hash
dlgHash = dlgNode.getValues();

# create a Canvas window
var window = canvas.Window.new([640,480],"dialog").set('title',dlgHash.name);
# adding a canvas to the new window and setting up background colors/transparency
var myCanvas = window.createCanvas().set("background", canvas.style.getColor("bg_color"));

# creating the top-level/root group which will contain all other elements/group
var root = myCanvas.createGroup();

# determine/set top-level layout
var layoutMode = dlgHash.layout;
var topLevelLayout = (layoutMode=='vbox')?canvas.VBoxLayout.new() : canvas.HBoxLayout.new();
myCanvas.setLayout(topLevelLayout);

var namespace = {cmdarg: func dlgNode};
if(dlgNode.getNode("nasal/open")!=nil) {
var cb=PUI.nasalOpenCompiler(dlgNode, namespace); # compile
cb(); # and call
}

window.del = func() {
var namespace = closure(cb);
if(dlgNode.getNode("nasal/close")!=nil) {
var close=PUI.nasalCloseCompiler(dlgNode, namespace); # invoke Nasal/close block
#close=bind(close, namespace);
close();
}
# call the original dtor
call(canvas.Window.del, [], window, var err=[]);
}

# http://wiki.flightgear.org/Built-in_Profiler#Nasal
fgcommand("profiler-start", props.Node.new({filename:"pui2canvas-"~filename}));
PUI.parseWidgets(window:window, root:root, layout:topLevelLayout, node:dlgNode);
fgcommand("profiler-stop");

}, # showDialog

}; # end of PUI namespace

###
# create a handful of tag compiler instances for different purposes
#
# helper to compile bindings
PUI.nasalBindingCompiler = PUI.makeTagCompiler(codeTag: "script");

# helper to compile & call embedded blocks
PUI.nasalOpenCompiler = PUI.makeTagCompiler(codeTag:"nasal/open");
PUI.nasalCloseCompiler = PUI.makeTagCompiler(codeTag:"nasal/close");
PUI.canvasLoadCompiler = PUI.makeTagCompiler(codeTag:"canvas/load");
##
# finally, register a new fgcommand for turning PUI dialogs into Canvas widgets
addcommand("canvas-dialog-show", PUI.showDialog);
print("pui2canvas module loaded, canvas-dialog-show command registered");

}}

== PUI Findings ==
The way PUI is used, and "enhanced" through tons of custom Nasal code embedded in PUI/XML dialogs, makes it obvious that it would be a good idea not just to support legacy dialogs, but to also introduce support for specialized widgets to get rid of all the Nasal spaghetti code, especially:

* airport-list (airports.xml)
* airport-info (airports.xml)
* pilot-list (multiplayer)

...

Ideally, these would be gradually re-implemented using a simple Canvas wrapper, so that the corresponding Nasal/PUI markup can be phased out in favor of dedicated widgets.

== Canvas Menubar ==
{{Main article|Howto:Making a Canvas Menubar}}

== Preliminary Findings (core Canvas/C++) ==
Writing a parser in Nasal to convert PUI/XML PropertyList-encoded XML to Canvas widgets/dialogs is possible, and not even very involved, however there also some obvious issues/challenges currently - because the underlying C++ code was never designed with this use-case in mind.

This section is intended to gather data points and conclusions to identify bottlenecks and potential opportunities for optimizing Canvas, unrelated to the UI use-case, but with a focus on shaping APIs that may be useful for similar efforts, such as e.g. porting the HUD/2D panels code to use a similar approach:

* for testing purposes it would make sense to come up with a dialog showing an embedded Canvas to open/run arbitrary dialogs on demand (including aircraft specific ones)
* at least on old hardware, instantiating a Canvas-based PUI dialog is a fairly noticeable process that may take 50-120ms
* wrapping key props.nas APIs via cppbind would certainly help speed-up dialog parsing/processing
* it may make sense to investigate adding a widget/dialog cache (parts of this could be in Nasal, others would need C++ changes)
* using vbox/hbox layouts to emulate tables is unnecessarily heavy, i.e. causing tons of property/Nasal overhead - adding a Table layout (and exposing some related attributes, as per README.layout) would make sense and should alleviate most layouting overhead (most PUI dialogs make heavy use of tables).
* to process PUI/XML layouts, it would be much easier not to go through Nasal at all, and expose layouts at the property level directly, e.g. by treating a layout as a canvas element and automatically aligning child nodes according to the parent layout (vbox,hbox, table)
* scrolling/event-handling seems unnecessarily slow/unresponsive (need to investigate)
* animations should not be handled using timers or listeners, but by using OSG data structures directly
* Equally, README.gui covers a few common use-cases, such as "live" properties, and printf-style formatting - as well as using properties as input/output for a widget. Mapping those concepts directly to Canvas using C++ code, should make most related Nasal code unnecessary. Obviously, with Canvas everything is "live" in some way - but we still need to map Nasal callbacks to implement live/printf-style behavior, while that could also be done using property flags. So that Nasal listeners/polling can be avoided to emulate PUI behavior, i.e. by encoding update semantics (polling per frame, update-on-change etc)
* For the same reason it would make sense to expose the SGCondition code using cppbind, so that the props.nas helpers can be circumvented using native code.
* while there are a number of PUI widgets that are not currently implemented for Canvas, those are fairly straightforward to provide. However, there also is a handful of undocumented custom PUI widgets that need to be ported-some of which are using data that is currently not accessible, e.g. the loglist widget (Nasal Console, shaders/terrasync), which means that the [[SG LOG|logstream APIs]] would need to be exposed via [[Nasal/CppBind]]

== References ==
{{Appendix}}
{{Search|keywords=pui2canvas}}

[[Category:Canvas GUI]]

PUI

2023-04-21T10:40:53Z

Hooray: /* History */

{{Feature to be removed|version=2023.3|reason=[[Plib]]/PUI is to be removed and replaced by a [[Canvas widget matrix|Canvas/Nasal based solution]] to help improve compatibility with [[OSG]] 3.6+ and [[OpenGL]] 4.x ([[Core Profile support|OpenGL Core Profile]], see [[2022.X Release plan]] ) and improve performance by [[Unifying the 2D rendering backend via canvas|phasing out legacy OpenGL code]]. Therefore, people should be careful when extending the '''PUI''' based legacy GUI engine<ref>https://sourceforge.net/p/flightgear/mailman/message/34921495/</ref><ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35157325/
|title = <nowiki> Re: [Flightgear-devel] GUI options (Was: Aircraft center) </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jun 14th, 2016
|added = Jun 14th, 2016
|script_version = 0.40
}}</ref> and coordinate any related work with the devel mailing list first-this applies particularly to adding any [[Template:PUI_widget|additional hard-coded PUI widgets]]. }}
[[File:Exit.png|thumb|FlightGear GUI dialog (exit.xml)stored in $FG_ROOT/gui/dialogs]]
{{GUI Navbar}}

[[File:Custom-autopilot-dialog.png|right|200px]]
[[PUI]] is the standard GUI engine used in FlightGear, it is part of [[PLIB]] and is using raw, fixed-pipeline, [[OpenGL]] code internally (no [[OpenSceneGraph]]). As of mid 2021, FlightGear is in the process of working towards adopting the OpenGL Core Profile, this means that [[PUI]] is causing trouble and needs to be replaced/disabled or ported.

PUI provides a fairly basic, but robust, set of widgets. PUI is also used for rendering the [[Menubar]].

FlightGear uses a GUI widget set that is implemented on top of raw (legacy) [[OpenGL]]. This has many advantages from a portability standpoint and from the standpoint of integrating with window systems. [[PUI]] doesn't have every feature under the sun, but it was never meant to. It's relatively small, lean, mean, and written on top of [[OpenGL]] which makes life *much* easier for us.

[[PUI]] already is a separate distinct library within Plib. It depends on some central utility stuff, but that's about it. So it is pretty stripped down and separate already.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg26011.html</ref>

We are to some extent hamstrung by the rather old GUI toolkit we use. However, replacing that is going to be non-trivial, and it would affect not just the core GUI but also all the dialog boxes that have been set up for particular aircraft.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg25985.html</ref>

Flightgear can look amazing when you use the HDR pipeline. We absolutely need this to stay relevant. The problem is that HDR is not compatible with OpenGL1 PUI. Work on getting rid of PUI has been going on for over a decade (longer than it took to implement it).<ref>https://sourceforge.net/p/flightgear/mailman/message/37727346/</ref>

[[File:menubar2.jpg|517px]]

== Replacement status ==
{{See also|FlightGear_and_OpenGL_ES#Example:_disabling_PUI}}

{{Note| Update 09/2022: The PUI replacement [[QtQuick_use_in_FlightGear#Background|was going to be Qt]] but it started to get very complicated with changes in Qt 5.15 + Qt 6, so James is going with a more light-weight Canvas based approach now.

Qt added support for Vulkan / Metal / D3D starting in 5.15, but FlightGear / OpenSceneGraph can’t support those, so integrating the two renderers went from being ‘complicated but ok’ to ‘very very complicated’.

So now James is going with something much more lightweight using some C++ compatibility code, some Nasal for styling and the existing [[Canvas widgets|Canvas widget rendering]] from Thomas Geymayer (TheTom) with [[Canvas Widget Matrix|some extensions and additions]], based on the [[Howto:Processing_legacy_PUI_dialogs_using_Canvas#Original_Discussion|plans originally discussed when the Canvas GUI system was added to FlightGear]]: some pieces are in FlightGear & FGData already.

James has basic dialogs working okay but not the more complex ones and everything looks kind of ugly, he needs to improve the visual look before he shares screenshots to avoid everyone freaking out :) The disadvantage of this approach is James is far from expert at creating visual appearances this way, so it’s kind on unrewarding and slow for him. If someone likes messing with CSS-type styling, border-images and hover-states, ping him since we could probably move things also faster <ref>https://sourceforge.net/p/flightgear/mailman/message/37701750/</ref>}}

=== Motivation ===
{{Main article|Core Profile support}}

The bigger issue here is we need to ditch [[PUI]] (which is in progress) and some OpenGL 1.0 code (HUD, 2D panels especially - can be #ifdef for now) so we can enable Core profile on Mac - since Mac 4.x support (we only hit about 4.3 alas, but with some extensions to get in sight of 4.5) is Core profile only, no Compatability mode.

Improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, many people are convinced PUI needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

While most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so [using Qt5] would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

== Canvas Emulation ==
{{See also|Canvas widget matrix}}
'''Last updated: 04/2023 <ref>https://sourceforge.net/p/flightgear/mailman/message/37805054/</ref>
'''
=== Status ===
As of 01/2023, the replacement for PUI is making good progress<ref>https://sourceforge.net/p/flightgear/mailman/message/37765706/</ref>.

In February 2022, James reported having something in progress locally, and that should even be something we can try in March/April 2022. Hopefully that’s quick enough, knowing it has been a long time coming.<ref>https://sourceforge.net/p/flightgear/mailman/message/37606439/</ref>

There's now an XML to Nasal bridge, to keep PUI dialogs working (Disabled by a CMake option)
This is implemented on top of the [[Canvas]] system.

This builds equivalent C++ objects to what the [[PUI]] dialogs build, with properties exposed to Nasal.
Peer objects are created by Nasal [[callbacks]], which can implement the various dialog functions needed to keep compatibility, especially the [[#Background|‘update’ and ‘apply’ hooks]].<ref>https://sourceforge.net/p/flightgear/flightgear/ci/cbd5ef9e7b8f433dbc1ba97bae7d7cfc894e7cef/</ref>

{{Note|The PUI Compatible Canvas GUI is a compile time option: Use the following [[Building using CMake|cmake option]] to enable this code: {{CMake Build Option|option=ENABLE_PUICOMPAT|default=ON|description=This requires latest SG/FG AND FGDATA}}. But this is all highly fluid and most of it really developer only. At one point they will become default or be accessible in the launcher.<ref>https://sourceforge.net/p/flightgear/mailman/message/37834004/</ref>

If you compiled with PUICompatibility enabled, but still don't see any dialogs - only the menubar, you might need to enable the GUI module in defaults.xml<ref>https://sourceforge.net/p/flightgear/mailman/message/37833149/</ref>}}

The new Compatibility files can now be found in $FG_SRC/GUI:

* {{flightgear file|src/GUI/FGPUICompatDialog.cxx }}
* {{flightgear file|src/GUI/FGPUICompatDialog.hxx }}
* {{flightgear file|src/GUI/PUICompatObject.cxx }}

01/2023: James is slowly working on creating the pop-up menu and combo-box widgets [...]

One of the major things slowing down James' work on the popup-menu and combo box is time to restart the simulator for each change, he is looking for some solution to re-load the widget Nasal code independently. <ref><https://sourceforge.net/p/flightgear/mailman/message/37756183/</ref>

James has done about 75% (hah!) of the C++ work to enable live reloading of modules this way, but unfortunately there are some code paths that would become crashy if you use the feature for the Canvas: because it would reference the ‘old’ (pre-reload) Nasal code, and not the new one, and therefore you’d get a weird mix of old and new, and then just crash the sim. To fix it properly I need to track down those places that store a reference to Canvas and give them a re-init method, so we don’t keep the stale references.

The general non-fun-ness of that kind of debugging is James has been making such slow progress on my PUI replacement widgets recently <ref>https://sourceforge.net/p/flightgear/mailman/message/37756263/</ref>

=== Todo ===
Nothing in particular: help debugging the grid layout (which is in simgear) would be good. For now, you could create a grid layout manually using some Nasal.

For the menubar, we need to expose the C++ data to Nasal: we need a FGCompatMenuBar (alongisde FGPUIMenuBar) implementing FGMenubar which calls _createMenuObject in MenuBar.nas, using the same way I lookup and call _createDialogPeer in XMLDialog.nas

(Make sure you don’t break the macOS native menubar in the process!)

You can probably pass a wrapped SGpropertyNode into this, and then fill in the stubs in that file to use the Menu widgets Frederic has written.

Global menu keybindings won’t worry but don’t touch that, I have a separate plan for it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37805736/</ref>

As of 04/2023, remaining items on the todo list are: <ref>https://sourceforge.net/p/flightgear/mailman/message/37805060/</ref>

* Grid layout
** GridLayout needs debugged: After this, the basic UI is usable, would probably make it a switchable option on ‘next’ (I can already use the simulator with the new UI today, but all the sizes are off in the grid layouts which we use everywhere)

* list
* table (and tree ?) models corresponding views
* waypoint list
* Re-write the waypoint list and airport dialog to work again (since these use custom widgets):
** log list
** airport-list equivalents
* Nasal access to the menu i18n functions
* selection support for single- and multi-line text (which is being worked on -> CanvasPangoText)
* Keyboard shortcut handling, although this is not really a PUI vs replacement issue, to me we should handle UI shortcuts in the same was normal keyboard.xml shortcuts
** this previously worked because PUI got ‘first chance’ at handling key input. But we always had duplication between keyboard.xml and other places, so I would rather standardise on keyboard.xml, but allow a UI element to set a scope for shortcuts. (So that Copy/paste shortcuts etc can work in a text input, at least … but probably some other standard ones) <ref>https://sourceforge.net/p/flightgear/mailman/message/37805188/</ref>
* Ensure all the places which use the PUI combo-box and list-widget work : there’s a few of these.

The CanvasPangoText stuff is needed but we can perfectly well run the UI on next without it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37805176/</ref>

=== Parser ===
{{Main article|pui2canvas}}
The corresponding Nasal/Canvas module to dynamically "translate" legacy PUI/XML dialogs into Canvas dialogs (at runtime), is to be found in {{fgdata file|Nasal/gui/XMLDialog.nas}} <ref>https://sourceforge.net/p/flightgear/fgdata/ci/fe7c87b21a69f88ddb87d89453c48d12b69660e2/</ref>

=== Widgets ===
{{Main article|Howto:Creating a Canvas GUI Widget}}

It’s split between Simgear (see classes with widget / layout in the name) and in FGData. (Eg widgets/Button.nas) To be able to use the existing dialog XML files un-modified (which is a design goal), James is extending the widget types with many additional ones (eg PUI has slider, dial, combo-box, checkbox, all of which need to be created, see [[Canvas widget matrix]].

This is about 30% done and is the bit he's very slow at). Thomas’s canvas widgets have a very good separation of API + state from appearance, so all styling is in its own file, and James is being very strict about maintaining this separation, so we also retain the re-styling feature of the PUI UI, which many people also rely on. This does make the process of adding new widgets more complex, however.

{{See also|Canvas widgets}}

=== Layouting ===
The other thing is to preserve all the layouting: James has added a grid layout to Simgear, since that is supported by the existing PUI code (even though the layouts are not actually part of PUI itself). The problem is getting the sizing / hinting of all the widgets to match the PUI values, so that dialogs look approximately the same under the new UI as they did with PUI; again this a design goal so that all existing dialogs in aircraft and add-ons, which we can’t update, continue to work and be usable. Debugging that is also proving quite tricky, since there’s all kinds of hard-coded assumptions built into PUI widgets about pixels, font-sizes etc which are not true in the new system.<ref>https://sourceforge.net/p/flightgear/mailman/message/37701792/</ref>

== Background ==
In FlightGear, PUI dialogs are standard [[PropertyList XML File]]s that are stored in $FG_ROOT/gui/dialogs, they can contain the widgets mentioned in {{readme file|gui}}, using a simple layout engine discussed in {{readme file|layout}}, and bindings using a combination of so called fgcommands operating on properties (see {{readme file|commands}}) and custom [[Nasal]] (FlightGear scripting) code.

In addition, each PUI/XML dialog may contain Nasal script sections that are executed when opening/closing the dialog, a feature which is commonly used for procedurally creating/updating widgets using the [[Nasal_library#cmdarg.28.29|cmdarg() API]], which allows the dialog tree to be traversed and manipulated prior to the dialog being rendered.
Widgets can be conditionally hidden/shown using a wrapper for [[Conditions|SGCondition]] in [[Nasal_library/props|props.nas]]
The <code>canvas</code> widget also supports its own embedded Nasal code section to execute arbitrary widget specific Nasal code upon opening/closing the dialog/widget.

PUI/XML dialogs can be loaded, dynamically created, updated and closed using a handful of fgcommands:
* {{fgcommand|dialog-new}}
* {{fgcommand|dialog-show}}
* {{fgcommand|dialog-update}}
* {{fgcommand|dialog-apply}}
* {{fgcommand|dialog-close}}

PUI related OpenGL code is particularly infamous for causing rendering artifacts for people on AMD/ATI and Intel hardware (especially in combination with certain fonts/styles and [[Effects|effects]]/[[Shaders|shaders]]), see {{Issue|2213}}.

PUI is also known to affect rendering performance quite significantly (see {{search |keywords=anthrax+gui}}), while also preventing FlightGear from using a more recent version of OpenGL<ref>http://sourceforge.net/p/flightgear/mailman/message/34532040/</ref><ref>http://forum.flightgear.org/viewtopic.php?f=71&t=24046</ref>.

However, improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Besides, while most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

But given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, graphics folks are also convinced it needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

In addition, [[OpenSceneGraph]] (OSG) can obviously not help optimize any PUI related GL code and PUI widgets are generally considered to be pretty archaic and not easy to extend<ref>http://sourceforge.net/p/flightgear/mailman/message/26832164/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587120/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587272/</ref>.

{{Note|We use the GUI code from PLIB, which doesn't know anything about OSG. See the SGPuDrawable class in $FG_SRC/Viewer/renderer.cxx for the implementation. The one catch is that OSG has a strong notion of separation between the update of a "scene" and its rendering, and that might not play well with arbitrary existing OpenGL code. }}

As of late 2015, there is heavy activity towards providing alternatives to a PUI-based UI:
* [[Integrated Web GUI]] (external, browser-based - fully asynchronous)
* [[Howto:Processing legacy PUI dialogs using Canvas]] (internal, using the [[Canvas]] system and a simple [[Nasal]] parser to deal with existing PUI/XML dialogs)

<gallery mode="packed">
Early-Phi-screen shot.PNG|Screenshot showing [[Phi]]
About-dialog-rendered-by-canvas.png|Screenshot showing a dialog rendered by the [[Howto:Processing legacy PUI dialogs using Canvas|pui2canvas parser]]
</gallery>

== History ==
{{See also|QtQuick use in FlightGear}}
{{Caution|This is merely kept for future reference, many of the ideas discussed below have become obsolete as of 09/2022, if in doubt, please get in touch via devel-list.}}
=== 2021 ===
In early 2021, James did a brief evaluation of [https://github.com/ocornut/imgui ImGUI] as a possibility - he's also evaluating it in some projects at his day job.

The API is interesting if you’re starting from scratch and only exclusively in C++, but it’s not a great fit for how we define GUIs in FG (via [[XML]]/[[Nasal]]): there is no back door that he could find, to access the persistent state of the GUI, or build it up in a data-driven way. So making a mapping to keep our existing GUI XML working (and updating correctly) becomes a bit of a chore.<ref>https://sourceforge.net/p/flightgear/mailman/message/37295586/</ref>

Pretty much all of the FlightGear GUI is defined in XML space, except for a few oddments. Let’s say 95% at this point.

Additionally, even if we were to change that for the core sim (and James' current plan is to keep the XML syntax and just extend it), the installed base of '''aircraft''' ship their own XML dialogs (eg., replacing the autopilot dialog with a custom one, or just adding their own aircraft-specific helper controls for doors / lights / cargo / whatever). So even if we found the most sublimely beautiful, intuitive, compact GUI description language in the world, we have to keep the XML syntax working as-is, for the foreseeable future.

Given this, James' intention is to replace the output side [[PUI]] but keep the front-end side (XML / properties / bindings) unchanged, and therefore backwards compatible, and simply add some new types / options / widget types going forward. This will mean we still have to deal with the slightly cumbersome XML+Nasal syntax, but, well, it’s not *that* cumbersome. <ref>https://sourceforge.net/p/flightgear/mailman/message/37296280/</ref>

In mid 2021, James reported that he is working on some ‘PUICompat’ classes which hold/own/represent the GUI state in C++, but which can be used with [[Nasal/CppBind|Nasal CppBind]]. And of course we could indeed expose those later on. <ref>https://sourceforge.net/p/flightgear/mailman/message/37297727/</ref>

In July 2021, James suggested not to worry about the existing GUI code, it’s going in the bin.<ref>https://sourceforge.net/p/flightgear/mailman/message/37325905/</ref>

For the time being, the in-sim GUi can’t do Unicode yet, but James is working on it, hopefully available soon.<ref>https://sourceforge.net/p/flightgear/mailman/message/37328200/</ref>
Also, the in-sim menubar will change with the new GUI, *and* we use a native menubar on macOS. Until James replaces the PUI fonts we can’t use Unicode symbols. So, will have to come back to it once the new GUI is merged.<ref>https://sourceforge.net/p/flightgear/mailman/message/37327237/</ref>

=== 2020 ===
As of 03/2020, the PLIB replacement was reported to be in the backlog <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36951255/
|title = <nowiki>Re: [Flightgear-devel] C++ and/or OSG question </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Mar 18th, 2020
|added = Mar 18th, 2020
|script_version = 0.50
}}</ref>.

With PLIB replacement work likely being re-scheduled for [[Post FlightGear 2020.2 LTS changes]] <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36985375/
|title = <nowiki>Re: [Flightgear-devel] Working Group Proposal - Boost and PLIB replacement - Delegation and Teamwork </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = April 18th, 2020
|added = April 18th, 2020
|script_version = 1.10
}}</ref>.

In 08/2020, James stated that he was still working (exceptionally slowly!) on replacing PUI (as part of removing legacy OpenGL code (PUI, HUD, 2d panels, porting Canvas away form ShivaVG), so we can switch to Vulkan/VSG at some point (ideally at some point before Apple turn off OpenGL support…)), and that he doesn't think /any/ of us *want* to be working on these features particularly, but projects like these need to be done before anyone can have fun with VSG or Vulkan (personally James would be very enthusiastic about working on VSG support (being on macOS, I also have the most to lose / gain from it)). Sometimes that’s just how it goes. Equally they will all benefit the project ultimately, but the payoff both for the individual and the project is very drawn out. <ref>https://sourceforge.net/p/flightgear/mailman/message/37077158/</ref>

In 10/2020, the estimation is that PUI should be going away really ‘soon’, the replacement code is already in next / 2020.2. (There’s no plan to actually /use/ the new UI code in 2020.2, but if the bugs in it prove simple, we could actually turn it for specific dialog: it seems very unlikely this makes sense for a stable release however)<ref>https://sourceforge.net/p/flightgear/mailman/message/37123818/</ref>

The fixed-function removal, is actively in hand (Gaetan is working on the 2D panel part, and James is going to focus on PUI in the rest of 2020). James hopes that means next year he can focus on Vulkan, or at least, using OSG as if /were/ VSG, so the migration in a year or two when VSG is stable, is not so painful.<ref>https://sourceforge.net/p/flightgear/mailman/message/37129098/</ref>

The PUI UI and replacement can co-exist in the same build (they already do, effectively.<ref>https://sourceforge.net/p/flightgear/mailman/message/37131297/</ref>

In 11/2020, James suggested not to worry about details such as PUI styling/theming etc: we’re not making such changes for the LTS, and PUI should be gone before the next release.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142225/</ref> Also, he recommended (to everyone) to stop touching GUI stuff for a few weeks, as he's about to turn it all on its head.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142356/</ref>

=== 2019 ===
The new GUI has been incubating for a few years, but there's apparently been a lot of progress as of 10/2019.

It is likely the new GUI will be a user opt-in feature - at least initially. The sunset of the PLIB library _could_ happen relatively soon, but
people will need to see the new GUI and react to it before we could commit to PLIB removal <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36784489/
|title = <nowiki>Re: [Flightgear-devel] in Flightgear/Simgear C++ Code: What needs Doing? What are YOU Doing? What would you do if you had the time? </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Oct 14th, 2019
|added = Oct 14th, 2019
|script_version = 0.50
}}</ref>.

In 02/2019, James stated that the new UI is coming quite soon. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36589420/
|title = <nowiki> Re: [Flightgear-devel] Lagging </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Feb 17th, 2019
|added = Feb 17th, 2019
|script_version = 0.40
}}</ref>

=== 2018 ===
{{See also|QtQuick use in FlightGear}}

According to James, we have to accept that changes like testing or making [[PUI]] a modular thing or moving the JS code tend to have an immediate pain for some people (because strange stuff gets broken, and takes some time to get fixed), whereas the payoff in terms of improved joystick handling or replacing the UI or testing of all subsystems will take some months or years to be felt.<ref>https://sourceforge.net/p/flightgear/mailman/message/36323240/</ref>

James said he was in the middle of porting the launcher’s final tab (location) to the new UI scheme, once that’s done he will start sketching out the ‘in sim’ settings UI using the same pieces. He’ll send a request for contributions around about that in the next three-four weeks, once he has enough templates & examples that there is a clear pattern to follow.<ref>https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/2d10f16c-ddc8-07f3-07e7-eca2a0a0d55f%40zaretto.com/#msg36293586</ref>

James announced that the launcher is now feature complete with the QtQuick UI, he’ll keep making bug-fixes of course as people report them, but my todo list for the core features is now done<ref>https://sourceforge.net/p/flightgear/mailman/message/36355833/</ref>.

=== 2017 ===

In 10/2017, James said he was getting really close to having the PUI replacement UI suitable for beta-testing.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36067646/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 7th, 2017
|added = Oct 7th, 2017
|script_version = 0.40
}}</ref>

Originally, James was hoping to land the PUI replacement GUI in the last dev cycle in 2017 (at least as a proof-of-concept, probably not as the default UI), so wouldn’t expend lots of effort on things like collapsible sections which might be a lot of work with the current PUI/Canvas approaches, but are trivial with the new [[QtQuick use in FlightGear|QtQuick based UI scheme]].<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36059822/
|title = <nowiki> Re: [Flightgear-devel] Canvas MapLayer for OpenStreetMap, OpenAIP,
VFR Sectionals </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 1st, 2017
|added = Oct 1st, 2017
|script_version = 0.40
}}</ref>

Once the basic new UI is in place we can experiment with different re-arrangements easily, without being limited by PUI. (James expects PUI to live on as the default / alternate UI while this happens)<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36061229/
|title = <nowiki> Re: [Flightgear-devel] FGFS macOS Menubar </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 2nd, 2017
|added = Oct 2nd, 2017
|script_version = 0.40
}}</ref>

Technically, this entails replacing dialog.cxx with some code which builds up some special ‘PUI-Emulation’ QtQuick controls, so that existing dialogs (especially from Aircraft) continue to work. This mode will look somewhat ugly but hopefully no more ugly than PUI! And it helps that the set of widgets we have in PUI is limited, and the ‘tricky’ widgets (map, scrolling list, etc) are in the dialogs will will replace with new ones first.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068767/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

This PUI emulation isn't going to use any code from PLIB<ref>https://sourceforge.net/p/flightgear/mailman/message/36985303/</ref>, so what will remain from it in FG afterwards will be the FNT and JS components (reworked).<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068817/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> Florent Rougon </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

=== 2016 ===
We need to explore if Qt Quick or widgets is the better way to go, with a preference towards Qt Quick, since it will allow things closer to current PUI (semi-transparent widgets on top of the 3D content). It still allows creating separate windows too (Erik’s use case), but means we get consistent, custom theming on all platforms, since standard desktop look is not so nice for a flight-sim.

James intention is to make a QML-hosting OSG-drawable, and add this as a concept in Qt-enabled builds, then port some PUI dialogs to it, and see how easy / painful the process is. Hell create some QObjects which expose commands and the property tree and Nasal.

This has the advantage of not touching the OSG window at all, QtQuick simply provides some additional OpenGL rendering on top, which we pass events to - pretty much exactly the same as what we already do for PUI, and hopefully can co-exist with it. James got this working in a local OSG tree in a standalone demo, but that’s based on osgQt - he wants to see if he can make it work on a normal, non-Qt OSG window inside FlightGear.<ref>https://sourceforge.net/p/flightgear/mailman/message/35156051/</ref>

The idea is to host an XML dialog (Currently done with PUI) from Qt also. The question is if that can be done keeping ‘source compatibility’ exactly with the current UI XML and Nasal interface. It probably can be, but many of the PUI widgets have really ugly APIs, especially for combo-boxes, drop-down menus and scrolling lists, where it makes sense to map a Nasal class to a Qt ItemModel, which would be more elegant and easy to work with in both Nasal and integrate on the Qt side. But obviously would mean changing the dialog sources.

Of course, aircraft dialogs tend to be simpler, and not use the more complex PUI widgets, precisely for reasons like this, but that’s a limitation it would be best to remove.<ref>https://sourceforge.net/p/flightgear/mailman/message/35155721/</ref>


== References ==
{{Appendix}}

[[Category:PUI| ]]
[[Category:Rendering roadblocks]]

Template:Current UI

2023-04-21T10:16:14Z

Hooray:

<includeonly>
[[PUI]]
</includeonly>
<noinclude>
{{Stub}}
This template is used to display the name of the GUI toolkit currently in use (either PUI or CUI), based on the current date and/or latest software version.
Usage:

{{Current UI
| latest_version = X.Y.Z
| pui_name = Picospic User Interface
| cui_name = Canvas User Interface
}}
</noinclude>

Template:Current UI

2023-04-21T10:12:39Z

Hooray:

<includeonly>
{{#ifexpr: {{CURRENTDATE}} > {{#time: Y-m-d | {{#if: {{{latest_version|}}} | {{{latest_version}}} | 2050-01-01 }}}}
| {{#if: {{{cui_name|}}} | {{{cui_name}}} | CUI }}
| {{#if: {{{pui_name|}}} | {{{pui_name}}} | PUI }}
}}
</includeonly>
<noinclude>
{{Stub}}
This template is used to display the name of the GUI toolkit currently in use (either PUI or CUI), based on the current date and/or latest software version.
Usage:

{{Current UI
| latest_version = X.Y.Z
| pui_name = Picospic User Interface
| cui_name = Canvas User Interface
}}
</noinclude>

Template:Current UI

2023-04-21T10:12:22Z

Hooray: going to be used to update all occurences of PUI on the wiki

<includeonly>
{{#ifexpr: {{CURRENTDATE}} > {{#time: Y-m-d | {{#if: {{{latest_version|}}} | {{{latest_version}}} | 2050-01-01 }}}}
| {{#if: {{{cui_name|}}} | {{{cui_name}}} | CUI }}
| {{#if: {{{pui_name|}}} | {{{pui_name}}} | PUI }}
}}
</includeonly>
<noinclude>
{{Stub}}
This template is used to display the name of the GUI toolkit currently in use (either PUI or CUI), based on the current date and/or latest software version.
Usage:

{{UI
| latest_version = X.Y.Z
| pui_name = Picospic User Interface
| cui_name = Canvas User Interface
}}
</noinclude>

PUI

2023-04-21T09:53:25Z

Hooray: /* Replacement status */

{{Feature to be removed|version=2023.3|reason=[[Plib]]/PUI is to be removed and replaced by a [[Canvas widget matrix|Canvas/Nasal based solution]] to help improve compatibility with [[OSG]] 3.6+ and [[OpenGL]] 4.x ([[Core Profile support|OpenGL Core Profile]], see [[2022.X Release plan]] ) and improve performance by [[Unifying the 2D rendering backend via canvas|phasing out legacy OpenGL code]]. Therefore, people should be careful when extending the '''PUI''' based legacy GUI engine<ref>https://sourceforge.net/p/flightgear/mailman/message/34921495/</ref><ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35157325/
|title = <nowiki> Re: [Flightgear-devel] GUI options (Was: Aircraft center) </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jun 14th, 2016
|added = Jun 14th, 2016
|script_version = 0.40
}}</ref> and coordinate any related work with the devel mailing list first-this applies particularly to adding any [[Template:PUI_widget|additional hard-coded PUI widgets]]. }}
[[File:Exit.png|thumb|FlightGear GUI dialog (exit.xml)stored in $FG_ROOT/gui/dialogs]]
{{GUI Navbar}}

[[File:Custom-autopilot-dialog.png|right|200px]]
[[PUI]] is the standard GUI engine used in FlightGear, it is part of [[PLIB]] and is using raw, fixed-pipeline, [[OpenGL]] code internally (no [[OpenSceneGraph]]). As of mid 2021, FlightGear is in the process of working towards adopting the OpenGL Core Profile, this means that [[PUI]] is causing trouble and needs to be replaced/disabled or ported.

PUI provides a fairly basic, but robust, set of widgets. PUI is also used for rendering the [[Menubar]].

FlightGear uses a GUI widget set that is implemented on top of raw (legacy) [[OpenGL]]. This has many advantages from a portability standpoint and from the standpoint of integrating with window systems. [[PUI]] doesn't have every feature under the sun, but it was never meant to. It's relatively small, lean, mean, and written on top of [[OpenGL]] which makes life *much* easier for us.

[[PUI]] already is a separate distinct library within Plib. It depends on some central utility stuff, but that's about it. So it is pretty stripped down and separate already.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg26011.html</ref>

We are to some extent hamstrung by the rather old GUI toolkit we use. However, replacing that is going to be non-trivial, and it would affect not just the core GUI but also all the dialog boxes that have been set up for particular aircraft.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg25985.html</ref>

Flightgear can look amazing when you use the HDR pipeline. We absolutely need this to stay relevant. The problem is that HDR is not compatible with OpenGL1 PUI. Work on getting rid of PUI has been going on for over a decade (longer than it took to implement it).<ref>https://sourceforge.net/p/flightgear/mailman/message/37727346/</ref>

[[File:menubar2.jpg|517px]]

== Replacement status ==
{{See also|FlightGear_and_OpenGL_ES#Example:_disabling_PUI}}

{{Note| Update 09/2022: The PUI replacement [[QtQuick_use_in_FlightGear#Background|was going to be Qt]] but it started to get very complicated with changes in Qt 5.15 + Qt 6, so James is going with a more light-weight Canvas based approach now.

Qt added support for Vulkan / Metal / D3D starting in 5.15, but FlightGear / OpenSceneGraph can’t support those, so integrating the two renderers went from being ‘complicated but ok’ to ‘very very complicated’.

So now James is going with something much more lightweight using some C++ compatibility code, some Nasal for styling and the existing [[Canvas widgets|Canvas widget rendering]] from Thomas Geymayer (TheTom) with [[Canvas Widget Matrix|some extensions and additions]], based on the [[Howto:Processing_legacy_PUI_dialogs_using_Canvas#Original_Discussion|plans originally discussed when the Canvas GUI system was added to FlightGear]]: some pieces are in FlightGear & FGData already.

James has basic dialogs working okay but not the more complex ones and everything looks kind of ugly, he needs to improve the visual look before he shares screenshots to avoid everyone freaking out :) The disadvantage of this approach is James is far from expert at creating visual appearances this way, so it’s kind on unrewarding and slow for him. If someone likes messing with CSS-type styling, border-images and hover-states, ping him since we could probably move things also faster <ref>https://sourceforge.net/p/flightgear/mailman/message/37701750/</ref>}}

=== Motivation ===
{{Main article|Core Profile support}}

The bigger issue here is we need to ditch [[PUI]] (which is in progress) and some OpenGL 1.0 code (HUD, 2D panels especially - can be #ifdef for now) so we can enable Core profile on Mac - since Mac 4.x support (we only hit about 4.3 alas, but with some extensions to get in sight of 4.5) is Core profile only, no Compatability mode.

Improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, many people are convinced PUI needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

While most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so [using Qt5] would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

== Canvas Emulation ==
{{See also|Canvas widget matrix}}
'''Last updated: 04/2023 <ref>https://sourceforge.net/p/flightgear/mailman/message/37805054/</ref>
'''
=== Status ===
As of 01/2023, the replacement for PUI is making good progress<ref>https://sourceforge.net/p/flightgear/mailman/message/37765706/</ref>.

In February 2022, James reported having something in progress locally, and that should even be something we can try in March/April 2022. Hopefully that’s quick enough, knowing it has been a long time coming.<ref>https://sourceforge.net/p/flightgear/mailman/message/37606439/</ref>

There's now an XML to Nasal bridge, to keep PUI dialogs working (Disabled by a CMake option)
This is implemented on top of the [[Canvas]] system.

This builds equivalent C++ objects to what the [[PUI]] dialogs build, with properties exposed to Nasal.
Peer objects are created by Nasal [[callbacks]], which can implement the various dialog functions needed to keep compatibility, especially the [[#Background|‘update’ and ‘apply’ hooks]].<ref>https://sourceforge.net/p/flightgear/flightgear/ci/cbd5ef9e7b8f433dbc1ba97bae7d7cfc894e7cef/</ref>

{{Note|The PUI Compatible Canvas GUI is a compile time option: Use the following [[Building using CMake|cmake option]] to enable this code: {{CMake Build Option|option=ENABLE_PUICOMPAT|default=ON|description=This requires latest SG/FG AND FGDATA}}. But this is all highly fluid and most of it really developer only. At one point they will become default or be accessible in the launcher.<ref>https://sourceforge.net/p/flightgear/mailman/message/37834004/</ref>

If you compiled with PUICompatibility enabled, but still don't see any dialogs - only the menubar, you might need to enable the GUI module in defaults.xml<ref>https://sourceforge.net/p/flightgear/mailman/message/37833149/</ref>}}

The new Compatibility files can now be found in $FG_SRC/GUI:

* {{flightgear file|src/GUI/FGPUICompatDialog.cxx }}
* {{flightgear file|src/GUI/FGPUICompatDialog.hxx }}
* {{flightgear file|src/GUI/PUICompatObject.cxx }}

01/2023: James is slowly working on creating the pop-up menu and combo-box widgets [...]

One of the major things slowing down James' work on the popup-menu and combo box is time to restart the simulator for each change, he is looking for some solution to re-load the widget Nasal code independently. <ref><https://sourceforge.net/p/flightgear/mailman/message/37756183/</ref>

James has done about 75% (hah!) of the C++ work to enable live reloading of modules this way, but unfortunately there are some code paths that would become crashy if you use the feature for the Canvas: because it would reference the ‘old’ (pre-reload) Nasal code, and not the new one, and therefore you’d get a weird mix of old and new, and then just crash the sim. To fix it properly I need to track down those places that store a reference to Canvas and give them a re-init method, so we don’t keep the stale references.

The general non-fun-ness of that kind of debugging is James has been making such slow progress on my PUI replacement widgets recently <ref>https://sourceforge.net/p/flightgear/mailman/message/37756263/</ref>

=== Todo ===
Nothing in particular: help debugging the grid layout (which is in simgear) would be good. For now, you could create a grid layout manually using some Nasal.

For the menubar, we need to expose the C++ data to Nasal: we need a FGCompatMenuBar (alongisde FGPUIMenuBar) implementing FGMenubar which calls _createMenuObject in MenuBar.nas, using the same way I lookup and call _createDialogPeer in XMLDialog.nas

(Make sure you don’t break the macOS native menubar in the process!)

You can probably pass a wrapped SGpropertyNode into this, and then fill in the stubs in that file to use the Menu widgets Frederic has written.

Global menu keybindings won’t worry but don’t touch that, I have a separate plan for it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37805736/</ref>

As of 04/2023, remaining items on the todo list are: <ref>https://sourceforge.net/p/flightgear/mailman/message/37805060/</ref>

* Grid layout
** GridLayout needs debugged: After this, the basic UI is usable, would probably make it a switchable option on ‘next’ (I can already use the simulator with the new UI today, but all the sizes are off in the grid layouts which we use everywhere)

* list
* table (and tree ?) models corresponding views
* waypoint list
* Re-write the waypoint list and airport dialog to work again (since these use custom widgets):
** log list
** airport-list equivalents
* Nasal access to the menu i18n functions
* selection support for single- and multi-line text (which is being worked on -> CanvasPangoText)
* Keyboard shortcut handling, although this is not really a PUI vs replacement issue, to me we should handle UI shortcuts in the same was normal keyboard.xml shortcuts
** this previously worked because PUI got ‘first chance’ at handling key input. But we always had duplication between keyboard.xml and other places, so I would rather standardise on keyboard.xml, but allow a UI element to set a scope for shortcuts. (So that Copy/paste shortcuts etc can work in a text input, at least … but probably some other standard ones) <ref>https://sourceforge.net/p/flightgear/mailman/message/37805188/</ref>
* Ensure all the places which use the PUI combo-box and list-widget work : there’s a few of these.

The CanvasPangoText stuff is needed but we can perfectly well run the UI on next without it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37805176/</ref>

=== Parser ===
{{Main article|pui2canvas}}
The corresponding Nasal/Canvas module to dynamically "translate" legacy PUI/XML dialogs into Canvas dialogs (at runtime), is to be found in {{fgdata file|Nasal/gui/XMLDialog.nas}} <ref>https://sourceforge.net/p/flightgear/fgdata/ci/fe7c87b21a69f88ddb87d89453c48d12b69660e2/</ref>

=== Widgets ===
{{Main article|Howto:Creating a Canvas GUI Widget}}

It’s split between Simgear (see classes with widget / layout in the name) and in FGData. (Eg widgets/Button.nas) To be able to use the existing dialog XML files un-modified (which is a design goal), James is extending the widget types with many additional ones (eg PUI has slider, dial, combo-box, checkbox, all of which need to be created, see [[Canvas widget matrix]].

This is about 30% done and is the bit he's very slow at). Thomas’s canvas widgets have a very good separation of API + state from appearance, so all styling is in its own file, and James is being very strict about maintaining this separation, so we also retain the re-styling feature of the PUI UI, which many people also rely on. This does make the process of adding new widgets more complex, however.

{{See also|Canvas widgets}}

=== Layouting ===
The other thing is to preserve all the layouting: James has added a grid layout to Simgear, since that is supported by the existing PUI code (even though the layouts are not actually part of PUI itself). The problem is getting the sizing / hinting of all the widgets to match the PUI values, so that dialogs look approximately the same under the new UI as they did with PUI; again this a design goal so that all existing dialogs in aircraft and add-ons, which we can’t update, continue to work and be usable. Debugging that is also proving quite tricky, since there’s all kinds of hard-coded assumptions built into PUI widgets about pixels, font-sizes etc which are not true in the new system.<ref>https://sourceforge.net/p/flightgear/mailman/message/37701792/</ref>

== Background ==
In FlightGear, PUI dialogs are standard [[PropertyList XML File]]s that are stored in $FG_ROOT/gui/dialogs, they can contain the widgets mentioned in {{readme file|gui}}, using a simple layout engine discussed in {{readme file|layout}}, and bindings using a combination of so called fgcommands operating on properties (see {{readme file|commands}}) and custom [[Nasal]] (FlightGear scripting) code.

In addition, each PUI/XML dialog may contain Nasal script sections that are executed when opening/closing the dialog, a feature which is commonly used for procedurally creating/updating widgets using the [[Nasal_library#cmdarg.28.29|cmdarg() API]], which allows the dialog tree to be traversed and manipulated prior to the dialog being rendered.
Widgets can be conditionally hidden/shown using a wrapper for [[Conditions|SGCondition]] in [[Nasal_library/props|props.nas]]
The <code>canvas</code> widget also supports its own embedded Nasal code section to execute arbitrary widget specific Nasal code upon opening/closing the dialog/widget.

PUI/XML dialogs can be loaded, dynamically created, updated and closed using a handful of fgcommands:
* {{fgcommand|dialog-new}}
* {{fgcommand|dialog-show}}
* {{fgcommand|dialog-update}}
* {{fgcommand|dialog-apply}}
* {{fgcommand|dialog-close}}

PUI related OpenGL code is particularly infamous for causing rendering artifacts for people on AMD/ATI and Intel hardware (especially in combination with certain fonts/styles and [[Effects|effects]]/[[Shaders|shaders]]), see {{Issue|2213}}.

PUI is also known to affect rendering performance quite significantly (see {{search |keywords=anthrax+gui}}), while also preventing FlightGear from using a more recent version of OpenGL<ref>http://sourceforge.net/p/flightgear/mailman/message/34532040/</ref><ref>http://forum.flightgear.org/viewtopic.php?f=71&t=24046</ref>.

However, improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Besides, while most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

But given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, graphics folks are also convinced it needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

In addition, [[OpenSceneGraph]] (OSG) can obviously not help optimize any PUI related GL code and PUI widgets are generally considered to be pretty archaic and not easy to extend<ref>http://sourceforge.net/p/flightgear/mailman/message/26832164/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587120/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587272/</ref>.

{{Note|We use the GUI code from PLIB, which doesn't know anything about OSG. See the SGPuDrawable class in $FG_SRC/Viewer/renderer.cxx for the implementation. The one catch is that OSG has a strong notion of separation between the update of a "scene" and its rendering, and that might not play well with arbitrary existing OpenGL code. }}

As of late 2015, there is heavy activity towards providing alternatives to a PUI-based UI:
* [[Integrated Web GUI]] (external, browser-based - fully asynchronous)
* [[Howto:Processing legacy PUI dialogs using Canvas]] (internal, using the [[Canvas]] system and a simple [[Nasal]] parser to deal with existing PUI/XML dialogs)

<gallery mode="packed">
Early-Phi-screen shot.PNG|Screenshot showing [[Phi]]
About-dialog-rendered-by-canvas.png|Screenshot showing a dialog rendered by the [[Howto:Processing legacy PUI dialogs using Canvas|pui2canvas parser]]
</gallery>

== History ==
{{Caution|This is merely kept for future reference, many of the ideas discussed below have become obsolete as of 09/2022, if in doubt, please get in touch via devel-list.}}
=== 2021 ===
In early 2021, James did a brief evaluation of [https://github.com/ocornut/imgui ImGUI] as a possibility - he's also evaluating it in some projects at his day job.

The API is interesting if you’re starting from scratch and only exclusively in C++, but it’s not a great fit for how we define GUIs in FG (via [[XML]]/[[Nasal]]): there is no back door that he could find, to access the persistent state of the GUI, or build it up in a data-driven way. So making a mapping to keep our existing GUI XML working (and updating correctly) becomes a bit of a chore.<ref>https://sourceforge.net/p/flightgear/mailman/message/37295586/</ref>

Pretty much all of the FlightGear GUI is defined in XML space, except for a few oddments. Let’s say 95% at this point.

Additionally, even if we were to change that for the core sim (and James' current plan is to keep the XML syntax and just extend it), the installed base of '''aircraft''' ship their own XML dialogs (eg., replacing the autopilot dialog with a custom one, or just adding their own aircraft-specific helper controls for doors / lights / cargo / whatever). So even if we found the most sublimely beautiful, intuitive, compact GUI description language in the world, we have to keep the XML syntax working as-is, for the foreseeable future.

Given this, James' intention is to replace the output side [[PUI]] but keep the front-end side (XML / properties / bindings) unchanged, and therefore backwards compatible, and simply add some new types / options / widget types going forward. This will mean we still have to deal with the slightly cumbersome XML+Nasal syntax, but, well, it’s not *that* cumbersome. <ref>https://sourceforge.net/p/flightgear/mailman/message/37296280/</ref>

In mid 2021, James reported that he is working on some ‘PUICompat’ classes which hold/own/represent the GUI state in C++, but which can be used with [[Nasal/CppBind|Nasal CppBind]]. And of course we could indeed expose those later on. <ref>https://sourceforge.net/p/flightgear/mailman/message/37297727/</ref>

In July 2021, James suggested not to worry about the existing GUI code, it’s going in the bin.<ref>https://sourceforge.net/p/flightgear/mailman/message/37325905/</ref>

For the time being, the in-sim GUi can’t do Unicode yet, but James is working on it, hopefully available soon.<ref>https://sourceforge.net/p/flightgear/mailman/message/37328200/</ref>
Also, the in-sim menubar will change with the new GUI, *and* we use a native menubar on macOS. Until James replaces the PUI fonts we can’t use Unicode symbols. So, will have to come back to it once the new GUI is merged.<ref>https://sourceforge.net/p/flightgear/mailman/message/37327237/</ref>

=== 2020 ===
As of 03/2020, the PLIB replacement was reported to be in the backlog <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36951255/
|title = <nowiki>Re: [Flightgear-devel] C++ and/or OSG question </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Mar 18th, 2020
|added = Mar 18th, 2020
|script_version = 0.50
}}</ref>.

With PLIB replacement work likely being re-scheduled for [[Post FlightGear 2020.2 LTS changes]] <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36985375/
|title = <nowiki>Re: [Flightgear-devel] Working Group Proposal - Boost and PLIB replacement - Delegation and Teamwork </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = April 18th, 2020
|added = April 18th, 2020
|script_version = 1.10
}}</ref>.

In 08/2020, James stated that he was still working (exceptionally slowly!) on replacing PUI (as part of removing legacy OpenGL code (PUI, HUD, 2d panels, porting Canvas away form ShivaVG), so we can switch to Vulkan/VSG at some point (ideally at some point before Apple turn off OpenGL support…)), and that he doesn't think /any/ of us *want* to be working on these features particularly, but projects like these need to be done before anyone can have fun with VSG or Vulkan (personally James would be very enthusiastic about working on VSG support (being on macOS, I also have the most to lose / gain from it)). Sometimes that’s just how it goes. Equally they will all benefit the project ultimately, but the payoff both for the individual and the project is very drawn out. <ref>https://sourceforge.net/p/flightgear/mailman/message/37077158/</ref>

In 10/2020, the estimation is that PUI should be going away really ‘soon’, the replacement code is already in next / 2020.2. (There’s no plan to actually /use/ the new UI code in 2020.2, but if the bugs in it prove simple, we could actually turn it for specific dialog: it seems very unlikely this makes sense for a stable release however)<ref>https://sourceforge.net/p/flightgear/mailman/message/37123818/</ref>

The fixed-function removal, is actively in hand (Gaetan is working on the 2D panel part, and James is going to focus on PUI in the rest of 2020). James hopes that means next year he can focus on Vulkan, or at least, using OSG as if /were/ VSG, so the migration in a year or two when VSG is stable, is not so painful.<ref>https://sourceforge.net/p/flightgear/mailman/message/37129098/</ref>

The PUI UI and replacement can co-exist in the same build (they already do, effectively.<ref>https://sourceforge.net/p/flightgear/mailman/message/37131297/</ref>

In 11/2020, James suggested not to worry about details such as PUI styling/theming etc: we’re not making such changes for the LTS, and PUI should be gone before the next release.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142225/</ref> Also, he recommended (to everyone) to stop touching GUI stuff for a few weeks, as he's about to turn it all on its head.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142356/</ref>

=== 2019 ===
The new GUI has been incubating for a few years, but there's apparently been a lot of progress as of 10/2019.

It is likely the new GUI will be a user opt-in feature - at least initially. The sunset of the PLIB library _could_ happen relatively soon, but
people will need to see the new GUI and react to it before we could commit to PLIB removal <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36784489/
|title = <nowiki>Re: [Flightgear-devel] in Flightgear/Simgear C++ Code: What needs Doing? What are YOU Doing? What would you do if you had the time? </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Oct 14th, 2019
|added = Oct 14th, 2019
|script_version = 0.50
}}</ref>.

In 02/2019, James stated that the new UI is coming quite soon. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36589420/
|title = <nowiki> Re: [Flightgear-devel] Lagging </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Feb 17th, 2019
|added = Feb 17th, 2019
|script_version = 0.40
}}</ref>

=== 2018 ===
{{See also|QtQuick use in FlightGear}}

According to James, we have to accept that changes like testing or making [[PUI]] a modular thing or moving the JS code tend to have an immediate pain for some people (because strange stuff gets broken, and takes some time to get fixed), whereas the payoff in terms of improved joystick handling or replacing the UI or testing of all subsystems will take some months or years to be felt.<ref>https://sourceforge.net/p/flightgear/mailman/message/36323240/</ref>

James said he was in the middle of porting the launcher’s final tab (location) to the new UI scheme, once that’s done he will start sketching out the ‘in sim’ settings UI using the same pieces. He’ll send a request for contributions around about that in the next three-four weeks, once he has enough templates & examples that there is a clear pattern to follow.<ref>https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/2d10f16c-ddc8-07f3-07e7-eca2a0a0d55f%40zaretto.com/#msg36293586</ref>

James announced that the launcher is now feature complete with the QtQuick UI, he’ll keep making bug-fixes of course as people report them, but my todo list for the core features is now done<ref>https://sourceforge.net/p/flightgear/mailman/message/36355833/</ref>.

=== 2017 ===

In 10/2017, James said he was getting really close to having the PUI replacement UI suitable for beta-testing.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36067646/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 7th, 2017
|added = Oct 7th, 2017
|script_version = 0.40
}}</ref>

Originally, James was hoping to land the PUI replacement GUI in the last dev cycle in 2017 (at least as a proof-of-concept, probably not as the default UI), so wouldn’t expend lots of effort on things like collapsible sections which might be a lot of work with the current PUI/Canvas approaches, but are trivial with the new [[QtQuick use in FlightGear|QtQuick based UI scheme]].<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36059822/
|title = <nowiki> Re: [Flightgear-devel] Canvas MapLayer for OpenStreetMap, OpenAIP,
VFR Sectionals </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 1st, 2017
|added = Oct 1st, 2017
|script_version = 0.40
}}</ref>

Once the basic new UI is in place we can experiment with different re-arrangements easily, without being limited by PUI. (James expects PUI to live on as the default / alternate UI while this happens)<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36061229/
|title = <nowiki> Re: [Flightgear-devel] FGFS macOS Menubar </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 2nd, 2017
|added = Oct 2nd, 2017
|script_version = 0.40
}}</ref>

Technically, this entails replacing dialog.cxx with some code which builds up some special ‘PUI-Emulation’ QtQuick controls, so that existing dialogs (especially from Aircraft) continue to work. This mode will look somewhat ugly but hopefully no more ugly than PUI! And it helps that the set of widgets we have in PUI is limited, and the ‘tricky’ widgets (map, scrolling list, etc) are in the dialogs will will replace with new ones first.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068767/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

This PUI emulation isn't going to use any code from PLIB<ref>https://sourceforge.net/p/flightgear/mailman/message/36985303/</ref>, so what will remain from it in FG afterwards will be the FNT and JS components (reworked).<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068817/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> Florent Rougon </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

=== 2016 ===
We need to explore if Qt Quick or widgets is the better way to go, with a preference towards Qt Quick, since it will allow things closer to current PUI (semi-transparent widgets on top of the 3D content). It still allows creating separate windows too (Erik’s use case), but means we get consistent, custom theming on all platforms, since standard desktop look is not so nice for a flight-sim.

James intention is to make a QML-hosting OSG-drawable, and add this as a concept in Qt-enabled builds, then port some PUI dialogs to it, and see how easy / painful the process is. Hell create some QObjects which expose commands and the property tree and Nasal.

This has the advantage of not touching the OSG window at all, QtQuick simply provides some additional OpenGL rendering on top, which we pass events to - pretty much exactly the same as what we already do for PUI, and hopefully can co-exist with it. James got this working in a local OSG tree in a standalone demo, but that’s based on osgQt - he wants to see if he can make it work on a normal, non-Qt OSG window inside FlightGear.<ref>https://sourceforge.net/p/flightgear/mailman/message/35156051/</ref>

The idea is to host an XML dialog (Currently done with PUI) from Qt also. The question is if that can be done keeping ‘source compatibility’ exactly with the current UI XML and Nasal interface. It probably can be, but many of the PUI widgets have really ugly APIs, especially for combo-boxes, drop-down menus and scrolling lists, where it makes sense to map a Nasal class to a Qt ItemModel, which would be more elegant and easy to work with in both Nasal and integrate on the Qt side. But obviously would mean changing the dialog sources.

Of course, aircraft dialogs tend to be simpler, and not use the more complex PUI widgets, precisely for reasons like this, but that’s a limitation it would be best to remove.<ref>https://sourceforge.net/p/flightgear/mailman/message/35155721/</ref>


== References ==
{{Appendix}}

[[Category:PUI| ]]
[[Category:Rendering roadblocks]]

PUI

2023-04-21T09:52:34Z

Hooray: /* Todo */

{{Feature to be removed|version=2023.3|reason=[[Plib]]/PUI is to be removed and replaced by a [[Canvas widget matrix|Canvas/Nasal based solution]] to help improve compatibility with [[OSG]] 3.6+ and [[OpenGL]] 4.x ([[Core Profile support|OpenGL Core Profile]], see [[2022.X Release plan]] ) and improve performance by [[Unifying the 2D rendering backend via canvas|phasing out legacy OpenGL code]]. Therefore, people should be careful when extending the '''PUI''' based legacy GUI engine<ref>https://sourceforge.net/p/flightgear/mailman/message/34921495/</ref><ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35157325/
|title = <nowiki> Re: [Flightgear-devel] GUI options (Was: Aircraft center) </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jun 14th, 2016
|added = Jun 14th, 2016
|script_version = 0.40
}}</ref> and coordinate any related work with the devel mailing list first-this applies particularly to adding any [[Template:PUI_widget|additional hard-coded PUI widgets]]. }}
[[File:Exit.png|thumb|FlightGear GUI dialog (exit.xml)stored in $FG_ROOT/gui/dialogs]]
{{GUI Navbar}}

[[File:Custom-autopilot-dialog.png|right|200px]]
[[PUI]] is the standard GUI engine used in FlightGear, it is part of [[PLIB]] and is using raw, fixed-pipeline, [[OpenGL]] code internally (no [[OpenSceneGraph]]). As of mid 2021, FlightGear is in the process of working towards adopting the OpenGL Core Profile, this means that [[PUI]] is causing trouble and needs to be replaced/disabled or ported.

PUI provides a fairly basic, but robust, set of widgets. PUI is also used for rendering the [[Menubar]].

FlightGear uses a GUI widget set that is implemented on top of raw (legacy) [[OpenGL]]. This has many advantages from a portability standpoint and from the standpoint of integrating with window systems. [[PUI]] doesn't have every feature under the sun, but it was never meant to. It's relatively small, lean, mean, and written on top of [[OpenGL]] which makes life *much* easier for us.

[[PUI]] already is a separate distinct library within Plib. It depends on some central utility stuff, but that's about it. So it is pretty stripped down and separate already.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg26011.html</ref>

We are to some extent hamstrung by the rather old GUI toolkit we use. However, replacing that is going to be non-trivial, and it would affect not just the core GUI but also all the dialog boxes that have been set up for particular aircraft.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg25985.html</ref>

Flightgear can look amazing when you use the HDR pipeline. We absolutely need this to stay relevant. The problem is that HDR is not compatible with OpenGL1 PUI. Work on getting rid of PUI has been going on for over a decade (longer than it took to implement it).<ref>https://sourceforge.net/p/flightgear/mailman/message/37727346/</ref>

[[File:menubar2.jpg|517px]]

== Replacement status ==
{{See also|FlightGear_and_OpenGL_ES#Example:_disabling_PUI}}

{{Note| Update 09/2022: The PUI replacement [[QtQuick_use_in_FlightGear#Background|was going to be Qt]] but it started to get very complicated with changes in Qt 5.15 + Qt 6, so James is going with a more light-weight Canvas based approach now.

Qt added support for Vulkan / Metal / D3D starting in 5.15, but FlightGear / OpenSceneGraph can’t support those, so integrating the two renderers went from being ‘complicated but ok’ to ‘very very complicated’.

So now James is going with something much more lightweight using some C++ compatibility code, some Nasal for styling and the existing [[Canvas widgets|Canvas widget rendering]] from Thomas Geymayer (TheTom) with some extensions and additions, based on the [[Howto:Processing_legacy_PUI_dialogs_using_Canvas#Original_Discussion|plans originally discussed when the Canvas GUI system was added to FlightGear]]: some pieces are in FlightGear & FGData already.

James has basic dialogs working okay but not the more complex ones and everything looks kind of ugly, he needs to improve the visual look before he shares screenshots to avoid everyone freaking out :) The disadvantage of this approach is James is far from expert at creating visual appearances this way, so it’s kind on unrewarding and slow for him. If someone likes messing with CSS-type styling, border-images and hover-states, ping him since we could probably move things also faster <ref>https://sourceforge.net/p/flightgear/mailman/message/37701750/</ref>}}

=== Motivation ===
{{Main article|Core Profile support}}

The bigger issue here is we need to ditch [[PUI]] (which is in progress) and some OpenGL 1.0 code (HUD, 2D panels especially - can be #ifdef for now) so we can enable Core profile on Mac - since Mac 4.x support (we only hit about 4.3 alas, but with some extensions to get in sight of 4.5) is Core profile only, no Compatability mode.

Improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, many people are convinced PUI needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

While most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so [using Qt5] would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

== Canvas Emulation ==
{{See also|Canvas widget matrix}}
'''Last updated: 04/2023 <ref>https://sourceforge.net/p/flightgear/mailman/message/37805054/</ref>
'''
=== Status ===
As of 01/2023, the replacement for PUI is making good progress<ref>https://sourceforge.net/p/flightgear/mailman/message/37765706/</ref>.

In February 2022, James reported having something in progress locally, and that should even be something we can try in March/April 2022. Hopefully that’s quick enough, knowing it has been a long time coming.<ref>https://sourceforge.net/p/flightgear/mailman/message/37606439/</ref>

There's now an XML to Nasal bridge, to keep PUI dialogs working (Disabled by a CMake option)
This is implemented on top of the [[Canvas]] system.

This builds equivalent C++ objects to what the [[PUI]] dialogs build, with properties exposed to Nasal.
Peer objects are created by Nasal [[callbacks]], which can implement the various dialog functions needed to keep compatibility, especially the [[#Background|‘update’ and ‘apply’ hooks]].<ref>https://sourceforge.net/p/flightgear/flightgear/ci/cbd5ef9e7b8f433dbc1ba97bae7d7cfc894e7cef/</ref>

{{Note|The PUI Compatible Canvas GUI is a compile time option: Use the following [[Building using CMake|cmake option]] to enable this code: {{CMake Build Option|option=ENABLE_PUICOMPAT|default=ON|description=This requires latest SG/FG AND FGDATA}}. But this is all highly fluid and most of it really developer only. At one point they will become default or be accessible in the launcher.<ref>https://sourceforge.net/p/flightgear/mailman/message/37834004/</ref>

If you compiled with PUICompatibility enabled, but still don't see any dialogs - only the menubar, you might need to enable the GUI module in defaults.xml<ref>https://sourceforge.net/p/flightgear/mailman/message/37833149/</ref>}}

The new Compatibility files can now be found in $FG_SRC/GUI:

* {{flightgear file|src/GUI/FGPUICompatDialog.cxx }}
* {{flightgear file|src/GUI/FGPUICompatDialog.hxx }}
* {{flightgear file|src/GUI/PUICompatObject.cxx }}

01/2023: James is slowly working on creating the pop-up menu and combo-box widgets [...]

One of the major things slowing down James' work on the popup-menu and combo box is time to restart the simulator for each change, he is looking for some solution to re-load the widget Nasal code independently. <ref><https://sourceforge.net/p/flightgear/mailman/message/37756183/</ref>

James has done about 75% (hah!) of the C++ work to enable live reloading of modules this way, but unfortunately there are some code paths that would become crashy if you use the feature for the Canvas: because it would reference the ‘old’ (pre-reload) Nasal code, and not the new one, and therefore you’d get a weird mix of old and new, and then just crash the sim. To fix it properly I need to track down those places that store a reference to Canvas and give them a re-init method, so we don’t keep the stale references.

The general non-fun-ness of that kind of debugging is James has been making such slow progress on my PUI replacement widgets recently <ref>https://sourceforge.net/p/flightgear/mailman/message/37756263/</ref>

=== Todo ===
Nothing in particular: help debugging the grid layout (which is in simgear) would be good. For now, you could create a grid layout manually using some Nasal.

For the menubar, we need to expose the C++ data to Nasal: we need a FGCompatMenuBar (alongisde FGPUIMenuBar) implementing FGMenubar which calls _createMenuObject in MenuBar.nas, using the same way I lookup and call _createDialogPeer in XMLDialog.nas

(Make sure you don’t break the macOS native menubar in the process!)

You can probably pass a wrapped SGpropertyNode into this, and then fill in the stubs in that file to use the Menu widgets Frederic has written.

Global menu keybindings won’t worry but don’t touch that, I have a separate plan for it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37805736/</ref>

As of 04/2023, remaining items on the todo list are: <ref>https://sourceforge.net/p/flightgear/mailman/message/37805060/</ref>

* Grid layout
** GridLayout needs debugged: After this, the basic UI is usable, would probably make it a switchable option on ‘next’ (I can already use the simulator with the new UI today, but all the sizes are off in the grid layouts which we use everywhere)

* list
* table (and tree ?) models corresponding views
* waypoint list
* Re-write the waypoint list and airport dialog to work again (since these use custom widgets):
** log list
** airport-list equivalents
* Nasal access to the menu i18n functions
* selection support for single- and multi-line text (which is being worked on -> CanvasPangoText)
* Keyboard shortcut handling, although this is not really a PUI vs replacement issue, to me we should handle UI shortcuts in the same was normal keyboard.xml shortcuts
** this previously worked because PUI got ‘first chance’ at handling key input. But we always had duplication between keyboard.xml and other places, so I would rather standardise on keyboard.xml, but allow a UI element to set a scope for shortcuts. (So that Copy/paste shortcuts etc can work in a text input, at least … but probably some other standard ones) <ref>https://sourceforge.net/p/flightgear/mailman/message/37805188/</ref>
* Ensure all the places which use the PUI combo-box and list-widget work : there’s a few of these.

The CanvasPangoText stuff is needed but we can perfectly well run the UI on next without it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37805176/</ref>

=== Parser ===
{{Main article|pui2canvas}}
The corresponding Nasal/Canvas module to dynamically "translate" legacy PUI/XML dialogs into Canvas dialogs (at runtime), is to be found in {{fgdata file|Nasal/gui/XMLDialog.nas}} <ref>https://sourceforge.net/p/flightgear/fgdata/ci/fe7c87b21a69f88ddb87d89453c48d12b69660e2/</ref>

=== Widgets ===
{{Main article|Howto:Creating a Canvas GUI Widget}}

It’s split between Simgear (see classes with widget / layout in the name) and in FGData. (Eg widgets/Button.nas) To be able to use the existing dialog XML files un-modified (which is a design goal), James is extending the widget types with many additional ones (eg PUI has slider, dial, combo-box, checkbox, all of which need to be created, see [[Canvas widget matrix]].

This is about 30% done and is the bit he's very slow at). Thomas’s canvas widgets have a very good separation of API + state from appearance, so all styling is in its own file, and James is being very strict about maintaining this separation, so we also retain the re-styling feature of the PUI UI, which many people also rely on. This does make the process of adding new widgets more complex, however.

{{See also|Canvas widgets}}

=== Layouting ===
The other thing is to preserve all the layouting: James has added a grid layout to Simgear, since that is supported by the existing PUI code (even though the layouts are not actually part of PUI itself). The problem is getting the sizing / hinting of all the widgets to match the PUI values, so that dialogs look approximately the same under the new UI as they did with PUI; again this a design goal so that all existing dialogs in aircraft and add-ons, which we can’t update, continue to work and be usable. Debugging that is also proving quite tricky, since there’s all kinds of hard-coded assumptions built into PUI widgets about pixels, font-sizes etc which are not true in the new system.<ref>https://sourceforge.net/p/flightgear/mailman/message/37701792/</ref>

== Background ==
In FlightGear, PUI dialogs are standard [[PropertyList XML File]]s that are stored in $FG_ROOT/gui/dialogs, they can contain the widgets mentioned in {{readme file|gui}}, using a simple layout engine discussed in {{readme file|layout}}, and bindings using a combination of so called fgcommands operating on properties (see {{readme file|commands}}) and custom [[Nasal]] (FlightGear scripting) code.

In addition, each PUI/XML dialog may contain Nasal script sections that are executed when opening/closing the dialog, a feature which is commonly used for procedurally creating/updating widgets using the [[Nasal_library#cmdarg.28.29|cmdarg() API]], which allows the dialog tree to be traversed and manipulated prior to the dialog being rendered.
Widgets can be conditionally hidden/shown using a wrapper for [[Conditions|SGCondition]] in [[Nasal_library/props|props.nas]]
The <code>canvas</code> widget also supports its own embedded Nasal code section to execute arbitrary widget specific Nasal code upon opening/closing the dialog/widget.

PUI/XML dialogs can be loaded, dynamically created, updated and closed using a handful of fgcommands:
* {{fgcommand|dialog-new}}
* {{fgcommand|dialog-show}}
* {{fgcommand|dialog-update}}
* {{fgcommand|dialog-apply}}
* {{fgcommand|dialog-close}}

PUI related OpenGL code is particularly infamous for causing rendering artifacts for people on AMD/ATI and Intel hardware (especially in combination with certain fonts/styles and [[Effects|effects]]/[[Shaders|shaders]]), see {{Issue|2213}}.

PUI is also known to affect rendering performance quite significantly (see {{search |keywords=anthrax+gui}}), while also preventing FlightGear from using a more recent version of OpenGL<ref>http://sourceforge.net/p/flightgear/mailman/message/34532040/</ref><ref>http://forum.flightgear.org/viewtopic.php?f=71&t=24046</ref>.

However, improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Besides, while most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

But given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, graphics folks are also convinced it needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

In addition, [[OpenSceneGraph]] (OSG) can obviously not help optimize any PUI related GL code and PUI widgets are generally considered to be pretty archaic and not easy to extend<ref>http://sourceforge.net/p/flightgear/mailman/message/26832164/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587120/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587272/</ref>.

{{Note|We use the GUI code from PLIB, which doesn't know anything about OSG. See the SGPuDrawable class in $FG_SRC/Viewer/renderer.cxx for the implementation. The one catch is that OSG has a strong notion of separation between the update of a "scene" and its rendering, and that might not play well with arbitrary existing OpenGL code. }}

As of late 2015, there is heavy activity towards providing alternatives to a PUI-based UI:
* [[Integrated Web GUI]] (external, browser-based - fully asynchronous)
* [[Howto:Processing legacy PUI dialogs using Canvas]] (internal, using the [[Canvas]] system and a simple [[Nasal]] parser to deal with existing PUI/XML dialogs)

<gallery mode="packed">
Early-Phi-screen shot.PNG|Screenshot showing [[Phi]]
About-dialog-rendered-by-canvas.png|Screenshot showing a dialog rendered by the [[Howto:Processing legacy PUI dialogs using Canvas|pui2canvas parser]]
</gallery>

== History ==
{{Caution|This is merely kept for future reference, many of the ideas discussed below have become obsolete as of 09/2022, if in doubt, please get in touch via devel-list.}}
=== 2021 ===
In early 2021, James did a brief evaluation of [https://github.com/ocornut/imgui ImGUI] as a possibility - he's also evaluating it in some projects at his day job.

The API is interesting if you’re starting from scratch and only exclusively in C++, but it’s not a great fit for how we define GUIs in FG (via [[XML]]/[[Nasal]]): there is no back door that he could find, to access the persistent state of the GUI, or build it up in a data-driven way. So making a mapping to keep our existing GUI XML working (and updating correctly) becomes a bit of a chore.<ref>https://sourceforge.net/p/flightgear/mailman/message/37295586/</ref>

Pretty much all of the FlightGear GUI is defined in XML space, except for a few oddments. Let’s say 95% at this point.

Additionally, even if we were to change that for the core sim (and James' current plan is to keep the XML syntax and just extend it), the installed base of '''aircraft''' ship their own XML dialogs (eg., replacing the autopilot dialog with a custom one, or just adding their own aircraft-specific helper controls for doors / lights / cargo / whatever). So even if we found the most sublimely beautiful, intuitive, compact GUI description language in the world, we have to keep the XML syntax working as-is, for the foreseeable future.

Given this, James' intention is to replace the output side [[PUI]] but keep the front-end side (XML / properties / bindings) unchanged, and therefore backwards compatible, and simply add some new types / options / widget types going forward. This will mean we still have to deal with the slightly cumbersome XML+Nasal syntax, but, well, it’s not *that* cumbersome. <ref>https://sourceforge.net/p/flightgear/mailman/message/37296280/</ref>

In mid 2021, James reported that he is working on some ‘PUICompat’ classes which hold/own/represent the GUI state in C++, but which can be used with [[Nasal/CppBind|Nasal CppBind]]. And of course we could indeed expose those later on. <ref>https://sourceforge.net/p/flightgear/mailman/message/37297727/</ref>

In July 2021, James suggested not to worry about the existing GUI code, it’s going in the bin.<ref>https://sourceforge.net/p/flightgear/mailman/message/37325905/</ref>

For the time being, the in-sim GUi can’t do Unicode yet, but James is working on it, hopefully available soon.<ref>https://sourceforge.net/p/flightgear/mailman/message/37328200/</ref>
Also, the in-sim menubar will change with the new GUI, *and* we use a native menubar on macOS. Until James replaces the PUI fonts we can’t use Unicode symbols. So, will have to come back to it once the new GUI is merged.<ref>https://sourceforge.net/p/flightgear/mailman/message/37327237/</ref>

=== 2020 ===
As of 03/2020, the PLIB replacement was reported to be in the backlog <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36951255/
|title = <nowiki>Re: [Flightgear-devel] C++ and/or OSG question </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Mar 18th, 2020
|added = Mar 18th, 2020
|script_version = 0.50
}}</ref>.

With PLIB replacement work likely being re-scheduled for [[Post FlightGear 2020.2 LTS changes]] <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36985375/
|title = <nowiki>Re: [Flightgear-devel] Working Group Proposal - Boost and PLIB replacement - Delegation and Teamwork </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = April 18th, 2020
|added = April 18th, 2020
|script_version = 1.10
}}</ref>.

In 08/2020, James stated that he was still working (exceptionally slowly!) on replacing PUI (as part of removing legacy OpenGL code (PUI, HUD, 2d panels, porting Canvas away form ShivaVG), so we can switch to Vulkan/VSG at some point (ideally at some point before Apple turn off OpenGL support…)), and that he doesn't think /any/ of us *want* to be working on these features particularly, but projects like these need to be done before anyone can have fun with VSG or Vulkan (personally James would be very enthusiastic about working on VSG support (being on macOS, I also have the most to lose / gain from it)). Sometimes that’s just how it goes. Equally they will all benefit the project ultimately, but the payoff both for the individual and the project is very drawn out. <ref>https://sourceforge.net/p/flightgear/mailman/message/37077158/</ref>

In 10/2020, the estimation is that PUI should be going away really ‘soon’, the replacement code is already in next / 2020.2. (There’s no plan to actually /use/ the new UI code in 2020.2, but if the bugs in it prove simple, we could actually turn it for specific dialog: it seems very unlikely this makes sense for a stable release however)<ref>https://sourceforge.net/p/flightgear/mailman/message/37123818/</ref>

The fixed-function removal, is actively in hand (Gaetan is working on the 2D panel part, and James is going to focus on PUI in the rest of 2020). James hopes that means next year he can focus on Vulkan, or at least, using OSG as if /were/ VSG, so the migration in a year or two when VSG is stable, is not so painful.<ref>https://sourceforge.net/p/flightgear/mailman/message/37129098/</ref>

The PUI UI and replacement can co-exist in the same build (they already do, effectively.<ref>https://sourceforge.net/p/flightgear/mailman/message/37131297/</ref>

In 11/2020, James suggested not to worry about details such as PUI styling/theming etc: we’re not making such changes for the LTS, and PUI should be gone before the next release.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142225/</ref> Also, he recommended (to everyone) to stop touching GUI stuff for a few weeks, as he's about to turn it all on its head.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142356/</ref>

=== 2019 ===
The new GUI has been incubating for a few years, but there's apparently been a lot of progress as of 10/2019.

It is likely the new GUI will be a user opt-in feature - at least initially. The sunset of the PLIB library _could_ happen relatively soon, but
people will need to see the new GUI and react to it before we could commit to PLIB removal <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36784489/
|title = <nowiki>Re: [Flightgear-devel] in Flightgear/Simgear C++ Code: What needs Doing? What are YOU Doing? What would you do if you had the time? </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Oct 14th, 2019
|added = Oct 14th, 2019
|script_version = 0.50
}}</ref>.

In 02/2019, James stated that the new UI is coming quite soon. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36589420/
|title = <nowiki> Re: [Flightgear-devel] Lagging </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Feb 17th, 2019
|added = Feb 17th, 2019
|script_version = 0.40
}}</ref>

=== 2018 ===
{{See also|QtQuick use in FlightGear}}

According to James, we have to accept that changes like testing or making [[PUI]] a modular thing or moving the JS code tend to have an immediate pain for some people (because strange stuff gets broken, and takes some time to get fixed), whereas the payoff in terms of improved joystick handling or replacing the UI or testing of all subsystems will take some months or years to be felt.<ref>https://sourceforge.net/p/flightgear/mailman/message/36323240/</ref>

James said he was in the middle of porting the launcher’s final tab (location) to the new UI scheme, once that’s done he will start sketching out the ‘in sim’ settings UI using the same pieces. He’ll send a request for contributions around about that in the next three-four weeks, once he has enough templates & examples that there is a clear pattern to follow.<ref>https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/2d10f16c-ddc8-07f3-07e7-eca2a0a0d55f%40zaretto.com/#msg36293586</ref>

James announced that the launcher is now feature complete with the QtQuick UI, he’ll keep making bug-fixes of course as people report them, but my todo list for the core features is now done<ref>https://sourceforge.net/p/flightgear/mailman/message/36355833/</ref>.

=== 2017 ===

In 10/2017, James said he was getting really close to having the PUI replacement UI suitable for beta-testing.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36067646/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 7th, 2017
|added = Oct 7th, 2017
|script_version = 0.40
}}</ref>

Originally, James was hoping to land the PUI replacement GUI in the last dev cycle in 2017 (at least as a proof-of-concept, probably not as the default UI), so wouldn’t expend lots of effort on things like collapsible sections which might be a lot of work with the current PUI/Canvas approaches, but are trivial with the new [[QtQuick use in FlightGear|QtQuick based UI scheme]].<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36059822/
|title = <nowiki> Re: [Flightgear-devel] Canvas MapLayer for OpenStreetMap, OpenAIP,
VFR Sectionals </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 1st, 2017
|added = Oct 1st, 2017
|script_version = 0.40
}}</ref>

Once the basic new UI is in place we can experiment with different re-arrangements easily, without being limited by PUI. (James expects PUI to live on as the default / alternate UI while this happens)<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36061229/
|title = <nowiki> Re: [Flightgear-devel] FGFS macOS Menubar </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 2nd, 2017
|added = Oct 2nd, 2017
|script_version = 0.40
}}</ref>

Technically, this entails replacing dialog.cxx with some code which builds up some special ‘PUI-Emulation’ QtQuick controls, so that existing dialogs (especially from Aircraft) continue to work. This mode will look somewhat ugly but hopefully no more ugly than PUI! And it helps that the set of widgets we have in PUI is limited, and the ‘tricky’ widgets (map, scrolling list, etc) are in the dialogs will will replace with new ones first.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068767/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

This PUI emulation isn't going to use any code from PLIB<ref>https://sourceforge.net/p/flightgear/mailman/message/36985303/</ref>, so what will remain from it in FG afterwards will be the FNT and JS components (reworked).<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068817/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> Florent Rougon </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

=== 2016 ===
We need to explore if Qt Quick or widgets is the better way to go, with a preference towards Qt Quick, since it will allow things closer to current PUI (semi-transparent widgets on top of the 3D content). It still allows creating separate windows too (Erik’s use case), but means we get consistent, custom theming on all platforms, since standard desktop look is not so nice for a flight-sim.

James intention is to make a QML-hosting OSG-drawable, and add this as a concept in Qt-enabled builds, then port some PUI dialogs to it, and see how easy / painful the process is. Hell create some QObjects which expose commands and the property tree and Nasal.

This has the advantage of not touching the OSG window at all, QtQuick simply provides some additional OpenGL rendering on top, which we pass events to - pretty much exactly the same as what we already do for PUI, and hopefully can co-exist with it. James got this working in a local OSG tree in a standalone demo, but that’s based on osgQt - he wants to see if he can make it work on a normal, non-Qt OSG window inside FlightGear.<ref>https://sourceforge.net/p/flightgear/mailman/message/35156051/</ref>

The idea is to host an XML dialog (Currently done with PUI) from Qt also. The question is if that can be done keeping ‘source compatibility’ exactly with the current UI XML and Nasal interface. It probably can be, but many of the PUI widgets have really ugly APIs, especially for combo-boxes, drop-down menus and scrolling lists, where it makes sense to map a Nasal class to a Qt ItemModel, which would be more elegant and easy to work with in both Nasal and integrate on the Qt side. But obviously would mean changing the dialog sources.

Of course, aircraft dialogs tend to be simpler, and not use the more complex PUI widgets, precisely for reasons like this, but that’s a limitation it would be best to remove.<ref>https://sourceforge.net/p/flightgear/mailman/message/35155721/</ref>


== References ==
{{Appendix}}

[[Category:PUI| ]]
[[Category:Rendering roadblocks]]

CUI

2023-04-21T09:50:46Z

Hooray: As of 09/2022, CUI is now the official PUI replacement, as per: https://sourceforge.net/p/flightgear/mailman/message/37701750/ - so no need, to link to the original proof-of-concept at Howto:Processing legacy PUI dialogs using Canvas

#REDIRECT [[PUI#Canvas_Emulation]]

Canvas news

2023-04-21T09:23:59Z

Hooray: /* PUI Emulation */

{{Canvas Navigation}}

This page is primarily intended to keep track of Canvas related core/fgdata changes and discussions, i.e. mainly of interest to people who are not able to follow the forum/devel list regularly, but who may still want to stay up to date regarding future Canvas developments (i.e. not including fgaddon).

Everybody is invited to help contribute to maintain this page and provide up-to-date information. Also, quoting/referincing devel/forum list talks is actively encouraged, too - to help provide the corresponding pointers back to the original discussion threads: [[Instant-Cquotes]].

{{Canvas Roadmap}}

== 2023 ==
=== Pango Text ===
{{Stub}}
[[File:Pango-text-03-2023.png|thumb|we'd use the Pango library with it's dependencies, write our ownrenderer and set_renderer(custom_renderer) on the rendering context ?If you think this is a good idea I'll look into it, if not - I have a pureOSG solution working, for fill color at least<ref>https://sourceforge.net/p/flightgear/mailman/message/37791568/</ref>]]
On the long hand we need to implement simple, GTK like markup support for
canvas.Text, mainly for easy selection handling (I have that working for
single-line text, but it's got visual artifacts and it would be incredibly
complicated to make it work for multi-line text), but there are other use
cases too (like syntax highlighting in the Nasal console, etc.).<ref>https://sourceforge.net/p/flightgear/mailman/message/37781788/</ref>

Successfully subclassed Pango::Renderer, and
I'm also successfully showing an osg::Texture2D as element on the canvas,
but when I try to copy an osgText::Glyph onto that texture, instead of a
glyph I get a noise texture instead … the other issue I'm having is some
ponter problem (a smart pointer of one CanvasPangoText instance only
getting deleted upon the creation of the next instance, which leads to it
wanting to delete something that was already deleted !?).
On both problems I'm somewhat stuck, so it would be great if @James Turner
<ja...@fl...> or @Hooray could take a look - the latest code is
available at git.code.sf.net/u/thefgfseagle/simgear.git / branch
canvas_pangotext, in
simgear/canvas/elements/{CanvasPangoText,PangoRendererCanvas}.cxx<ref>https://sourceforge.net/p/flightgear/mailman/message/37795860/</ref>

And the new element can be tested with the following Nasal code, after
checking out the canvas_pangotext branch from
git.code.sf.net/u/thefgfseagle/fgdata <ref>https://sourceforge.net/p/flightgear/mailman/message/37795864/</ref>:
<pre>
w = canvas.Window.new([200, 200], "dialog");
c = w.createCanvas();
g = c.createGroup();
t = g.createChild("pangotext");
t.setMarkup("bold");
w.show();
</pre>

=== PUI Emulation ===
{{Main article|PUI}}

[[File:Gc-monitoring-via-new-canvas-proptree-widget.png|thumb|Screen shot showing a [[Canvas GUI]] dialog rendering the new [[Property browser]] dialog based on porting the legacy [[PUI]] widget, showing GC stats]]
01/2023: James slowly working on creating the pop-up menu and combo-box widgets [...] We need to figure out the split of DefaultStyle.nas, but James is very keen to ensure we add a second style alongside the default, before we change much here.

Regarding styling, James is worried about us ending up putting code into the wrong side of the widget / Style split, if we don’t have a second alternative style implementation to ‘keep us honest’<ref>https://sourceforge.net/p/flightgear/mailman/message/37756178/</ref>

We really have two kinds of ’styles’

* tweaking margins, font sizes, colours etc should indeed be done in XML as you wrote : this is also analogous to styles in the PUI sense

* making radically different ways of presenting the same logical widgets: eg text label of checkbox in a different position relative to the button (of Surface vs Material vs iOS style, if you know web/mobile UIs)

For the second kind we would use a different Nasal style implementation and that’s the abstraction I think it is very important to maintain. It of course going to be a lot of work to make additional styles this way but it’s a very valuable feature to keep the possiblity, since it enables alternate UIs for user accessibility or different presentation modes such as VR.

What I don’t want to do is add lots of widgets assuming we only care about DefaultStyle.nas, and then have an impossible mountain to climb when someone needs an alternate Nasal style. We don’t have to make a complete alternate style now, but I don’t want to take shortcuts the make it impossible in the future. So I want to really think carefully about what is widget code and what is style code. <ref>https://sourceforge.net/p/flightgear/mailman/message/37756261/</ref>

One of the major things slowing down James' work on the popup-menu and combo box is time to restart the simulator for each change, he is looking for some solution to re-load the widget Nasal code independently. <ref><https://sourceforge.net/p/flightgear/mailman/message/37756183/</ref>

James has done about 75% (hah!) of the C++ work to enable live reloading of modules this way, but unfortunately there are some code paths that would become crashy if you use the feature for the Canvas: because it would reference the ‘old’ (pre-reload) Nasal code, and not the new one, and therefore you’d get a weird mix of old and new, and then just crash the sim. To fix it properly I need to track down those places that store a reference to Canvas and give them a re-init method, so we don’t keep the stale references.

The general non-fun-ness of that kind of debugging is why I’ve been making such slow progress on my PUI replacement widgets recently <ref>https://sourceforge.net/p/flightgear/mailman/message/37756263/</ref>

== 2022 ==
=== ListView Widget ===
[[File:Logbook-v.1.1.0.png|thumb]]
For the [[Logbook Add-on]], PlayeRom implemented a ListView canvas widget that can be reused by others, so he sent a merge request with this widget.<ref>https://sourceforge.net/p/flightgear/mailman/message/37754894/</ref>

see also {{Merge-request|project=fgdata|id=304|text=Merge request:Canvas ListView implementation}}
=== Tab Widget ===
[[File:Canvas TabWidget example.png|thumb]]
[[File:TabWidget.png|thumb|TheEagle's tab widget]]
FGFSEagle needed a tab widget for his C310, so he did a quick implementation inspired
by FGAddon/trunk/Aircraft/f16/Nasal/canvas/gui/widgets/Tabs.nas.

The plan is to add scrolling / reordering / closing support for the tabs later. <ref>https://sourceforge.net/p/flightgear/mailman/message/37751388/ </ref>

Learn more at [[Canvas snippets#Using_TabWidgets]]

For the merge request, see see {{Merge-request|project=fgdata|id=303|text=Canvas tab widget implementation}}

For the underlying idea, refer to: [[PUI#Replacement status]]

=== Releasing Canvas textures ===
{{Stub}}

we'd need some kind
of way to delete the texture without deleting the window, redrawing the
texture when the window is reopened ? Starts to sound complicated … but on
the other hand, all windows on the Extra 500 use a custom Window class
which does something similar … <ref>https://sourceforge.net/p/flightgear/mailman/message/37719030/</ref>
I've updated the code to directly hide the window when the close button is
pressed, and also fixed a bug which consisted of the windows automatically
showing (which is not desired when the window is constructed at startup and
should only be shown later). New patch attached.
As for memory usage, I did a test - 100 1000x1000 px canvas windows, all
with destroy_on_close = 0. constructing them didn't give a significant
increase in memory usage - only upon showing them all at once, the RAM
usage went up by 2 GB. that's quite a lot you might say, but 1) most
dialogs are not as big as that and 2) which user opens 100 dialogs in one
session ? In most cases it won't be more than 10 = 200 MB RAM (if all
dialogs were using this new behaviour) - and the default behaviour is to
destroy the window on closing anyways (destroy_on_close = 1 by default, you
got to explicitly set it to 0 to get the new behaviour, also to maintain
backwards compatibility), so I think this won't be an issue.<ref>https://sourceforge.net/p/flightgear/mailman/message/37719123/</ref>

What we’d ideally want is a C++ change so that hidden canvases release their texture memory : it’s created the first time the canvas is rendered, which is why the memory is fine until you actually show them.

200MB memory is not great, but the bigger problem is the GPU-side memory : 200MB of VRAM is much more ‘valuable’ for textures than for keeping the backing store of hidden dialogs. So I would definitely say use this feature sparingly, until someone adds some C++ logic to destroy the backing texture for hidden canvas windows.<ref>https://sourceforge.net/p/flightgear/mailman/message/37720688/</ref>

For this window behaviour one, I’ve applied it since it’s an opt-in change, but I suspect we may end reviewing this API a little, so I’d suggest not building lots of dialogs across different aircraft, which depend on this behaviour, until we get a bit more experience with it.

So use it, gain some understanding, but maybe we discover in 6 months that it’s a bad idea and have to revert it. (That’s the worst case, but it is kind of a radical change in the lifetime / memory usage of the Canvas, so I just want to mention the worst possibility) I’m 90% sure we can keep this API, so long as we improve the C++ behaviour to release the texture / FBO memory of hidden canvases, which is a reasonable thing to do anyway, it just needs someone to have the time to implement that, and right now, I certainly don’t.<ref>https://sourceforge.net/p/flightgear/mailman/message/37720701/</ref>

=== Replacing PUI ===
{{See also|PUI#Replacement_status}}

Update 09/2022: The PUI replacement was going to be Qt but it started to get very complicated with changes in Qt 5.15 + Qt 6, so James is going with a more light-weight, Canvas-based, approach now.

Qt added support for Vulkan / Metal / D3D starting in 5.15, but FlightGear / OpenSceneGraph can’t support those, so integrating the two renderers went from being ‘complicated but ok’ to ‘very very complicated’.

So now James is going with something much more lightweight using some C++ compatibility code, some Nasal for styling and the existing widget rendering from Thomas Geymayer (TheTom) with some extensions and additions: some pieces are in FlightGear & FGData already.

James has basic dialogs working okay but not the more complex ones and everything looks kind of ugly, he needs to improve the visual look before he shares screenshots to avoid everyone freaking out :) The disadvantage of this approach is James is far from expert at creating visual appearances this way, so it’s kind on unrewarding and slow for him. If someone likes messing with CSS-type styling, border-images and hover-states, ping him since we could probably move things also faster <ref>https://sourceforge.net/p/flightgear/mailman/message/37701750/</ref>

The PUI limitations should be gone ‘soon’: actually James is now focused on getting dialogs working; on macOS we use a native menubar (not PUI) inside FG which can handle sub-menus just fine.

If someone out there wants to work on the UI for menus / menubar part, just ping him directly, he can suggest some steps to start working that way. (Basically creating the view code in Nasal for menu items, menus and the menubar, and handling the different visual states of the above, such as an item being disabled, showing the keyboard shortcut, eliding too-long item names, hover feedback, timers to open menus / sub-menus on mouse-over: it’s all pretty standard stuff)

This does *also* need C++ parts, because the internal menubar structure /also/ needs some additions to support sub-menus, and the add-ons themselves would likely need some tweaks in the XML to integrate with that. So in total there are quite a few changes in this ’simple’ request, but this is often the way with software development :)<ref>https://sourceforge.net/p/flightgear/mailman/message/37701747/</ref>

{{Main article|pui2canvas}}

In February 2022, James reported having something in progress locally, and that should even be something we can try in March/April 2022. Hopefully that’s quick enough, knowing it has been a long time coming.<ref>https://sourceforge.net/p/flightgear/mailman/message/37606439/</ref>

It’s split between Simgear (see classes with widget / layout in the name) and in FGData. (Eg widgets/Button.nas) To be able to use the existing dialog XML files un-modified (which is a design goal), James is extending the widget types with many additional ones (eg PUI has slider, dial, combo-box, checkbox, all of which need to be created - this is about 30% done and is the bit he's very slow at). Thomas’s widgets have a very good separation of API + state from appearance, so all styling is in its own file, and James is being very strict about maintaining this separation, so we also retain the re-styling feature of the PUI UI, which many people also rely on. This does make the process of adding new widgets more complex, however.

The other thing is to preserve all the layouting : James has added a grid layout to Simgear, since that is supported by the existing PUI code (even though the layouts are not actually part of PUI itself). The problem is getting the sizing / hinting of all the widgets to match the PUI values, so that dialogs look approximately the same under the new UI as they did with PUI; again this a design goal so that all existing dialogs in aircraft and add-ons, which we can’t update, continue to work and be usable. Debugging that is also proving quite tricky, since there’s all kinds of hard-coded assumptions built into PUI widgets about pixels, font-sizes etc which are not true in the new system.<ref>https://sourceforge.net/p/flightgear/mailman/message/37701792/</ref>

=== XMLDialog.nas ===

{{Main article|pui2canvas}}

There's now an XML to Nasal bridge, to keep PUI dialogs working (Disabled by a CMake option)
This is implemented on top of the [[Canvas]] system.

James reported having something in progress locally, and that should even be something we can try in 2022. Hopefully that’s quick enough, knowing it has been a long time coming.<ref>https://sourceforge.net/p/flightgear/mailman/message/37606439/</ref>

The new code builds equivalent C++ objects to what the [[PUI]] dialogs build, with properties exposed to [[Nasal]].

Peer objects are created by Nasal [[callbacks]], which can implement the various dialog functions needed to keep compatibility, especially the ‘update’ and ‘apply’ hooks.<ref>https://sourceforge.net/p/flightgear/flightgear/ci/cbd5ef9e7b8f433dbc1ba97bae7d7cfc894e7cef/</ref>

Use the following [[Building using CMake|cmake option]] to enable this code: <code>-DENABLE_PUICOMPAT=ON</code>

The new Compatibility files can now be found in $FG_SRC/GUI:

* {{flightgear file|src/GUI/FGPUICompatDialog.cxx }}
* {{flightgear file|src/GUI/FGPUICompatDialog.hxx }}
* {{flightgear file|src/GUI/PUICompatObject.cxx }}

The corresponding Nasal/Canvas module to dynamically "translate" legacy PUI/XML dialogs into Canvas dialogs (at runtime), is to be found in {{fgdata file|Nasal/gui/XMLDialog.nas}} <ref>https://sourceforge.net/p/flightgear/fgdata/ci/fe7c87b21a69f88ddb87d89453c48d12b69660e2/</ref>

=== Core Profile support / replacing ShivaVG ===
[[File:ShivaVG.jpg|thumb|Here is a comparison between ShivaVG and ShaderVG.Look at the Canvas Dialog top left and particularly the vertical airspeed bars <ref>https://sourceforge.net/p/flightgear/mailman/message/37610774/</ref>]]
[[File:ShaderVG.jpg|thumb|Here is a comparison.Look at the Canvas Dialog top left and particularly the vertical airspeed bars<ref>https://sourceforge.net/p/flightgear/mailman/message/37610774/</ref>]]

{{Main article|Shiva Alternatives}}
We need to remove [[PUI]] and change the [[Canvas]] not to use ShivaVG ([[Canvas Path]] back end), to be ES2 compatible or Core-profile compatible.<ref>https://sourceforge.net/p/flightgear/mailman/message/36194973/</ref>

To support [[Canvas]] on [[OpenGL]] [[FlightGear and OpenGL ES|Core profile]], the plan is to migrate from [[Shiva]] to ‘something else’ which implements the required drawing operations. Unfortunately two of the probable solutions (Skia from Chrome and Cairo from Gtk) are both enormous and a pain to deploy on macOS and Windows.

{{See also|Unifying the 2D rendering backend via canvas}}
As part of the Core profile migration, we need to replace ShivaVG (which is the functional guts of Path.cxx) with a shader based implementation, ideally NanoVG, although Scott has indicated this might not be as easy as originally hoped. <ref>https://sourceforge.net/p/flightgear/mailman/message/37605458/</ref>

Early experiments (patch [https://sourceforge.net/p/flightgear/mailman/message/37610741/]) in 02/2022 with ShaderVG were promising and suggest, that it ‘kind of sort of’ works, that’s already less work than integrating NanoVG.<ref>https://sourceforge.net/p/flightgear/mailman/message/37610750/</ref>

For the time being, it's not a one on one drop in replacement but it works quite nicely:
* For one the x,y positions are off comapared to ShivaVG making things slightly bigger (maybe too big for the screen).
* and one issue with the "title bar" being opaque.<ref>https://sourceforge.net/p/flightgear/mailman/message/37610740/</ref>

== 2021 ==
=== Moving Canvas Rendering to a separate OpenGL Context ===
{{Main article|Howto:New Canvas Execution Model}}
[[File:Pbuffer-based-canvas-startup.png|thumb|fgfs initialization with pbuffer based addCamera() modification in renderer.cxx to create canvas cameras in a dedicated GL context]]

[[File:Pbuffer-based-canvas-cams.png|thumb|pbuffer based canvas cams used for offscreen rendering, but also to move canvas rendering out of the main loop (in conjunction with aggressive OSG threading via )
This shows disabled context sharing and use a separate osg::Image to copy the texture from one GL context to another (the CPU being the bottleneck, unless we can use a shader or PBO to do this)]]

[[File:Fgfs-20210904184748.png|thumb|This screen shot shows the FG1000 running in a patched fgfs version where Canvas Cameras are attached to an OpenGL context running in another thread. Synchronization with the main thread is not accomplished using a shared context, but instead using an osg::Image (which considerably slows down things, as can be seen in the stats above)]]

Early experiments moving Canvas rendering out of the main loop by using aggressive OSG threading in conjunction with a separate GL context for Canvas cams, and subsequently, with also moving Nasal (and Property Tree I/O) out of the main loop by using a dedicated thread per Canvas [Texture], probably with its own FGNasalSys instance and related subsystem machinery (mainly, events/timers).

=== Dedicated prerender cams ===
{{See also|Post_FlightGear_2020.2_LTS_changes#Canvas}}
2021-08-27: Fernando has begun working on moving Canvas cameras out of the scene graph into dedicated PRERENDER cams in the viewer (This was a long-standing issue where Canvas cameras were rendered multiple times, once per slave camera. In the case of the Classic pipeline they were being rendered twice.), see:
* {{flightgear commit|83b0a3}}
* {{simgear commit|a97e14}}

== 2020 ==
=== Canvas EFIS Framework ===

The '''canvas EFIS framework''' (created by jsb) is by-product of the EFIS development
done for the CRJ700 family, which uses Rockwell Collins Proline.
It is published as a separate framework in the hope that it is useful for other aircraft as well,
however some features may be rather specific.
The biggest motivation and primary design goal was to support "near optimal"
performance but that does not come automatically of course.

{{Main article|Canvas EFIS Framework}}

== 2019 ==
placeholder for next year

== 2018 ==
=== Compositor ===
{{Main article|Compositor}}

[[File:Compositor-08-2018.png|right|thumb|A screenshot showing post-processed gaussian blur and a blue filter:[https://i.imgur.com/Zzxre8a.png]]]
{{Usr|Icecode}} has been working on and off on multi-pass rendering support for
FlightGear since late 2017. It went through several iterations and
design changes, but he think it's finally on the right track. It's
heavily based on the Ogre3D Compositor and inspired by many
data-driven rendering pipelines. Its features include:

* Completely independent of other parts of the simulator, i.e. it's part of SimGear and can be used in a standalone fashion if needed, ala Canvas.
* Although independent, its aim is to be fully compatible with the current rendering framework in FG. This includes the Effects system, CameraGroup, Rembrandt and ALS (and obviously the Canvas).
* Its functionality overlaps Rembrandt: what can be done with Rembrandt can be done with the Compositor, but not vice versa.
* Fully configurable via a XML interface without compromising performance (ala Effects, using PropertyList files).
* Optional at compile time to aid merge request efforts.
* Flexible, expandable and compatible with modern graphics.
* It doesn't increase the hardware requirements, it expands the hardware range FG can run on. People with integrated GPUs (Intel HD etc) can run a Compositor with a single pass that renders directly to the screen like before, while people with more powerful cards can run a Compositor that implements deferred rendering, for example.

Unlike Rembrandt, the Compositor makes use of scene graph cameras
instead of viewer level cameras.

This allows CameraGroup to manage windows, near/far cameras and other
slaves without interfering with what is being rendered
(post-processing, shadows...).

The Compositor is in an usable state right now: it works but there are
no effects or pipelines developed for it. There are also some bugs and
features that don't work as expected because of some hardcoded
assumptions in the FlightGear Viewer code. Still, I think it's time to
announce it so people much more knowledgeable than me can point me in
the right direction to get this upstream and warn me about possible
issues and worries. :)

=== Aircraft Dialogs ===
Some of you may already know that the current tool to generate the dialogs ([[PUI]]) is going to disappear in the mid-future. After some (partially controversial) discussion, there seems now to be some support for the idea that canvas is a good tool to generate aircraft-specific dialogs in the future <ref>https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/93862C87-0D3E-47BB-B169-8D3CBBF963B7%40kdab.com/#msg36194973</ref> (as it allows to tailor the dialog closely to the plane and also, canvas being canvas, the UI can smoothly mesh with the 3d models, so you can project a canvas checklist onto a 3d model in sim for instance rather than a popup window).

Thorsten would very much like to claim to be pioneering this approach, but in fact he believes the [[Extra EA-500|Extra-500 team]] is - look at the [[Extra_EA-500/failure_dialog|failure dialog of that plane]] where you can click the components you want to fail and you see what he means!

[[File:Extra500-Failuredialog-deice.png|right|thumb|500px|Extra 500 - failure dialog - de-ice]]

Anyway, Thorsten has started to roll out a few designs of his own and try to keep the tools fairly general so that they can be re-used by others- so here's the revised version of the Shuttle propellant dialog.

[[File:Propellant dlg02.jpg|thumb|right|an example of the detail dialog which allows to set levels of fuel and oxidizer separately (and the overview dialog shows the usable propellant then, i.e. the minimum of the two) - for aircraft, this would be somewhat simpler.]]

The general idea is to use semi-transparent 'content gauges' on a background raster image to show where the tank is located and how full it currently is - double-clicking any tank will bring up a detail window which allows to set the content (here propellant and oxidier separately, this is rocket fuel...) and also shows the current tank pressures and temperatures.
The whole thing can readily be applied on top of a different raster image with a different number of tanks - you just instance and position the labels and 'gauges' you need - in fact placement is probably what's going to take longest (at least for me).
The whole thing is currently in flux <ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=326789&sid=c15d338facab18fb091aa0530f5dfa0f#p326789
|title = <nowiki> Aircraft-specific dialogs </nowiki>
|author = <nowiki> Thorsten </nowiki>
|date = Jan 24th, 2018
|added = Jan 24th, 2018
|script_version = 0.36
}}</ref>
If anyone wants to follow the development or use the code, it's here:
https://sourceforge.net/p/fgspaceshuttledev/code/ci/development/tree/Nasal/canvas/canvas_dialogs.nas

=== Plot2D ===

[[File:Oscilloscope.png|thumb|rleibner's new Oscilloscope addon is working.This screenshot shows the usual c172p "magnetos checking" Channel 1 (yellow) is '''rpm''' (100 rpm / div).Channel 2 (mauve) is '''magnetos''' (1 / div).Time sweep is 200 ms / div.The idea is to share it as an addon. Mainly to have some feedback about plot2D/graph.<ref>{{cite web |url = https://forum.flightgear.org/viewtopic.php?p=325929#p325929 |title = <nowiki> Re: Plot2D and graph helpers </nowiki> |author = <nowiki> rleibner </nowiki> |date = Jan 6th, 2018 |added = Jan 6th, 2018 |script_version = 0.36 }}</ref>]]

== 2017 ==
=== Vertical Situation Display ===
[[File:Rleibner-canvas-vsd-12-2017.png|thumb|rleibner is developing a graph class that works using local (customized) coordinates and calls the plot2D helpers (see below).For testing (and as exercise) he came up with a VSD (Vertical Situation Display): <ref>https://forum.flightgear.org/viewtopic.php?f=71&t=33457#p324637</ref>]]
rleibner is developing a graph class that works using local (customized) coordinates and calls the plot2D helpers (see below).
For testing (and as exercise) he came up with a VSD (Vertical Situation Display): <ref>https://forum.flightgear.org/viewtopic.php?f=71&t=33457#p324637</ref>

=== Plot2D Helpers ===
[[File:Plot2D.rectangle and grid.png|thumb]]

[[File:Plot2D.polyline.png|thumb|plot2D.polyline example]]

[[File:Graph examples.png|thumb|rleibner's Canvas plotting framework implemented in Nasal <ref>https://forum.flightgear.org/viewtopic.php?f=30&t=32882&start=90</ref>]]

'''Plot2D''' is nothing more than a collection of helpers that aims to facilitate the task of coding. It makes intensive use of the [[Canvas Nasal API|Canvas API]], a mandatory reference for those who intend to refine the result beyond what is offered by plot2D. 
It is assumed here that you already have a minimal knowledge about [[Canvas]]. 
For now '''Plot2D''' resides in the '''SpokenGCA''' addon, but the idea is that in the future it could be included in the $FG-ROOT/Nasal/canvas directory. 

Continue reading at [[How to manipulate Canvas elements]] ...

=== FG1000 ===
Here is a little update o the G1000 emulation. Stuart has now got the key [[MapStructure]] layers in place, though they are not styled correctly for the '''G1000''' yet and Stuart would like to replace some of them (airspace in particular) with vector data, and started on the MFD architecture. For prototyping he hacked together a [[PUI]] dialog box, which speeds up development massively as it reloads all the Nasal code each time it's opened.

There's a screenshot of it here: [[File:Fg1000_mfd.jpg|thumb|right]]

There's also a wiki page of the current status here: http://wiki.flightgear.org/FG1000 Next steps are to get the MFD architecture in place - this will probably require some changes to Richard's generic [[Canvas MFD Framework|MFD]] to support buttons that don't change the MFD pages better. Stuart has not yet pushed this to fgdata - he'll wait until he's happy with the overall architectures so that there is a solid base for anyone else interested in helping out.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36103513/
|title = <nowiki> [Flightgear-devel] FG1000 update </nowiki>
|author = <nowiki> Stuart Buchanan </nowiki>
|date = Nov 4th, 2017
|added = Nov 4th, 2017
|script_version = 0.40
}}</ref>
=== CanvasWidget and PUI ===
James pushed a change which changes how we integrate [[PUI]] into the renderer and other systems <ref>https://sourceforge.net/p/flightgear/flightgear/ci/804dc4e74ab921f196ca5e09eb7cd6de74b09c0d/</ref>; this makes our PUI usage more modular, so it can be enabled / disabled in a standard way. It also renders PUI via an FBO so we can use it safely (and scale it) on HiDPI screens, since PUI is too old to support a scaling factor as more modern UI toolkits would do. I’ve done a fair amount of testing, and everything seems to be working, but if you see any changes in how PUI reacts to mouse or key presses, or the appearance of things, please let James know via the issue or devel mailing list. It’s using the same code as it always did but starting from a slightly different place, both in terms of drawing and event handling. One temporary regression: right now CanvasWidget (the mechanism by which we include canvas content into PUI) is messed up because previously PUI had no alpha channel, so the canvas’s alpha was ignored.

With the new system, the alpha is actually being used, but this is not really desired - it shows up as a semi-transparent map background in the ‘Select airport’ airfield chart, and the Map-Canvas window at least. James thought he had a work-around for this, but the one he came up with is awkward to support on Windows, he still needs to think on a better solution, so in the meantime he pushed a hack so at least Windows still builds and runs <ref>https://sourceforge.net/p/flightgear/flightgear/ci/c1df6e9d1528fc2513c6f455f0c0ccc6ca74e34a/</ref>. (If your canvas content inside PUI has an opaque background, you’ll be fine, so one fix is just to adjust the Canvas code for those dialogs, but James would like to find a backwards compatible fix)<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36084254/
|title = <nowiki> [Flightgear-devel] PUI non-change, CanvasWidget appearance </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 20th, 2017
|added = Oct 20th, 2017
|script_version = 0.40
}}</ref>

===MapStructure used by airports.xml ===
[[File:Airport-selection dialog updated to use MapStructure.png|thumb|Screenshot showing a the [[PUI]] based airports.xml dialog with an embedded [[Canvas]] widget feature a [[MapStructure]] based airport diagram developed by Stuart]]
Stuart has committed some changes <ref>https://sourceforge.net/p/flightgear/fgdata/ci/d84c527ca747dd6bbd9634507f0664ff3631bdef/</ref> to update the Select Airport dialog to use [[Canvas MapStructure]] Layers to display airport information, rather than the now deprecated map layers. The change should be largely transparent to end users - the only significant change is that your can display navigation symbols. This is all part of a long-term effort to provide the building blocks for a Garmin G1000 - these layers could be used for the airport display on the MFD, and could easily be combined with the APS layer to show a moving aircraft.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36075357/
|title = <nowiki> [Flightgear-devel] Updated Select Airport dialog </nowiki>
|author = <nowiki> Stuart Buchanan </nowiki>
|date = Oct 13th, 2017
|added = Oct 13th, 2017
|script_version = 0.40
}}</ref>

=== Canvas Slippy Maps ===
[[File:StuartsSlippyMap1.png|thumb|Stuart pushed some changes to fgdata with OpenStreetMap, OpenAIP and VFRMap layers for the Canvas Map Layer system, which can be seen on the canvas map dialog. They use a generic Slippy Map OverlayLayer Map Layer. Additional web-based mapping can be trivially added by creating a new lcontroller. See Nasal/Canvas/map/OpenAIP.lcontroller for an example.I've also added a Web Mercator Projection to the Canvas Map support.The wiki will be updated shortly.<ref>{{cite web |url = https://forum.flightgear.org/viewtopic.php?p=319545#p319545 |title = <nowiki> Re: Canvas G1000 </nowiki> |author = <nowiki> stuart </nowiki> |date = Sep 28th, 2017 |added = Sep 28th, 2017 |script_version = 0.40 }}</ref>]]

[[File:StuartsSlippyMap2.png|thumb|Stuart pushed some changes to fgdata with OpenStreetMap, OpenAIP and VFRMap layers for the Canvas Map Layer system, which can be seen on the canvas map dialog. They use a generic Slippy Map OverlayLayer Map Layer. Additional web-based mapping can be trivially added by creating a new lcontroller. See Nasal/Canvas/map/OpenAIP.lcontroller for an example.I've also added a Web Mercator Projection to the Canvas Map support.The wiki will be updated shortly.<ref>{{cite web |url = https://forum.flightgear.org/viewtopic.php?p=319545#p319545 |title = <nowiki> Re: Canvas G1000 </nowiki> |author = <nowiki> stuart </nowiki> |date = Sep 28th, 2017 |added = Sep 28th, 2017 |script_version = 0.40 }}</ref>]]

[[File:StuartsSlippyMap3.png|thumb|MapStructure OpenAIP layer created by Stuart for the ongoing G1000 effort]]

[[File:StuartsSlippyMap4.png|thumb|MapStructure OSM (OpenStreetMap) layer created by Stuart for his ongoing G1000 effort]]

[[File:Slawek-stamen-maps.png|thumb|Regarding mailling list talk: https://sourceforge.net/p/flightgear/mailman/message/36059733/ and some information in G1000 canvas topic (https://forum.flightgear.org/viewtopic.php?f=71&t=32764There is commented out three different map styles (terrain + overlay, terrain, toner). One can apply this patch to get new tile rendering.<ref>{{cite web |url = https://forum.flightgear.org/viewtopic.php?p=319802#p319802 |title = <nowiki> Canvas MapLayer for OSM, OpenAIP, VFR Sectionals and other </nowiki> |author = <nowiki> slawekmikula </nowiki> |date = Oct 2nd, 2017 |added = Oct 2nd, 2017 |script_version = 0.40 }}</ref>]]

Stuart wants to build a set of Canvas MapStructure layers for a G1000 implementation - the canvas map UI is really just a way to display it.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36059733/
|title = <nowiki> Re: [Flightgear-devel] Canvas MapLayer for OpenStreetMap, OpenAIP,
VFR Sectionals </nowiki>
|author = <nowiki> Stuart Buchanan </nowiki>
|date = Oct 1st, 2017
|added = Oct 1st, 2017
|script_version = 0.40
}}</ref>

* SimGear: https://sourceforge.net/p/flightgear/simgear/ci/a800189c25a3fb4610c1e36655940a95694c4a84/
* FGData: https://sourceforge.net/p/flightgear/fgdata/ci/85b7665c19ebaae02d746fef53f25f8d8974eb13/<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=319550#p319550
|title = <nowiki> Re: Canvas G1000 </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Sep 28th, 2017
|added = Sep 28th, 2017
|script_version = 0.40
}}</ref>

Stuart added some new Nasal Canvas MapLayers to support Slippy Maps, as used by most web-based mapping services such as openstreetmap. This allows us to display sectional charts (for the US - vfrmap.com), and airspace information (courtesy of openaip.org), as well as a openstreetmap data. The canvas Map dialog has been updated to support these layers. Map data is retrieved over http and cached locally.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36056088/
|title = <nowiki> [Flightgear-devel] Canvas MapLayer for OpenStreetMap, OpenAIP,
VFR Sectionals </nowiki>
|author = <nowiki> Stuart Buchanan </nowiki>
|date = Sep 28th, 2017
|added = Sep 28th, 2017
|script_version = 0.40
}}</ref>

fgdata with OpenStreetMap, OpenAIP and VFRMap layers for the Canvas Map Layer system, which can be seen on the canvas map dialog. They use a generic Slippy Map OverlayLayer Map Layer. Additional web-based mapping can be trivially added by creating a new lcontroller. See Nasal/Canvas/map/OpenAIP.lcontroller for an example.
Stuart has also added a Web Mercator Projection to the Canvas Map support.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=319545#p319545
|title = <nowiki> Re: Canvas G1000 </nowiki>
|author = <nowiki> stuart </nowiki>
|date = Sep 28th, 2017
|added = Sep 28th, 2017
|script_version = 0.40
}}</ref>

=== Canvas VSD / Vertical MapStructure Layers ===
{{See also|Howto:Implement a Vertical Situation Display in Nasal}}
A few years ago, Omega95 created a Canvas VSD [[File:VSD-prototype-by-omega95.png|right|250px]]<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=291908#p291908
|title = <nowiki> Re: Trying to experiment </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Aug 5th, 2016
|added = Aug 5th, 2016
|script_version = 0.40
}}</ref>

Recently, clm76 adapted Omega95's original Canvas VSD to the CitationX<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=319234#p319234
|title = <nowiki> Re: Spoken GCA </nowiki>
|author = <nowiki> clm76 </nowiki>
|date = Sep 23rd, 2017
|added = Sep 23rd, 2017
|script_version = 0.40
}}</ref>

[[File:Clm76-vsd-10-2017.png|thumb|clm76 adapted the Omega95's VSD to the CitationX :<ref>{{cite web |url = https://forum.flightgear.org/viewtopic.php?p=319234#p319234 |title = <nowiki> Re: Spoken GCA </nowiki> |author = <nowiki> clm76 </nowiki> |date = Sep 23rd, 2017 |added = Sep 23rd, 2017 |script_version = 0.40 }}</ref>]]

=== Canvas + Effects goes Deferred Rendering ===
Icecode GL has been experimenting with effects/shaders support for Canvas and got something kind of dirty and primitive but it works:

[[File:Canvas+Effects vs deferred.png|thumb|been experimenting with effects/shaders support for Canvas and Icecode GL got something kind of dirty and primitive but it works]]

It works similarly to how Rembrandt does its buffers. There is a new texture type called "canvas" that allows shaders to access any canvas texture via a texture unit, just like you'd access a normal texture from the hard drive. This removes (most) limitations of addPlacement, which can only substitute the "base" texture (unit 0). The posibilities are endless, it just needs some care and work. At the moment we could have shadow mapping outside Rembrandt just by creating a new view placed at the Sun and make it render the depth buffer to a canvas. Then every ALS shader could access this canvas and do the shadow comparison thingy. Planar reflections in the water should be kind of trivial as well, it'd just require the model-view matrix to be multiplied by a reflection matrix and the water shader could just paste the result over the water surface (with some more fancy calculations to make it pretty of course).<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=318662#p318662
|title = <nowiki> Re: Canvas:View development </nowiki>
|author = <nowiki> Icecode GL </nowiki>
|date = Sep 11th, 2017
|added = Sep 11th, 2017
|script_version = 0.40
}}</ref>

=== Canvas & Slave Cameras ===
{{See also|Howto:Canvas View Camera Element}}

[[File:Canvas-view-element-prototype-by-icecode gl.png|thumb|upright|[[Canvas]] gui dialog with a custom canvas element to display view manager views (based on code prototyped by F-JJTH)]]

[[File:F-JJTH-SlavedCams-Instrument-09-2017-one.png|thumb|First screenshot created by Alant, view from the rear cockpit of TSR2, showing the the custom "camera-display" prototyped by F-JJTH, just to the left of the moving map.Known issue: despite flying more or less straight and level, the image camera point can be seen to jump around between screenshots. <ref>{{cite web |url = https://forum.flightgear.org/viewtopic.php?p=317486#p317486 |title = <nowiki> Re: Gear view in cockpit computer </nowiki> |author = <nowiki> Alant </nowiki> |date = Aug 26th, 2017 |added = Aug 26th, 2017 |script_version = 0.40 }}</ref>]]

[[File:F-JJTH-SlavedCams-Instrument-09-2017-two.png|thumb|Second screenshot created by Alant, view from the rear cockpit of TSR2, showing the the custom "camera-display" prototyped by F-JJTH, just to the left of the moving map.Known issue: despite flying more or less straight and level, the image camera point can be seen to jump around between screenshots. <ref>{{cite web |url = https://forum.flightgear.org/viewtopic.php?p=317486#p317486 |title = <nowiki> Re: Gear view in cockpit computer </nowiki> |author = <nowiki> Alant </nowiki> |date = Aug 26th, 2017 |added = Aug 26th, 2017 |script_version = 0.40 }}</ref>]]

Former FlightGear core developer F-JJTH shared a patch <ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=317448#p317448
|title = <nowiki> Re: Gear view in cockpit computer </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Aug 26th, 2017
|added = Aug 26th, 2017
|script_version = 0.40
}}</ref> implementing a proof-of-concept to render an arbitrary slave view to a FBO/RTT using a new dedicated "camera-display" instrument. This would be the kind of functionality required to implement many interesting features that cannot currently be added easily; Rear view mirrors in fighters could become a reality, as well as camera displays in SAR helicopters, outside views in airliners, backing view displays in cars etc.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=317462#p317462
|title = <nowiki> Re: Gear view in cockpit computer </nowiki>
|author = <nowiki> Johan G </nowiki>
|date = Aug 26th, 2017
|added = Aug 26th, 2017
|script_version = 0.40
}}</ref>

The patch seems not to break anything else, and does nothing unless the aircraft side code is added. It is therefore reasonably safe to add the patch to your working copy of FG. No git branch expertise is required.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=317493#p317493
|title = <nowiki> Re: Gear view in cockpit computer </nowiki>
|author = <nowiki> Alant </nowiki>
|date = Aug 26th, 2017
|added = Aug 26th, 2017
|script_version = 0.40
}}</ref>

Once the patch is applied and the binary rebuilt, all that is needed is to add the new camera-display to an existing cockpit panel:

<syntaxhighlight lang="xml">
<camera-display>
<name>cd</name>
<texture></texture>
<enabled type="bool">true</enabled>
<view-number>0</view-number>
</camera-display>
</syntaxhighlight>

For view configuratoin, it's using the standard view-manager interface, so you primarily need to set the view-number property to change the view (untested, feedback is just based on looking at the patch in question).
Specifically, when running the patched fgfs binary, look for: '''/instrumentation/camera-display''' and the '''view-number''' property underneath<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=317488#p317488
|title = <nowiki> Re: Gear view in cockpit computer </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Aug 26th, 2017
|added = Aug 26th, 2017
|script_version = 0.40
}}</ref>

The current state is... well, it "works" ;-)
However there are some bugs:

* The image jumps all over the place when the aircraft is moving.
* The colours are wrong.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=317475#p317475
|title = <nowiki> Re: Gear view in cockpit computer </nowiki>
|author = <nowiki> Alant </nowiki>
|date = Aug 26th, 2017
|added = Aug 26th, 2017
|script_version = 0.40
}}</ref>

# The colours are wrong with Rembrandt. It looks as if the wrong buffer is being used.
# Jumping around is the same with and without Rembrandt.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=317486#p317486
|title = <nowiki> Re: Gear view in cockpit computer </nowiki>
|author = <nowiki> Alant </nowiki>
|date = Aug 26th, 2017
|added = Aug 26th, 2017
|script_version = 0.40
}}</ref>

The jumping around effect seems to be in all views. The control tower view jumps back and forward, showing the whole tower at times.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=317489#p317489
|title = <nowiki> Re: Gear view in cockpit computer </nowiki>
|author = <nowiki> Alant </nowiki>
|date = Aug 26th, 2017
|added = Aug 26th, 2017
|script_version = 0.40
}}</ref>

before looking at some of our most advanced use-cases, it's best to tinker with a really simple scenario, to see how well this works, and what needs to be polished.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=317487#p317487
|title = <nowiki> Re: Gear view in cockpit computer </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Aug 26th, 2017
|added = Aug 26th, 2017
|script_version = 0.40
}}</ref>

if anybody is interested in working out what is missing or what can be improved, we should review working features doing similar things, e.g. the screenshot/streaming handlers or the camera setup routines used by CameraGroup.cxx itself.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=317477#p317477
|title = <nowiki> Re: Gear view in cockpit computer </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Aug 26th, 2017
|added = Aug 26th, 2017
|script_version = 0.40
}}</ref>

The patch itself seems overlapping with Zan's original "new-cameras" effort, as mentioned at: [[Canvas Development#Supporting Cameras]]
If this patch should work well enough, it would probably make sense to integrate it with the Canvas system to come up with a dedicated "camera" element for the Canvas system, that would be configurable using the format/properties used by the view manager: [[Howto:Configure views in FlightGear]]
At that point, it would actually be a terrific idea to review Zan's original patches and see if any of the features there could/should be integrated with the new Canvas::Camera element - like you say, once this is properly working, "the sky is the limit" (or not even that, think shuttle cams)<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=317466#p317466
|title = <nowiki> Re: Gear view in cockpit computer </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Aug 26th, 2017
|added = Aug 26th, 2017
|script_version = 0.40
}}</ref>

Thus, the patch needs some TLC - however, it's definitely a very solid foundation, and very compelling as a prototype, especially given that the patch is pretty lightweight.

Much of the OSG machinery to set up the FBO/RTT (render to texture) is overlapping with Canvas functionality, so we could do away with that by using a dedicated Canvas element (which may fix some issues, e.g. colors being off).

Besides, if/when we actually use the approach used by Torsten's screenshot handler routines (mongoose/Phi), the "jumping" may also be gone (just a guess).
At this point, we need to get more people involved who are able to patch/rebuild sg/fg from source and test these patches, so that we can come up with a team of folks to help with testing/developing. Hooray can certainly help with the Canvas side of this, which means that the FBO/RTT setup routines can be simplified, and he can help turn the whole thing into a dedicated Canvas "camera" element.

<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=317490#p317490
|title = <nowiki> Re: Gear view in cockpit computer </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Aug 26th, 2017
|added = Aug 26th, 2017
|script_version = 0.40
}}</ref>

=== G1000 & MapStructure improvements ===
{{Main article|FG1000}}

As of 09/2017, Stuart started making some tentative steps towards a full Garmin [[G1000]] simulation, he started with the excellent xkv1000 as a starting point, particularly for the PFD which very closely mirrors the G1000.

For the MFD he's planning to use the [[Canvas MapStructure]] layers (obviously).
One area he is going to have to develop is tiled mapping, which the [[MapStructure]] in fgdata doesn't currently support as a layer.

Stuart's thoughts are:

# Create an OverlayLayer layer with a controller that is analogous to the SymbolLayer, but likely with a simple update method rather than SearchCmd, and no .symbol equivalent
# Convert the tiled map example from the wiki, but also other layers such as a compass rose, airport diagram, lat/lon grid.

Stuart is currently undecided on how to handle the projection - whether to have the layer itself have to interpret the centerpoint of the map and scale, and then make a projection itself, or to provide it from the Map. The latter would undoubtably be cleaner, but for something like a tiled map he suspects that the management will need to be quite low down the stack.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=317013#p317013
|title = <nowiki> Canvas G1000 </nowiki>
|author = <nowiki> stuart </nowiki>
|date = Aug 21st, 2017
|added = Aug 21st, 2017
|script_version = 0.40
}}</ref>

Stuart is getting to grips with the Canvas MapLayer stuff, and in particular rendering layers from a map service. One layer he is wanting to add is airspace information, so it's very good news that this is available. From the looks of things Stuart may just be able to plug in the Slippy Tile URLs and render all the airspace in-sim in a Canvas map.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36034923/
|title = <nowiki> Re: [Flightgear-devel] New MultiPlayer map server based on nodejs </nowiki>
|author = <nowiki> Stuart Buchanan </nowiki>
|date = Sep 12th, 2017
|added = Sep 12th, 2017
|script_version = 0.40
}}</ref>

=== Property I/O ===
{{See also|Howto:Canvas Path Benchmarking}}

As a first step towards [[Canvas_News#Moving_map.2FRNAV_discussion|developing a G1000]], Stuart Buchanan has been looking at Nasal property read/write performance, as he understands that this is a bottleneck for developing complex Canvas applications.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35974946/
|title = <nowiki> [Flightgear-devel] Nasal property lookup performance </nowiki>
|author = <nowiki> Stuart Buchanan </nowiki>
|date = Jul 31st, 2017
|added = Jul 31st, 2017
|script_version = 0.40
}}</ref>

For well-organized code (aka writing only when needed, organizing the displays in suitable groups, staggered updates...), it's going to be fast enough. For a straightforward approach to complicated displays probably not. A thousand properties sounds a lot, but every update in translation is already 2 properties, combined with a visible flag and color information you're down to 166 elements you can update already. If each of them is driven by reading a value from the tree you're losing even more. Generally, if there is a way of making either method faster, it would affect performance in a positive way all over Nasal scripting because currently property I/O is in my view the largest bottleneck (especially of canvas).<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35975339/
|title = <nowiki> Re: [Flightgear-devel] Nasal property lookup performance </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Aug 1st, 2017
|added = Aug 1st, 2017
|script_version = 0.40
}}</ref>

low-hanging fruit in the canvas API:
* add more calls like updateText (updateTranslation, updateRotation,...) which check whether the property to be written has changed at all against a Nasal record before actually doing property I/O
* make the updateXXX methods store the node reference and use that rather than construct it afresh

If the test suite numbers hold up in reality, this ought to give a factor 2 to <few hundred> (dependent on how often the argument actually has to be written - at least Thorsten was able to write 50 million numbers into a Nasal array much faster than 50.000 numbers into properties).<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35976562/
|title = <nowiki> Re: [Flightgear-devel] Nasal property lookup performance </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Aug 1st, 2017
|added = Aug 1st, 2017
|script_version = 0.40
}}</ref>

it’s easy to add native helpers to Canvas to set some properties from code directly, rather than using the canvas.nas wrappers which then use props.nas internally. This could bypass a whole ton of Nasal if that’s the issue. Of course this code will still have to update properties from C++, so we should rather do the analysis first to see where the slowness occurs, since this could either be a very big win, or completely pointless based on that measurement.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35976398/
|title = <nowiki> Re: [Flightgear-devel] Nasal property lookup performance </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Aug 1st, 2017
|added = Aug 1st, 2017
|script_version = 0.40
}}</ref>

=== Moving map/RNAV discussion ===
{{See also|Complex Canvas Avionics}}

The airspace system is in the process of changing drastically<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35924395/
|title = <nowiki> [Flightgear-devel] RFD: FlightGear and the changing state of air
navigation </nowiki>
|author = <nowiki> David Megginson </nowiki>
|date = Jul 3rd, 2017
|added = Jul 3rd, 2017
|script_version = 0.40
}}</ref>

and there's an interesting discussion that was started by David Megginson regarding implementing G1000-type systems on the mailing list:
[https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/CAKor_TGugT%2Be%3DQhdNBqWq3Pn%2BCEq6iLZsgaB7HmiU%2BBoDK0vxQ%40mail.gmail.com/#msg35924395 https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/CAKor_TGugT%2Be%3DQhdNBqWq3Pn%2BCEq6iLZsgaB7HmiU%2BBoDK0vxQ%40mail.gmail.com/#msg35924395]<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=313697#p313697
|title = <nowiki> Re: zkv1000 reborn </nowiki>
|author = <nowiki> stuart </nowiki>
|date = Jul 4th, 2017
|added = Jul 4th, 2017
|script_version = 0.40
}}</ref>

When you're flying an IFR approach with a GPS navigator, you can use RNAV for the transitions, but need to switch to the ground ILS transmitter for the actual approach (they both use the same CDI on many planes, so it's easy to miss). The GTN 650 that I'm installing in my plane will switch CDI mode automatically under certain conditions, but it's not guaranteed. In the past, people could practice the hell out of these kinds of details in FlightGear (tuning, twisting, and identifying all the navaids, adding crosswind corrections, etc) so that they were habits when I flew them for real, but we can't practice RNAV procedures like this (or many others).<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35926937/
|title = <nowiki> Re: [Flightgear-devel] RFD: FlightGear and the changing state of
air navigation </nowiki>
|author = <nowiki> David Megginson </nowiki>
|date = Jul 4th, 2017
|added = Jul 4th, 2017
|script_version = 0.40
}}</ref>

this is something we need to address, as our GA aircraft will otherwise become more and more old-fashioned.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35925226/
|title = <nowiki> Re: [Flightgear-devel] RFD: FlightGear and the changing state of
air navigation </nowiki>
|author = <nowiki> Stuart Buchanan </nowiki>
|date = Jul 3rd, 2017
|added = Jul 3rd, 2017
|script_version = 0.40
}}</ref>

FlightGear will still be great for people who want to practice the mechanical parts of flying (e.g. crosswind wheel landings in a Cub), but will slip further and further behind for people who want to use it for real IFR practice.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35927088/
|title = <nowiki> Re: [Flightgear-devel] RFD: FlightGear and the changing state of
air navigation </nowiki>
|author = <nowiki> David Megginson </nowiki>
|date = Jul 4th, 2017
|added = Jul 4th, 2017
|script_version = 0.40
}}</ref>

zakh on the forum has been developing a Garmin G1000 clone called thekv1000: https://forum.flightgear.org/viewtopic.php?f=14&t=32056 <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35925226/
|title = <nowiki> Re: [Flightgear-devel] RFD: FlightGear and the changing state of
air navigation </nowiki>
|author = <nowiki> Stuart Buchanan </nowiki>
|date = Jul 3rd, 2017
|added = Jul 3rd, 2017
|script_version = 0.40
}}</ref>

the G1000 has multiple pages of data with data entry for flightplans etc. Stuart is sure there is a lot that has been learned by the Shuttle team that can be passed on as "best practise". The Route Manager should be able to handle most of the "magenta line" tasks, but it may be that the more complicated routing such as the RF approach, fly-by vs fly-over requires some new autopilot coding as you describe.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35925369/
|title = <nowiki> Re: [Flightgear-devel] RFD: FlightGear and the changing state of
air navigation </nowiki>
|author = <nowiki> Stuart Buchanan </nowiki>
|date = Jul 3rd, 2017
|added = Jul 3rd, 2017
|script_version = 0.40
}}</ref>

The MFD framework that is used on the Shuttle is more than capable of supporting a most of the requirements; Canvas is capable of rendering the displays. So it's possible to do this<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35927653/
|title = <nowiki> Re: [Flightgear-devel] RFD: FlightGear and the changing state of
air navigation </nowiki>
|author = <nowiki> Richard Harrison </nowiki>
|date = Jul 4th, 2017
|added = Jul 4th, 2017
|script_version = 0.40
}}</ref>

A number of contributors expressed concerns regarding the performance of the Canvas system when it comes to implementing sophisticated avoinics like G1000-style systems. However, the fact that there are people who code canvas like there's no tomorrow and update 10 elements where an update of the group position would do the trick at a fraction of the cost doesn't mean that canvas or Nasal are slow - it means inefficient code is slow, and that's just as true for C++. Nasal as such is fast, and compared with the cost of rendering the terrain, rendering a canvas display is fast on the GPU (you can test by rendering but not updating a canvas display), and unless you're doing something very inefficient, calculating a display but not writing it to the property tree is fast (you can test this by disabling the write commands). It's the property I/O which you need to structure well, and then canvas will run fast. And of course the complexity of your underlying simulation costs - if you run a thermal model underneath to get real temperature reading, it costs more than inventing the numbers. But that has nothing to do with canvas.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35926343/
|title = <nowiki> Re: [Flightgear-devel] RFD: FlightGear and the changing state of
air navigation </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jul 4th, 2017
|added = Jul 4th, 2017
|script_version = 0.40
}}</ref>

Structured in a reasonable way (i.e. minimiing property I/O in update cycles, avoiding canvas pitfalls which trigger high performance needs etc. ) canvas is pretty fast (kind of reminds me of the old 'Nasal is slow' discussions... it's still the same things which are slow, except canvas hides it behind some abstraction - understand property I/O, and it'll run fast)<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35925540/
|title = <nowiki> Re: [Flightgear-devel] RFD: FlightGear and the changing state of
air navigation </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jul 3rd, 2017
|added = Jul 3rd, 2017
|script_version = 0.40
}}</ref>

The G1000 is a fairly significant piece of computer hardware that we're going to emulate. It's not going to be "free" particularly for those on older hardware that's already struggling. However, hopefully we can offload a chunk of the logic (route management, autopilot/flight director) to the core, and do things like offline generation of terrain maps to minimie the impact.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35926745/
|title = <nowiki> Re: [Flightgear-devel] RFD: FlightGear and the changing state of
air navigation </nowiki>
|author = <nowiki> Stuart Buchanan </nowiki>
|date = Jul 4th, 2017
|added = Jul 4th, 2017
|script_version = 0.40
}}</ref>

For starters, Stuart is hoping to to optimize the property access and become more familiar with the Canvas C++ code so that he can help bridge the cap between core and Canvas client developers. He thinks James has some thoughts on the Canvas C++, so he'll want to coordinate with him as well.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=313787#p313787
|title = <nowiki> Re: zkv1000 reborn </nowiki>
|author = <nowiki> stuart </nowiki>
|date = Jul 6th, 2017
|added = Jul 6th, 2017
|script_version = 0.40
}}</ref>

One of the ideas raised by David is, should there maybe be a separate project to build an embeddable GPS navigator with different faces/UIs (and a default standalone front end)? As others have mentioned, a lot of the backend logic is the same, like doing a gradual transition from RNAV to Localiser on intercept to avoid a sudden jolt in the A/P, or calculating a turn past a fly-by waypoint. Again, that would be a way to join forces with other Sim dev communities. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35929948/
|title = <nowiki> Re: [Flightgear-devel] RFD: FlightGear and the changing state of
air navigation </nowiki>
|author = <nowiki> David Megginson </nowiki>
|date = Jul 5th, 2017
|added = Jul 5th, 2017
|script_version = 0.40
}}</ref>

if we wanted to build a tablet-based emulator ourselves, we could at least join forces with the FSX and X-Plane communities to do it to grow up the pool of talent.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35927243/
|title = <nowiki> Re: [Flightgear-devel] RFD: FlightGear and the changing state of
air navigation </nowiki>
|author = <nowiki> David Megginson </nowiki>
|date = Jul 4th, 2017
|added = Jul 4th, 2017
|script_version = 0.40
}}</ref>

=== Groups and Colors ===
Thorsten learned something rather important about canvas: After doing canvas a while, most of us love the concept to suitably group things and then translate or hide the whole group, which is a very performance-friendly way to get the job done compared with moving all elements.

Thorsten had the situation that the Shuttle HUD has several de-clutter levels which are progressively hidden as the de-clutter function is used. So, he introduced dc0 to dc3 as the groups and operate with selective setVisible() on them according to chosen de-clutter level.

Doing brightness adjustment of the HUD by setting color on the group (specifically the alpha channel).

Unlike translations, rotations or visible statements acting on the top level of the group, this one seems to be passed recursively down the child elements, leading to a huge property I/O.

Anyway, if you know what it does, it's a very useful function still - just it can't be used in a performance-critical place, and it should not be confused with performance-friendly group operations.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=307073#p307073
|title = <nowiki> Color and groups - beware! </nowiki>
|author = <nowiki> Thorsten </nowiki>
|date = Mar 16th, 2017
|added = Mar 16th, 2017
|script_version = 0.40
}}</ref>

=== Canvas GUI ===
James is planning a bit of work in the Canvas GUI/widgets area but in the medium term (mid 2017), he wouldn't recommend making lots of extensions to the current Canvas GUI toolkit because he wants to give the whole Canvas-GUI architecture a review and sanity-check first. For the time being, he has no idea if this will be compatible or incompatible with the existing GUI controls, or even be successful. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35591369/
|title = <nowiki> Re: [Flightgear-devel] fgplot / currently active canvas developers? </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 8th, 2017
|added = Jan 8th, 2017
|script_version = 0.40
}}</ref>

Hhis intuition is the current style system is overkill, but that the layout code will need some enhancements. So he would avoid both those areas for now. Adding missing widget types is probably safe, but if you propose them here we can discuss their API to hopefully keep it stable even if the implementation changes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35610051/
|title = <nowiki> Re: [Flightgear-devel] fgplot / currently active canvas developers? </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 17th, 2017
|added = Jan 17th, 2017
|script_version = 0.40
}}</ref>

=== Skia talks ===
James announced he wants to replace the vector drawing routines with another package which was designed with SIMD in mind<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=302558#p302558
|title = <nowiki> Re: Simgear compilation failure </nowiki>
|author = <nowiki> erik </nowiki>
|date = Jan 3rd, 2017
|added = Jan 3rd, 2017
|script_version = 0.40
}}</ref>

Blend2D is quite amazing for a technical point of view: it compiles native CPU code (including SIMD) for every draw operation using a JIT compiler.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35631656/
|title = <nowiki> Re: [Flightgear-devel] Canvas-svg </nowiki>
|author = <nowiki> Erik Hofman </nowiki>
|date = Jan 28th, 2017
|added = Jan 28th, 2017
|script_version = 0.40
}}</ref>

The idea is to use Skia (from Chrome), actually, since it has software and hardware backends. This would allow switching based on which gives better performance on a given machine, and easy porting to other devices, such as Android. The remote-canvas code is a proof-of-concept for this, the aim would be to use the same protocol to render the canvases in different threads.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35630367/
|title = <nowiki> [Flightgear-devel] Canvas-svg </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 27th, 2017
|added = Jan 27th, 2017
|script_version = 0.40
}}</ref>

After reviewing Skia (including reading the sources) and it seems like a very promising fit, albeit with the caveat that it is kind of huge. Blend2D looks pretty good but less mature than Skia, and most importantly, lacks a hardware renderer which James thinks is critical to support devices such as the Raspberry Pi and cheap Android tablets, which James expects to be a very good target for the remote canvas (an RPi driving a wide-screen panel via HDMI could do both the PFD and ND of a Boeing/Airbus setup, but that’s 1920 x 1080 pixels which is too much to fill in software at 60H) Anyway, at this point the code is small enough that experimenting with one renderer or another (Cairo also) is probably a weekend’s hacking, if anyone cared to try. James is currently working on hardware acceleration using QtQuick, since we already have Qt as a dependency.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35631079/
|title = <nowiki> Re: [Flightgear-devel] Canvas-svg </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 27th, 2017
|added = Jan 27th, 2017
|script_version = 0.40
}}</ref>

== 2016 ==

=== SIMD ===
{{Main article|SIMD Support}}
Erik is experimenting with streamlined Canvas rendering using Single Instruction Multiple Data (SIMD) instructions which is able to calculate on 4 floating poit variables simultaneously (e.g 3 or 4 value vectors). For the F-16 map this gives a speedup from 12+ seconds delay rendering at the first select down to 6 seconds delay.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35555294/
|title = <nowiki> [Flightgear-devel] Canvas rendering speed </nowiki>
|author = <nowiki> Erik Hofman </nowiki>
|date = Dec 16th, 2016
|added = Dec 16th, 2016
|script_version = 0.40
}}</ref> <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35555306/
|title = <nowiki> Re: [Flightgear-devel] Canvas rendering speed </nowiki>
|author = <nowiki> Erik Hofman </nowiki>
|date = Dec 16th, 2016
|added = Dec 16th, 2016
|script_version = 0.36
}}</ref>

A few users have reported a noticeable increase in framerate on their computers, e.g. on some desktop the framerate has doubled<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35555950/
|title = <nowiki> Re: [Flightgear-devel] Canvas rendering speed </nowiki>
|author = <nowiki> Alan Teeder </nowiki>
|date = Dec 16th, 2016
|added = Dec 16th, 2016
|script_version = 0.36
}}</ref>.

SSE and NEON work best when considered in the design stage. Adding it afterwards is always suboptimal. Thus, Erik might still update it in a place or two but this work isn't intended to detract from adding Skia.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35556369/
|title = <nowiki> Re: [Flightgear-devel] Canvas rendering speed </nowiki>
|author = <nowiki> Erik Hofman </nowiki>
|date = Dec 17th, 2016
|added = Dec 17th, 2016
|script_version = 0.36
}}</ref>

=== Porting the legacy HUD ===
James is planning to port the C++ HUD to use Canvas for its rendering soon (next few months), but he plans to keep XML compatibility (so aircraft don't see any change) and will keep the placement logic relative to the view, for the same reason. <ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=301277#p301277
|title = <nowiki> Re: Pitfalls of canvas HUDs </nowiki>
|author = <nowiki> zakalawe </nowiki>
|date = Dec 15th, 2016
|added = Dec 15th, 2016
|script_version = 0.40
}}</ref>

=== 2D Panels ===

James is working towards migrating 2D panels to use the Canvas<ref>https://sourceforge.net/p/flightgear/mailman/message/35623408/</ref>.

This step was inspired by a discussion that originally took place on the devel list, i.e. we should move the 2D panel and HUD rendering over to this approach, since that would get rid of all the legacy OpenGL code besides the GUI. <ref>https://sourceforge.net/p/flightgear/mailman/message/29584988/</ref>

Moving the HUD to use the Canvas would be a great step from his point of view, since it and 2D panels (which he is happy to write the convert for!) are the last places besides the UI which make raw OpenGL calls, and hence would benefit from moving to the Canvas (and thus, to use OSG internally) <ref>https://sourceforge.net/p/flightgear/mailman/message/30058187/</ref>

The original goal was to identify common requirements to seee how we manage XML / property-list file processing in a nice way, to support the various formats we want to create canvas elements from - GUI dialogs, 2D panels and HUDs.<ref>https://sourceforge.net/p/flightgear/mailman/message/29588419/</ref>

James is planning in the next couple of weeks to port the panel code to generate Canvas elements, and then submit my fgcanvas utility to render any Canvas remotely, That code currently users software rendering (too slow for the RaspberryPi he expects), but upgrading the code to use OpenGL ES2 rendering is next on his todo-list so he can fun on Android / iOS devices as well as Raspbery Pi. If you’re interested in working on that please let him know, he would be glad of the help.<ref>https://sourceforge.net/p/flightgear/mailman/message/35552824/</ref>

James has done most of the work to port the 2D panels to use Canvas in an experimental branch<ref>https://sourceforge.net/p/flightgear/mailman/message/35691472/</ref>, and will do the C++ HUD next, and hence is creating Canvas elements bypassing the Nasal API.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35574596/
|title = <nowiki> Re: [Flightgear-devel] Observation about the Canvas Z-ordering </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Dec 29th, 2016
|added = Dec 29th, 2016
|script_version = 0.36
}}</ref>

=== Skia backend ===
James is also currently looking at making a Skia backend for the Canvas (to replace Shiva, making a solution using Skia ([https://skia.org https://skia.org]) as the backend, because this would give good performance via its OpenGL backend, make people who don’t want to use Qt happier, and could also replace the OSG rendering of the Canvas within FlightGear itself, allowing us to ditch ShivaVG (which is unmaintained) and probably improve performance substantially. (Skia can do SSE3/NEON optimised software rendering in a background thread, so Canvas wouldn’t eat into our OSG / triangle budget)<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=300990#p300990
|title = <nowiki> Remote canvas utility </nowiki>
|author = <nowiki> zakalawe </nowiki>
|date = Dec 10th, 2016
|added = Dec 10th, 2016
|script_version = 0.40
}}</ref>), and Skia already has quite intensive SSE/NEON optimisations, in addition to an optimised OpenGL render which he expects to be substantially more performant than the current OSG Node/Drawable hierarchy.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35555702/
|title = <nowiki> Re: [Flightgear-devel] Canvas rendering speed </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Dec 16th, 2016
|added = Dec 16th, 2016
|script_version = 0.40
}}</ref>

== References ==
{{Appendix}}

Template:CMake Build Option

2023-04-21T09:21:50Z

Hooray:

<noinclude>{{Stub}}</noinclude> -D'''{{{option|ENABLE_TESTS}}}'''={{{default|OFF}}} ({{{description|enable/disable unit tests}}} requires {{{version|'''next'''}}})

Template:CMake Build Option

2023-04-21T09:21:16Z

Hooray:

<noinclude>{{Stub}}</noinclude> -D'''{{{option|ENABLE_TESTS}}}'''={{{default|OFF}}} ({{{description|enable/disable unit tests}}} requires {{{version|next}}})

User:Callahanp

2023-04-21T08:14:07Z

Hooray:

== What I'm doing: ==
https://sourceforge.net/p/flightgear/mailman/message/37833798/

A new wiki page or edits to an existing wiki page possibly with an article on the forum:

*

There are interesting ongoing development projects on Flightgear, including new features, new scenery and aircraft. I wanted to try some of them out.

As part of my project https://github.com/callahanp/fgdev, I want to document the command line options, necessary files, environment variables and actions needed to enable specific features

*
{| class="wikitable"
|+
!Scenario or Description
!Flightgear cmake build/Executable Startup Options
and Environment Variables
|Notes:

* Recommended File Placement
* Command Line Options
* Development Status
* Report Errors to:
|-
|HDR:
|<nowiki>--compositor=Compositor/HDR/hdr</nowiki>
|[[HDR Pipeline]]

|-
|New Canvas GUI
| {{Note|The [[PUI|PUI Compatible Canvas GUI]] is a compile time option: Use the following [[Building using CMake|cmake option]] to enable this code: {{CMake Build Option|option=ENABLE_PUICOMPAT|default=ON|description=This requires latest SG/FG AND FGDATA}}. But this is all highly fluid and most of it really developer only. At one point they will become default or be accessible in the launcher.<ref>https://sourceforge.net/p/flightgear/mailman/message/37834004/</ref>}}

<code>--prop:/nasal/gui/enabled=1</code>
| {{Main article|PUI#Canvas_Emulation}}
To learn more about the implementation of underlying widgets, see [[Canvas widget matrix]]
|-
|World Scenery 2.0
|
|
|-
|World Scenery 3.0
|
|
|-
|Photoscenery for WS2.0
|<nowiki>--prop:/sim/rendering/photoscenery/enabled=true</nowiki>
|
|-
|Photoscenery for WS3.0
|<nowiki>--prop:/sim/rendering/photoscenery/enabled=true</nowiki>
|
|-
|Other Scenery
|
|
|-
|Other Aircraft
|
|
|-
|Testing
|
|
|-
|Developer Mode
| --developer
|Not sure Exactly what this does, but currently, a dialog indicating an error in the C172P appears that is not there without developer mode.
|-
|Multiplayer
| --multiplay=in,10,<your-internal-ip-address>,5000
example: --multiplay=in,10,192.168.1.246,5000
|In your router, allow TCP and UDP Port forwarding.

Example:
{| class="wikitable"
|+
!Application
!Original Port
!Protocol
!Fwd to Addr
!Fwd to Port
!Schedule
|-
|
|5000
|Both
|192.168.1.246
|5000
|Always
|-
|
|5001
|Both
|192.168.1.246
|5001
|Always
|}
|-
|Web Server
|<nowiki>--httpd=5401</nowiki>
|In web browser on the same machine as Flightgear is running on, enter this URL:
localhost:5401
|-
|Other useful Options
| --callsign=N1742C --timeofday=noon --httpd=5401 --enable-terrasync --enable-real-weather-fetch --enable-horizon-effect -multiplay=in,10,192.168.1.246,5000
|These options are present by default when you run using the fgdev infrastructure.
|}

*

PUI

2023-04-21T08:06:37Z

Hooray: /* Canvas Emulation */

{{Feature to be removed|version=2023.3|reason=[[Plib]]/PUI is to be removed and replaced by a [[Canvas widget matrix|Canvas/Nasal based solution]] to help improve compatibility with [[OSG]] 3.6+ and [[OpenGL]] 4.x ([[Core Profile support|OpenGL Core Profile]], see [[2022.X Release plan]] ) and improve performance by [[Unifying the 2D rendering backend via canvas|phasing out legacy OpenGL code]]. Therefore, people should be careful when extending the '''PUI''' based legacy GUI engine<ref>https://sourceforge.net/p/flightgear/mailman/message/34921495/</ref><ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35157325/
|title = <nowiki> Re: [Flightgear-devel] GUI options (Was: Aircraft center) </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jun 14th, 2016
|added = Jun 14th, 2016
|script_version = 0.40
}}</ref> and coordinate any related work with the devel mailing list first-this applies particularly to adding any [[Template:PUI_widget|additional hard-coded PUI widgets]]. }}
[[File:Exit.png|thumb|FlightGear GUI dialog (exit.xml)stored in $FG_ROOT/gui/dialogs]]
{{GUI Navbar}}

[[File:Custom-autopilot-dialog.png|right|200px]]
[[PUI]] is the standard GUI engine used in FlightGear, it is part of [[PLIB]] and is using raw, fixed-pipeline, [[OpenGL]] code internally (no [[OpenSceneGraph]]). As of mid 2021, FlightGear is in the process of working towards adopting the OpenGL Core Profile, this means that [[PUI]] is causing trouble and needs to be replaced/disabled or ported.

PUI provides a fairly basic, but robust, set of widgets. PUI is also used for rendering the [[Menubar]].

FlightGear uses a GUI widget set that is implemented on top of raw (legacy) [[OpenGL]]. This has many advantages from a portability standpoint and from the standpoint of integrating with window systems. [[PUI]] doesn't have every feature under the sun, but it was never meant to. It's relatively small, lean, mean, and written on top of [[OpenGL]] which makes life *much* easier for us.

[[PUI]] already is a separate distinct library within Plib. It depends on some central utility stuff, but that's about it. So it is pretty stripped down and separate already.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg26011.html</ref>

We are to some extent hamstrung by the rather old GUI toolkit we use. However, replacing that is going to be non-trivial, and it would affect not just the core GUI but also all the dialog boxes that have been set up for particular aircraft.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg25985.html</ref>

Flightgear can look amazing when you use the HDR pipeline. We absolutely need this to stay relevant. The problem is that HDR is not compatible with OpenGL1 PUI. Work on getting rid of PUI has been going on for over a decade (longer than it took to implement it).<ref>https://sourceforge.net/p/flightgear/mailman/message/37727346/</ref>

[[File:menubar2.jpg|517px]]

== Replacement status ==
{{See also|FlightGear_and_OpenGL_ES#Example:_disabling_PUI}}

{{Note| Update 09/2022: The PUI replacement [[QtQuick_use_in_FlightGear#Background|was going to be Qt]] but it started to get very complicated with changes in Qt 5.15 + Qt 6, so James is going with a more light-weight Canvas based approach now.

Qt added support for Vulkan / Metal / D3D starting in 5.15, but FlightGear / OpenSceneGraph can’t support those, so integrating the two renderers went from being ‘complicated but ok’ to ‘very very complicated’.

So now James is going with something much more lightweight using some C++ compatibility code, some Nasal for styling and the existing [[Canvas widgets|Canvas widget rendering]] from Thomas Geymayer (TheTom) with some extensions and additions, based on the [[Howto:Processing_legacy_PUI_dialogs_using_Canvas#Original_Discussion|plans originally discussed when the Canvas GUI system was added to FlightGear]]: some pieces are in FlightGear & FGData already.

James has basic dialogs working okay but not the more complex ones and everything looks kind of ugly, he needs to improve the visual look before he shares screenshots to avoid everyone freaking out :) The disadvantage of this approach is James is far from expert at creating visual appearances this way, so it’s kind on unrewarding and slow for him. If someone likes messing with CSS-type styling, border-images and hover-states, ping him since we could probably move things also faster <ref>https://sourceforge.net/p/flightgear/mailman/message/37701750/</ref>}}

=== Motivation ===
{{Main article|Core Profile support}}

The bigger issue here is we need to ditch [[PUI]] (which is in progress) and some OpenGL 1.0 code (HUD, 2D panels especially - can be #ifdef for now) so we can enable Core profile on Mac - since Mac 4.x support (we only hit about 4.3 alas, but with some extensions to get in sight of 4.5) is Core profile only, no Compatability mode.

Improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, many people are convinced PUI needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

While most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so [using Qt5] would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

== Canvas Emulation ==
{{See also|Canvas widget matrix}}
'''Last updated: 04/2023 <ref>https://sourceforge.net/p/flightgear/mailman/message/37805054/</ref>
'''
=== Status ===
As of 01/2023, the replacement for PUI is making good progress<ref>https://sourceforge.net/p/flightgear/mailman/message/37765706/</ref>.

In February 2022, James reported having something in progress locally, and that should even be something we can try in March/April 2022. Hopefully that’s quick enough, knowing it has been a long time coming.<ref>https://sourceforge.net/p/flightgear/mailman/message/37606439/</ref>

There's now an XML to Nasal bridge, to keep PUI dialogs working (Disabled by a CMake option)
This is implemented on top of the [[Canvas]] system.

This builds equivalent C++ objects to what the [[PUI]] dialogs build, with properties exposed to Nasal.
Peer objects are created by Nasal [[callbacks]], which can implement the various dialog functions needed to keep compatibility, especially the [[#Background|‘update’ and ‘apply’ hooks]].<ref>https://sourceforge.net/p/flightgear/flightgear/ci/cbd5ef9e7b8f433dbc1ba97bae7d7cfc894e7cef/</ref>

{{Note|The PUI Compatible Canvas GUI is a compile time option: Use the following [[Building using CMake|cmake option]] to enable this code: {{CMake Build Option|option=ENABLE_PUICOMPAT|default=ON|description=This requires latest SG/FG AND FGDATA}}. But this is all highly fluid and most of it really developer only. At one point they will become default or be accessible in the launcher.<ref>https://sourceforge.net/p/flightgear/mailman/message/37834004/</ref>

If you compiled with PUICompatibility enabled, but still don't see any dialogs - only the menubar, you might need to enable the GUI module in defaults.xml<ref>https://sourceforge.net/p/flightgear/mailman/message/37833149/</ref>}}

The new Compatibility files can now be found in $FG_SRC/GUI:

* {{flightgear file|src/GUI/FGPUICompatDialog.cxx }}
* {{flightgear file|src/GUI/FGPUICompatDialog.hxx }}
* {{flightgear file|src/GUI/PUICompatObject.cxx }}

01/2023: James is slowly working on creating the pop-up menu and combo-box widgets [...]

One of the major things slowing down James' work on the popup-menu and combo box is time to restart the simulator for each change, he is looking for some solution to re-load the widget Nasal code independently. <ref><https://sourceforge.net/p/flightgear/mailman/message/37756183/</ref>

James has done about 75% (hah!) of the C++ work to enable live reloading of modules this way, but unfortunately there are some code paths that would become crashy if you use the feature for the Canvas: because it would reference the ‘old’ (pre-reload) Nasal code, and not the new one, and therefore you’d get a weird mix of old and new, and then just crash the sim. To fix it properly I need to track down those places that store a reference to Canvas and give them a re-init method, so we don’t keep the stale references.

The general non-fun-ness of that kind of debugging is James has been making such slow progress on my PUI replacement widgets recently <ref>https://sourceforge.net/p/flightgear/mailman/message/37756263/</ref>

=== Todo ===
Nothing in particular : help debugging the grid layout (which is in simgear) would be good. For now you could create a grid layout manually using some Nasal.

For the menubar, we need to expose the C++ data to Nasal : we need a FGCompatMenuBar (alongisde FGPUIMenuBar) implementing FGMenubar which calls _createMenuObject in MenuBar.nas, using the same way I lookup and call _createDialogPeer in XMLDialog.nas

(Make sure you don’t break the macOS native menubar in the process!)

You can probably pass a wrapped SGpropertyNode into this, and then fill in the stubs in that file to use the Menu widgets Frederic has written.

Global menu keybindings won’t worry but don’t touch that, I have a separate plan for it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37805736/</ref>

As of 04/2023, remaining items on the todo list are: <ref>https://sourceforge.net/p/flightgear/mailman/message/37805060/</ref>

* Grid layout
** GridLayout needs debugged: After this, the basic UI is usable, would probably make it a switchable option on ‘next’ (I can already use the simulator with the new UI today, but all the sizes are off in the grid layouts which we use everywhere)

* list
* table (and tree ?) models corresponding views
* waypoint list
* Re-write the waypoint list and airport dialog to work again (since these use custom widgets):
** log list
** airport-list equivalents
* Nasal access to the menu i18n functions
* selection support for single- and multi-line text (which is being worked on -> CanvasPangoText)
* Keyboard shortcut handling, although this is not really a PUI vs replacement issue, to me we should handle UI shortcuts in the same was normal keyboard.xml shortcuts
** this previously worked because PUI got ‘first chance’ at handling key input. But we always had duplication between keyboard.xml and other places, so I would rather standardise on keyboard.xml, but allow a UI element to set a scope for shortcuts. (So that Copy/paste shortcuts etc can work in a text input, at least … but probably some other standard ones) <ref>https://sourceforge.net/p/flightgear/mailman/message/37805188/</ref>
* Ensure all the places which use the PUI combo-box and list-widget work : there’s a few of these.

The CanvasPangoText stuff is needed but we can perfectly well run the UI on next without it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37805176/</ref>

=== Parser ===
{{Main article|pui2canvas}}
The corresponding Nasal/Canvas module to dynamically "translate" legacy PUI/XML dialogs into Canvas dialogs (at runtime), is to be found in {{fgdata file|Nasal/gui/XMLDialog.nas}} <ref>https://sourceforge.net/p/flightgear/fgdata/ci/fe7c87b21a69f88ddb87d89453c48d12b69660e2/</ref>

=== Widgets ===
{{Main article|Howto:Creating a Canvas GUI Widget}}

It’s split between Simgear (see classes with widget / layout in the name) and in FGData. (Eg widgets/Button.nas) To be able to use the existing dialog XML files un-modified (which is a design goal), James is extending the widget types with many additional ones (eg PUI has slider, dial, combo-box, checkbox, all of which need to be created, see [[Canvas widget matrix]].

This is about 30% done and is the bit he's very slow at). Thomas’s canvas widgets have a very good separation of API + state from appearance, so all styling is in its own file, and James is being very strict about maintaining this separation, so we also retain the re-styling feature of the PUI UI, which many people also rely on. This does make the process of adding new widgets more complex, however.

{{See also|Canvas widgets}}

=== Layouting ===
The other thing is to preserve all the layouting: James has added a grid layout to Simgear, since that is supported by the existing PUI code (even though the layouts are not actually part of PUI itself). The problem is getting the sizing / hinting of all the widgets to match the PUI values, so that dialogs look approximately the same under the new UI as they did with PUI; again this a design goal so that all existing dialogs in aircraft and add-ons, which we can’t update, continue to work and be usable. Debugging that is also proving quite tricky, since there’s all kinds of hard-coded assumptions built into PUI widgets about pixels, font-sizes etc which are not true in the new system.<ref>https://sourceforge.net/p/flightgear/mailman/message/37701792/</ref>

== Background ==
In FlightGear, PUI dialogs are standard [[PropertyList XML File]]s that are stored in $FG_ROOT/gui/dialogs, they can contain the widgets mentioned in {{readme file|gui}}, using a simple layout engine discussed in {{readme file|layout}}, and bindings using a combination of so called fgcommands operating on properties (see {{readme file|commands}}) and custom [[Nasal]] (FlightGear scripting) code.

In addition, each PUI/XML dialog may contain Nasal script sections that are executed when opening/closing the dialog, a feature which is commonly used for procedurally creating/updating widgets using the [[Nasal_library#cmdarg.28.29|cmdarg() API]], which allows the dialog tree to be traversed and manipulated prior to the dialog being rendered.
Widgets can be conditionally hidden/shown using a wrapper for [[Conditions|SGCondition]] in [[Nasal_library/props|props.nas]]
The <code>canvas</code> widget also supports its own embedded Nasal code section to execute arbitrary widget specific Nasal code upon opening/closing the dialog/widget.

PUI/XML dialogs can be loaded, dynamically created, updated and closed using a handful of fgcommands:
* {{fgcommand|dialog-new}}
* {{fgcommand|dialog-show}}
* {{fgcommand|dialog-update}}
* {{fgcommand|dialog-apply}}
* {{fgcommand|dialog-close}}

PUI related OpenGL code is particularly infamous for causing rendering artifacts for people on AMD/ATI and Intel hardware (especially in combination with certain fonts/styles and [[Effects|effects]]/[[Shaders|shaders]]), see {{Issue|2213}}.

PUI is also known to affect rendering performance quite significantly (see {{search |keywords=anthrax+gui}}), while also preventing FlightGear from using a more recent version of OpenGL<ref>http://sourceforge.net/p/flightgear/mailman/message/34532040/</ref><ref>http://forum.flightgear.org/viewtopic.php?f=71&t=24046</ref>.

However, improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Besides, while most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

But given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, graphics folks are also convinced it needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

In addition, [[OpenSceneGraph]] (OSG) can obviously not help optimize any PUI related GL code and PUI widgets are generally considered to be pretty archaic and not easy to extend<ref>http://sourceforge.net/p/flightgear/mailman/message/26832164/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587120/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587272/</ref>.

{{Note|We use the GUI code from PLIB, which doesn't know anything about OSG. See the SGPuDrawable class in $FG_SRC/Viewer/renderer.cxx for the implementation. The one catch is that OSG has a strong notion of separation between the update of a "scene" and its rendering, and that might not play well with arbitrary existing OpenGL code. }}

As of late 2015, there is heavy activity towards providing alternatives to a PUI-based UI:
* [[Integrated Web GUI]] (external, browser-based - fully asynchronous)
* [[Howto:Processing legacy PUI dialogs using Canvas]] (internal, using the [[Canvas]] system and a simple [[Nasal]] parser to deal with existing PUI/XML dialogs)

<gallery mode="packed">
Early-Phi-screen shot.PNG|Screenshot showing [[Phi]]
About-dialog-rendered-by-canvas.png|Screenshot showing a dialog rendered by the [[Howto:Processing legacy PUI dialogs using Canvas|pui2canvas parser]]
</gallery>

== History ==
{{Caution|This is merely kept for future reference, many of the ideas discussed below have become obsolete as of 09/2022, if in doubt, please get in touch via devel-list.}}
=== 2021 ===
In early 2021, James did a brief evaluation of [https://github.com/ocornut/imgui ImGUI] as a possibility - he's also evaluating it in some projects at his day job.

The API is interesting if you’re starting from scratch and only exclusively in C++, but it’s not a great fit for how we define GUIs in FG (via [[XML]]/[[Nasal]]): there is no back door that he could find, to access the persistent state of the GUI, or build it up in a data-driven way. So making a mapping to keep our existing GUI XML working (and updating correctly) becomes a bit of a chore.<ref>https://sourceforge.net/p/flightgear/mailman/message/37295586/</ref>

Pretty much all of the FlightGear GUI is defined in XML space, except for a few oddments. Let’s say 95% at this point.

Additionally, even if we were to change that for the core sim (and James' current plan is to keep the XML syntax and just extend it), the installed base of '''aircraft''' ship their own XML dialogs (eg., replacing the autopilot dialog with a custom one, or just adding their own aircraft-specific helper controls for doors / lights / cargo / whatever). So even if we found the most sublimely beautiful, intuitive, compact GUI description language in the world, we have to keep the XML syntax working as-is, for the foreseeable future.

Given this, James' intention is to replace the output side [[PUI]] but keep the front-end side (XML / properties / bindings) unchanged, and therefore backwards compatible, and simply add some new types / options / widget types going forward. This will mean we still have to deal with the slightly cumbersome XML+Nasal syntax, but, well, it’s not *that* cumbersome. <ref>https://sourceforge.net/p/flightgear/mailman/message/37296280/</ref>

In mid 2021, James reported that he is working on some ‘PUICompat’ classes which hold/own/represent the GUI state in C++, but which can be used with [[Nasal/CppBind|Nasal CppBind]]. And of course we could indeed expose those later on. <ref>https://sourceforge.net/p/flightgear/mailman/message/37297727/</ref>

In July 2021, James suggested not to worry about the existing GUI code, it’s going in the bin.<ref>https://sourceforge.net/p/flightgear/mailman/message/37325905/</ref>

For the time being, the in-sim GUi can’t do Unicode yet, but James is working on it, hopefully available soon.<ref>https://sourceforge.net/p/flightgear/mailman/message/37328200/</ref>
Also, the in-sim menubar will change with the new GUI, *and* we use a native menubar on macOS. Until James replaces the PUI fonts we can’t use Unicode symbols. So, will have to come back to it once the new GUI is merged.<ref>https://sourceforge.net/p/flightgear/mailman/message/37327237/</ref>

=== 2020 ===
As of 03/2020, the PLIB replacement was reported to be in the backlog <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36951255/
|title = <nowiki>Re: [Flightgear-devel] C++ and/or OSG question </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Mar 18th, 2020
|added = Mar 18th, 2020
|script_version = 0.50
}}</ref>.

With PLIB replacement work likely being re-scheduled for [[Post FlightGear 2020.2 LTS changes]] <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36985375/
|title = <nowiki>Re: [Flightgear-devel] Working Group Proposal - Boost and PLIB replacement - Delegation and Teamwork </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = April 18th, 2020
|added = April 18th, 2020
|script_version = 1.10
}}</ref>.

In 08/2020, James stated that he was still working (exceptionally slowly!) on replacing PUI (as part of removing legacy OpenGL code (PUI, HUD, 2d panels, porting Canvas away form ShivaVG), so we can switch to Vulkan/VSG at some point (ideally at some point before Apple turn off OpenGL support…)), and that he doesn't think /any/ of us *want* to be working on these features particularly, but projects like these need to be done before anyone can have fun with VSG or Vulkan (personally James would be very enthusiastic about working on VSG support (being on macOS, I also have the most to lose / gain from it)). Sometimes that’s just how it goes. Equally they will all benefit the project ultimately, but the payoff both for the individual and the project is very drawn out. <ref>https://sourceforge.net/p/flightgear/mailman/message/37077158/</ref>

In 10/2020, the estimation is that PUI should be going away really ‘soon’, the replacement code is already in next / 2020.2. (There’s no plan to actually /use/ the new UI code in 2020.2, but if the bugs in it prove simple, we could actually turn it for specific dialog: it seems very unlikely this makes sense for a stable release however)<ref>https://sourceforge.net/p/flightgear/mailman/message/37123818/</ref>

The fixed-function removal, is actively in hand (Gaetan is working on the 2D panel part, and James is going to focus on PUI in the rest of 2020). James hopes that means next year he can focus on Vulkan, or at least, using OSG as if /were/ VSG, so the migration in a year or two when VSG is stable, is not so painful.<ref>https://sourceforge.net/p/flightgear/mailman/message/37129098/</ref>

The PUI UI and replacement can co-exist in the same build (they already do, effectively.<ref>https://sourceforge.net/p/flightgear/mailman/message/37131297/</ref>

In 11/2020, James suggested not to worry about details such as PUI styling/theming etc: we’re not making such changes for the LTS, and PUI should be gone before the next release.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142225/</ref> Also, he recommended (to everyone) to stop touching GUI stuff for a few weeks, as he's about to turn it all on its head.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142356/</ref>

=== 2019 ===
The new GUI has been incubating for a few years, but there's apparently been a lot of progress as of 10/2019.

It is likely the new GUI will be a user opt-in feature - at least initially. The sunset of the PLIB library _could_ happen relatively soon, but
people will need to see the new GUI and react to it before we could commit to PLIB removal <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36784489/
|title = <nowiki>Re: [Flightgear-devel] in Flightgear/Simgear C++ Code: What needs Doing? What are YOU Doing? What would you do if you had the time? </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Oct 14th, 2019
|added = Oct 14th, 2019
|script_version = 0.50
}}</ref>.

In 02/2019, James stated that the new UI is coming quite soon. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36589420/
|title = <nowiki> Re: [Flightgear-devel] Lagging </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Feb 17th, 2019
|added = Feb 17th, 2019
|script_version = 0.40
}}</ref>

=== 2018 ===
{{See also|QtQuick use in FlightGear}}

According to James, we have to accept that changes like testing or making [[PUI]] a modular thing or moving the JS code tend to have an immediate pain for some people (because strange stuff gets broken, and takes some time to get fixed), whereas the payoff in terms of improved joystick handling or replacing the UI or testing of all subsystems will take some months or years to be felt.<ref>https://sourceforge.net/p/flightgear/mailman/message/36323240/</ref>

James said he was in the middle of porting the launcher’s final tab (location) to the new UI scheme, once that’s done he will start sketching out the ‘in sim’ settings UI using the same pieces. He’ll send a request for contributions around about that in the next three-four weeks, once he has enough templates & examples that there is a clear pattern to follow.<ref>https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/2d10f16c-ddc8-07f3-07e7-eca2a0a0d55f%40zaretto.com/#msg36293586</ref>

James announced that the launcher is now feature complete with the QtQuick UI, he’ll keep making bug-fixes of course as people report them, but my todo list for the core features is now done<ref>https://sourceforge.net/p/flightgear/mailman/message/36355833/</ref>.

=== 2017 ===

In 10/2017, James said he was getting really close to having the PUI replacement UI suitable for beta-testing.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36067646/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 7th, 2017
|added = Oct 7th, 2017
|script_version = 0.40
}}</ref>

Originally, James was hoping to land the PUI replacement GUI in the last dev cycle in 2017 (at least as a proof-of-concept, probably not as the default UI), so wouldn’t expend lots of effort on things like collapsible sections which might be a lot of work with the current PUI/Canvas approaches, but are trivial with the new [[QtQuick use in FlightGear|QtQuick based UI scheme]].<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36059822/
|title = <nowiki> Re: [Flightgear-devel] Canvas MapLayer for OpenStreetMap, OpenAIP,
VFR Sectionals </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 1st, 2017
|added = Oct 1st, 2017
|script_version = 0.40
}}</ref>

Once the basic new UI is in place we can experiment with different re-arrangements easily, without being limited by PUI. (James expects PUI to live on as the default / alternate UI while this happens)<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36061229/
|title = <nowiki> Re: [Flightgear-devel] FGFS macOS Menubar </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 2nd, 2017
|added = Oct 2nd, 2017
|script_version = 0.40
}}</ref>

Technically, this entails replacing dialog.cxx with some code which builds up some special ‘PUI-Emulation’ QtQuick controls, so that existing dialogs (especially from Aircraft) continue to work. This mode will look somewhat ugly but hopefully no more ugly than PUI! And it helps that the set of widgets we have in PUI is limited, and the ‘tricky’ widgets (map, scrolling list, etc) are in the dialogs will will replace with new ones first.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068767/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

This PUI emulation isn't going to use any code from PLIB<ref>https://sourceforge.net/p/flightgear/mailman/message/36985303/</ref>, so what will remain from it in FG afterwards will be the FNT and JS components (reworked).<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068817/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> Florent Rougon </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

=== 2016 ===
We need to explore if Qt Quick or widgets is the better way to go, with a preference towards Qt Quick, since it will allow things closer to current PUI (semi-transparent widgets on top of the 3D content). It still allows creating separate windows too (Erik’s use case), but means we get consistent, custom theming on all platforms, since standard desktop look is not so nice for a flight-sim.

James intention is to make a QML-hosting OSG-drawable, and add this as a concept in Qt-enabled builds, then port some PUI dialogs to it, and see how easy / painful the process is. Hell create some QObjects which expose commands and the property tree and Nasal.

This has the advantage of not touching the OSG window at all, QtQuick simply provides some additional OpenGL rendering on top, which we pass events to - pretty much exactly the same as what we already do for PUI, and hopefully can co-exist with it. James got this working in a local OSG tree in a standalone demo, but that’s based on osgQt - he wants to see if he can make it work on a normal, non-Qt OSG window inside FlightGear.<ref>https://sourceforge.net/p/flightgear/mailman/message/35156051/</ref>

The idea is to host an XML dialog (Currently done with PUI) from Qt also. The question is if that can be done keeping ‘source compatibility’ exactly with the current UI XML and Nasal interface. It probably can be, but many of the PUI widgets have really ugly APIs, especially for combo-boxes, drop-down menus and scrolling lists, where it makes sense to map a Nasal class to a Qt ItemModel, which would be more elegant and easy to work with in both Nasal and integrate on the Qt side. But obviously would mean changing the dialog sources.

Of course, aircraft dialogs tend to be simpler, and not use the more complex PUI widgets, precisely for reasons like this, but that’s a limitation it would be best to remove.<ref>https://sourceforge.net/p/flightgear/mailman/message/35155721/</ref>


== References ==
{{Appendix}}

[[Category:PUI| ]]
[[Category:Rendering roadblocks]]

PUI

2023-04-19T19:14:56Z

Hooray: /* Status */ https://sourceforge.net/p/flightgear/mailman/message/37833149/

{{Feature to be removed|version=2023.3|reason=[[Plib]]/PUI is to be removed and replaced by a [[Canvas widget matrix|Canvas/Nasal based solution]] to help improve compatibility with [[OSG]] 3.6+ and [[OpenGL]] 4.x ([[Core Profile support|OpenGL Core Profile]], see [[2022.X Release plan]] ) and improve performance by [[Unifying the 2D rendering backend via canvas|phasing out legacy OpenGL code]]. Therefore, people should be careful when extending the '''PUI''' based legacy GUI engine<ref>https://sourceforge.net/p/flightgear/mailman/message/34921495/</ref><ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35157325/
|title = <nowiki> Re: [Flightgear-devel] GUI options (Was: Aircraft center) </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jun 14th, 2016
|added = Jun 14th, 2016
|script_version = 0.40
}}</ref> and coordinate any related work with the devel mailing list first-this applies particularly to adding any [[Template:PUI_widget|additional hard-coded PUI widgets]]. }}
[[File:Exit.png|thumb|FlightGear GUI dialog (exit.xml)stored in $FG_ROOT/gui/dialogs]]
{{GUI Navbar}}

[[File:Custom-autopilot-dialog.png|right|200px]]
[[PUI]] is the standard GUI engine used in FlightGear, it is part of [[PLIB]] and is using raw, fixed-pipeline, [[OpenGL]] code internally (no [[OpenSceneGraph]]). As of mid 2021, FlightGear is in the process of working towards adopting the OpenGL Core Profile, this means that [[PUI]] is causing trouble and needs to be replaced/disabled or ported.

PUI provides a fairly basic, but robust, set of widgets. PUI is also used for rendering the [[Menubar]].

FlightGear uses a GUI widget set that is implemented on top of raw (legacy) [[OpenGL]]. This has many advantages from a portability standpoint and from the standpoint of integrating with window systems. [[PUI]] doesn't have every feature under the sun, but it was never meant to. It's relatively small, lean, mean, and written on top of [[OpenGL]] which makes life *much* easier for us.

[[PUI]] already is a separate distinct library within Plib. It depends on some central utility stuff, but that's about it. So it is pretty stripped down and separate already.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg26011.html</ref>

We are to some extent hamstrung by the rather old GUI toolkit we use. However, replacing that is going to be non-trivial, and it would affect not just the core GUI but also all the dialog boxes that have been set up for particular aircraft.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg25985.html</ref>

Flightgear can look amazing when you use the HDR pipeline. We absolutely need this to stay relevant. The problem is that HDR is not compatible with OpenGL1 PUI. Work on getting rid of PUI has been going on for over a decade (longer than it took to implement it).<ref>https://sourceforge.net/p/flightgear/mailman/message/37727346/</ref>

[[File:menubar2.jpg|517px]]

== Replacement status ==
{{See also|FlightGear_and_OpenGL_ES#Example:_disabling_PUI}}

{{Note| Update 09/2022: The PUI replacement [[QtQuick_use_in_FlightGear#Background|was going to be Qt]] but it started to get very complicated with changes in Qt 5.15 + Qt 6, so James is going with a more light-weight Canvas based approach now.

Qt added support for Vulkan / Metal / D3D starting in 5.15, but FlightGear / OpenSceneGraph can’t support those, so integrating the two renderers went from being ‘complicated but ok’ to ‘very very complicated’.

So now James is going with something much more lightweight using some C++ compatibility code, some Nasal for styling and the existing [[Canvas widgets|Canvas widget rendering]] from Thomas Geymayer (TheTom) with some extensions and additions, based on the [[Howto:Processing_legacy_PUI_dialogs_using_Canvas#Original_Discussion|plans originally discussed when the Canvas GUI system was added to FlightGear]]: some pieces are in FlightGear & FGData already.

James has basic dialogs working okay but not the more complex ones and everything looks kind of ugly, he needs to improve the visual look before he shares screenshots to avoid everyone freaking out :) The disadvantage of this approach is James is far from expert at creating visual appearances this way, so it’s kind on unrewarding and slow for him. If someone likes messing with CSS-type styling, border-images and hover-states, ping him since we could probably move things also faster <ref>https://sourceforge.net/p/flightgear/mailman/message/37701750/</ref>}}

=== Motivation ===
{{Main article|Core Profile support}}

The bigger issue here is we need to ditch [[PUI]] (which is in progress) and some OpenGL 1.0 code (HUD, 2D panels especially - can be #ifdef for now) so we can enable Core profile on Mac - since Mac 4.x support (we only hit about 4.3 alas, but with some extensions to get in sight of 4.5) is Core profile only, no Compatability mode.

Improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, many people are convinced PUI needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

While most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so [using Qt5] would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

== Canvas Emulation ==
{{See also|Canvas widget matrix}}
'''Last updated: 04/2023 <ref>https://sourceforge.net/p/flightgear/mailman/message/37805054/</ref>
'''
=== Status ===
As of 01/2023, the replacement for PUI is making good progress<ref>https://sourceforge.net/p/flightgear/mailman/message/37765706/</ref>.

In February 2022, James reported having something in progress locally, and that should even be something we can try in March/April 2022. Hopefully that’s quick enough, knowing it has been a long time coming.<ref>https://sourceforge.net/p/flightgear/mailman/message/37606439/</ref>

There's now an XML to Nasal bridge, to keep PUI dialogs working (Disabled by a CMake option)
This is implemented on top of the [[Canvas]] system.

This builds equivalent C++ objects to what the [[PUI]] dialogs build, with properties exposed to Nasal.
Peer objects are created by Nasal [[callbacks]], which can implement the various dialog functions needed to keep compatibility, especially the [[#Background|‘update’ and ‘apply’ hooks]].<ref>https://sourceforge.net/p/flightgear/flightgear/ci/cbd5ef9e7b8f433dbc1ba97bae7d7cfc894e7cef/</ref>

Use the following [[Building using CMake|cmake option]] to enable this code: <code>-DENABLE_PUICOMPAT=ON</code>

{{Note|If you compiled with PUICompatibility enabled, but still don't see any dialogs - only the menubar, you might need to enable the GUI module in defaults.xml<ref>https://sourceforge.net/p/flightgear/mailman/message/37833149/</ref>}}

The new Compatibility files can now be found in $FG_SRC/GUI:

* {{flightgear file|src/GUI/FGPUICompatDialog.cxx }}
* {{flightgear file|src/GUI/FGPUICompatDialog.hxx }}
* {{flightgear file|src/GUI/PUICompatObject.cxx }}

01/2023: James is slowly working on creating the pop-up menu and combo-box widgets [...]

One of the major things slowing down James' work on the popup-menu and combo box is time to restart the simulator for each change, he is looking for some solution to re-load the widget Nasal code independently. <ref><https://sourceforge.net/p/flightgear/mailman/message/37756183/</ref>

James has done about 75% (hah!) of the C++ work to enable live reloading of modules this way, but unfortunately there are some code paths that would become crashy if you use the feature for the Canvas: because it would reference the ‘old’ (pre-reload) Nasal code, and not the new one, and therefore you’d get a weird mix of old and new, and then just crash the sim. To fix it properly I need to track down those places that store a reference to Canvas and give them a re-init method, so we don’t keep the stale references.

The general non-fun-ness of that kind of debugging is James has been making such slow progress on my PUI replacement widgets recently <ref>https://sourceforge.net/p/flightgear/mailman/message/37756263/</ref>

=== Todo ===
Nothing in particular : help debugging the grid layout (which is in simgear) would be good. For now you could create a grid layout manually using some Nasal.

For the menubar, we need to expose the C++ data to Nasal : we need a FGCompatMenuBar (alongisde FGPUIMenuBar) implementing FGMenubar which calls _createMenuObject in MenuBar.nas, using the same way I lookup and call _createDialogPeer in XMLDialog.nas

(Make sure you don’t break the macOS native menubar in the process!)

You can probably pass a wrapped SGpropertyNode into this, and then fill in the stubs in that file to use the Menu widgets Frederic has written.

Global menu keybindings won’t worry but don’t touch that, I have a separate plan for it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37805736/</ref>

As of 04/2023, remaining items on the todo list are: <ref>https://sourceforge.net/p/flightgear/mailman/message/37805060/</ref>

* Grid layout
** GridLayout needs debugged: After this, the basic UI is usable, would probably make it a switchable option on ‘next’ (I can already use the simulator with the new UI today, but all the sizes are off in the grid layouts which we use everywhere)

* list
* table (and tree ?) models corresponding views
* waypoint list
* Re-write the waypoint list and airport dialog to work again (since these use custom widgets):
** log list
** airport-list equivalents
* Nasal access to the menu i18n functions
* selection support for single- and multi-line text (which is being worked on -> CanvasPangoText)
* Keyboard shortcut handling, although this is not really a PUI vs replacement issue, to me we should handle UI shortcuts in the same was normal keyboard.xml shortcuts
** this previously worked because PUI got ‘first chance’ at handling key input. But we always had duplication between keyboard.xml and other places, so I would rather standardise on keyboard.xml, but allow a UI element to set a scope for shortcuts. (So that Copy/paste shortcuts etc can work in a text input, at least … but probably some other standard ones) <ref>https://sourceforge.net/p/flightgear/mailman/message/37805188/</ref>
* Ensure all the places which use the PUI combo-box and list-widget work : there’s a few of these.

The CanvasPangoText stuff is needed but we can perfectly well run the UI on next without it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37805176/</ref>

=== Parser ===
{{Main article|pui2canvas}}
The corresponding Nasal/Canvas module to dynamically "translate" legacy PUI/XML dialogs into Canvas dialogs (at runtime), is to be found in {{fgdata file|Nasal/gui/XMLDialog.nas}} <ref>https://sourceforge.net/p/flightgear/fgdata/ci/fe7c87b21a69f88ddb87d89453c48d12b69660e2/</ref>

=== Widgets ===
{{Main article|Howto:Creating a Canvas GUI Widget}}

It’s split between Simgear (see classes with widget / layout in the name) and in FGData. (Eg widgets/Button.nas) To be able to use the existing dialog XML files un-modified (which is a design goal), James is extending the widget types with many additional ones (eg PUI has slider, dial, combo-box, checkbox, all of which need to be created, see [[Canvas widget matrix]].

This is about 30% done and is the bit he's very slow at). Thomas’s canvas widgets have a very good separation of API + state from appearance, so all styling is in its own file, and James is being very strict about maintaining this separation, so we also retain the re-styling feature of the PUI UI, which many people also rely on. This does make the process of adding new widgets more complex, however.

{{See also|Canvas widgets}}

=== Layouting ===
The other thing is to preserve all the layouting: James has added a grid layout to Simgear, since that is supported by the existing PUI code (even though the layouts are not actually part of PUI itself). The problem is getting the sizing / hinting of all the widgets to match the PUI values, so that dialogs look approximately the same under the new UI as they did with PUI; again this a design goal so that all existing dialogs in aircraft and add-ons, which we can’t update, continue to work and be usable. Debugging that is also proving quite tricky, since there’s all kinds of hard-coded assumptions built into PUI widgets about pixels, font-sizes etc which are not true in the new system.<ref>https://sourceforge.net/p/flightgear/mailman/message/37701792/</ref>

== Background ==
In FlightGear, PUI dialogs are standard [[PropertyList XML File]]s that are stored in $FG_ROOT/gui/dialogs, they can contain the widgets mentioned in {{readme file|gui}}, using a simple layout engine discussed in {{readme file|layout}}, and bindings using a combination of so called fgcommands operating on properties (see {{readme file|commands}}) and custom [[Nasal]] (FlightGear scripting) code.

In addition, each PUI/XML dialog may contain Nasal script sections that are executed when opening/closing the dialog, a feature which is commonly used for procedurally creating/updating widgets using the [[Nasal_library#cmdarg.28.29|cmdarg() API]], which allows the dialog tree to be traversed and manipulated prior to the dialog being rendered.
Widgets can be conditionally hidden/shown using a wrapper for [[Conditions|SGCondition]] in [[Nasal_library/props|props.nas]]
The <code>canvas</code> widget also supports its own embedded Nasal code section to execute arbitrary widget specific Nasal code upon opening/closing the dialog/widget.

PUI/XML dialogs can be loaded, dynamically created, updated and closed using a handful of fgcommands:
* {{fgcommand|dialog-new}}
* {{fgcommand|dialog-show}}
* {{fgcommand|dialog-update}}
* {{fgcommand|dialog-apply}}
* {{fgcommand|dialog-close}}

PUI related OpenGL code is particularly infamous for causing rendering artifacts for people on AMD/ATI and Intel hardware (especially in combination with certain fonts/styles and [[Effects|effects]]/[[Shaders|shaders]]), see {{Issue|2213}}.

PUI is also known to affect rendering performance quite significantly (see {{search |keywords=anthrax+gui}}), while also preventing FlightGear from using a more recent version of OpenGL<ref>http://sourceforge.net/p/flightgear/mailman/message/34532040/</ref><ref>http://forum.flightgear.org/viewtopic.php?f=71&t=24046</ref>.

However, improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Besides, while most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

But given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, graphics folks are also convinced it needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

In addition, [[OpenSceneGraph]] (OSG) can obviously not help optimize any PUI related GL code and PUI widgets are generally considered to be pretty archaic and not easy to extend<ref>http://sourceforge.net/p/flightgear/mailman/message/26832164/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587120/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587272/</ref>.

{{Note|We use the GUI code from PLIB, which doesn't know anything about OSG. See the SGPuDrawable class in $FG_SRC/Viewer/renderer.cxx for the implementation. The one catch is that OSG has a strong notion of separation between the update of a "scene" and its rendering, and that might not play well with arbitrary existing OpenGL code. }}

As of late 2015, there is heavy activity towards providing alternatives to a PUI-based UI:
* [[Integrated Web GUI]] (external, browser-based - fully asynchronous)
* [[Howto:Processing legacy PUI dialogs using Canvas]] (internal, using the [[Canvas]] system and a simple [[Nasal]] parser to deal with existing PUI/XML dialogs)

<gallery mode="packed">
Early-Phi-screen shot.PNG|Screenshot showing [[Phi]]
About-dialog-rendered-by-canvas.png|Screenshot showing a dialog rendered by the [[Howto:Processing legacy PUI dialogs using Canvas|pui2canvas parser]]
</gallery>

== History ==
{{Caution|This is merely kept for future reference, many of the ideas discussed below have become obsolete as of 09/2022, if in doubt, please get in touch via devel-list.}}
=== 2021 ===
In early 2021, James did a brief evaluation of [https://github.com/ocornut/imgui ImGUI] as a possibility - he's also evaluating it in some projects at his day job.

The API is interesting if you’re starting from scratch and only exclusively in C++, but it’s not a great fit for how we define GUIs in FG (via [[XML]]/[[Nasal]]): there is no back door that he could find, to access the persistent state of the GUI, or build it up in a data-driven way. So making a mapping to keep our existing GUI XML working (and updating correctly) becomes a bit of a chore.<ref>https://sourceforge.net/p/flightgear/mailman/message/37295586/</ref>

Pretty much all of the FlightGear GUI is defined in XML space, except for a few oddments. Let’s say 95% at this point.

Additionally, even if we were to change that for the core sim (and James' current plan is to keep the XML syntax and just extend it), the installed base of '''aircraft''' ship their own XML dialogs (eg., replacing the autopilot dialog with a custom one, or just adding their own aircraft-specific helper controls for doors / lights / cargo / whatever). So even if we found the most sublimely beautiful, intuitive, compact GUI description language in the world, we have to keep the XML syntax working as-is, for the foreseeable future.

Given this, James' intention is to replace the output side [[PUI]] but keep the front-end side (XML / properties / bindings) unchanged, and therefore backwards compatible, and simply add some new types / options / widget types going forward. This will mean we still have to deal with the slightly cumbersome XML+Nasal syntax, but, well, it’s not *that* cumbersome. <ref>https://sourceforge.net/p/flightgear/mailman/message/37296280/</ref>

In mid 2021, James reported that he is working on some ‘PUICompat’ classes which hold/own/represent the GUI state in C++, but which can be used with [[Nasal/CppBind|Nasal CppBind]]. And of course we could indeed expose those later on. <ref>https://sourceforge.net/p/flightgear/mailman/message/37297727/</ref>

In July 2021, James suggested not to worry about the existing GUI code, it’s going in the bin.<ref>https://sourceforge.net/p/flightgear/mailman/message/37325905/</ref>

For the time being, the in-sim GUi can’t do Unicode yet, but James is working on it, hopefully available soon.<ref>https://sourceforge.net/p/flightgear/mailman/message/37328200/</ref>
Also, the in-sim menubar will change with the new GUI, *and* we use a native menubar on macOS. Until James replaces the PUI fonts we can’t use Unicode symbols. So, will have to come back to it once the new GUI is merged.<ref>https://sourceforge.net/p/flightgear/mailman/message/37327237/</ref>

=== 2020 ===
As of 03/2020, the PLIB replacement was reported to be in the backlog <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36951255/
|title = <nowiki>Re: [Flightgear-devel] C++ and/or OSG question </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Mar 18th, 2020
|added = Mar 18th, 2020
|script_version = 0.50
}}</ref>.

With PLIB replacement work likely being re-scheduled for [[Post FlightGear 2020.2 LTS changes]] <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36985375/
|title = <nowiki>Re: [Flightgear-devel] Working Group Proposal - Boost and PLIB replacement - Delegation and Teamwork </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = April 18th, 2020
|added = April 18th, 2020
|script_version = 1.10
}}</ref>.

In 08/2020, James stated that he was still working (exceptionally slowly!) on replacing PUI (as part of removing legacy OpenGL code (PUI, HUD, 2d panels, porting Canvas away form ShivaVG), so we can switch to Vulkan/VSG at some point (ideally at some point before Apple turn off OpenGL support…)), and that he doesn't think /any/ of us *want* to be working on these features particularly, but projects like these need to be done before anyone can have fun with VSG or Vulkan (personally James would be very enthusiastic about working on VSG support (being on macOS, I also have the most to lose / gain from it)). Sometimes that’s just how it goes. Equally they will all benefit the project ultimately, but the payoff both for the individual and the project is very drawn out. <ref>https://sourceforge.net/p/flightgear/mailman/message/37077158/</ref>

In 10/2020, the estimation is that PUI should be going away really ‘soon’, the replacement code is already in next / 2020.2. (There’s no plan to actually /use/ the new UI code in 2020.2, but if the bugs in it prove simple, we could actually turn it for specific dialog: it seems very unlikely this makes sense for a stable release however)<ref>https://sourceforge.net/p/flightgear/mailman/message/37123818/</ref>

The fixed-function removal, is actively in hand (Gaetan is working on the 2D panel part, and James is going to focus on PUI in the rest of 2020). James hopes that means next year he can focus on Vulkan, or at least, using OSG as if /were/ VSG, so the migration in a year or two when VSG is stable, is not so painful.<ref>https://sourceforge.net/p/flightgear/mailman/message/37129098/</ref>

The PUI UI and replacement can co-exist in the same build (they already do, effectively.<ref>https://sourceforge.net/p/flightgear/mailman/message/37131297/</ref>

In 11/2020, James suggested not to worry about details such as PUI styling/theming etc: we’re not making such changes for the LTS, and PUI should be gone before the next release.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142225/</ref> Also, he recommended (to everyone) to stop touching GUI stuff for a few weeks, as he's about to turn it all on its head.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142356/</ref>

=== 2019 ===
The new GUI has been incubating for a few years, but there's apparently been a lot of progress as of 10/2019.

It is likely the new GUI will be a user opt-in feature - at least initially. The sunset of the PLIB library _could_ happen relatively soon, but
people will need to see the new GUI and react to it before we could commit to PLIB removal <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36784489/
|title = <nowiki>Re: [Flightgear-devel] in Flightgear/Simgear C++ Code: What needs Doing? What are YOU Doing? What would you do if you had the time? </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Oct 14th, 2019
|added = Oct 14th, 2019
|script_version = 0.50
}}</ref>.

In 02/2019, James stated that the new UI is coming quite soon. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36589420/
|title = <nowiki> Re: [Flightgear-devel] Lagging </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Feb 17th, 2019
|added = Feb 17th, 2019
|script_version = 0.40
}}</ref>

=== 2018 ===
{{See also|QtQuick use in FlightGear}}

According to James, we have to accept that changes like testing or making [[PUI]] a modular thing or moving the JS code tend to have an immediate pain for some people (because strange stuff gets broken, and takes some time to get fixed), whereas the payoff in terms of improved joystick handling or replacing the UI or testing of all subsystems will take some months or years to be felt.<ref>https://sourceforge.net/p/flightgear/mailman/message/36323240/</ref>

James said he was in the middle of porting the launcher’s final tab (location) to the new UI scheme, once that’s done he will start sketching out the ‘in sim’ settings UI using the same pieces. He’ll send a request for contributions around about that in the next three-four weeks, once he has enough templates & examples that there is a clear pattern to follow.<ref>https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/2d10f16c-ddc8-07f3-07e7-eca2a0a0d55f%40zaretto.com/#msg36293586</ref>

James announced that the launcher is now feature complete with the QtQuick UI, he’ll keep making bug-fixes of course as people report them, but my todo list for the core features is now done<ref>https://sourceforge.net/p/flightgear/mailman/message/36355833/</ref>.

=== 2017 ===

In 10/2017, James said he was getting really close to having the PUI replacement UI suitable for beta-testing.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36067646/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 7th, 2017
|added = Oct 7th, 2017
|script_version = 0.40
}}</ref>

Originally, James was hoping to land the PUI replacement GUI in the last dev cycle in 2017 (at least as a proof-of-concept, probably not as the default UI), so wouldn’t expend lots of effort on things like collapsible sections which might be a lot of work with the current PUI/Canvas approaches, but are trivial with the new [[QtQuick use in FlightGear|QtQuick based UI scheme]].<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36059822/
|title = <nowiki> Re: [Flightgear-devel] Canvas MapLayer for OpenStreetMap, OpenAIP,
VFR Sectionals </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 1st, 2017
|added = Oct 1st, 2017
|script_version = 0.40
}}</ref>

Once the basic new UI is in place we can experiment with different re-arrangements easily, without being limited by PUI. (James expects PUI to live on as the default / alternate UI while this happens)<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36061229/
|title = <nowiki> Re: [Flightgear-devel] FGFS macOS Menubar </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 2nd, 2017
|added = Oct 2nd, 2017
|script_version = 0.40
}}</ref>

Technically, this entails replacing dialog.cxx with some code which builds up some special ‘PUI-Emulation’ QtQuick controls, so that existing dialogs (especially from Aircraft) continue to work. This mode will look somewhat ugly but hopefully no more ugly than PUI! And it helps that the set of widgets we have in PUI is limited, and the ‘tricky’ widgets (map, scrolling list, etc) are in the dialogs will will replace with new ones first.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068767/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

This PUI emulation isn't going to use any code from PLIB<ref>https://sourceforge.net/p/flightgear/mailman/message/36985303/</ref>, so what will remain from it in FG afterwards will be the FNT and JS components (reworked).<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068817/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> Florent Rougon </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

=== 2016 ===
We need to explore if Qt Quick or widgets is the better way to go, with a preference towards Qt Quick, since it will allow things closer to current PUI (semi-transparent widgets on top of the 3D content). It still allows creating separate windows too (Erik’s use case), but means we get consistent, custom theming on all platforms, since standard desktop look is not so nice for a flight-sim.

James intention is to make a QML-hosting OSG-drawable, and add this as a concept in Qt-enabled builds, then port some PUI dialogs to it, and see how easy / painful the process is. Hell create some QObjects which expose commands and the property tree and Nasal.

This has the advantage of not touching the OSG window at all, QtQuick simply provides some additional OpenGL rendering on top, which we pass events to - pretty much exactly the same as what we already do for PUI, and hopefully can co-exist with it. James got this working in a local OSG tree in a standalone demo, but that’s based on osgQt - he wants to see if he can make it work on a normal, non-Qt OSG window inside FlightGear.<ref>https://sourceforge.net/p/flightgear/mailman/message/35156051/</ref>

The idea is to host an XML dialog (Currently done with PUI) from Qt also. The question is if that can be done keeping ‘source compatibility’ exactly with the current UI XML and Nasal interface. It probably can be, but many of the PUI widgets have really ugly APIs, especially for combo-boxes, drop-down menus and scrolling lists, where it makes sense to map a Nasal class to a Qt ItemModel, which would be more elegant and easy to work with in both Nasal and integrate on the Qt side. But obviously would mean changing the dialog sources.

Of course, aircraft dialogs tend to be simpler, and not use the more complex PUI widgets, precisely for reasons like this, but that’s a limitation it would be best to remove.<ref>https://sourceforge.net/p/flightgear/mailman/message/35155721/</ref>


== References ==
{{Appendix}}

[[Category:PUI| ]]
[[Category:Rendering roadblocks]]

PUI

2023-04-19T11:37:32Z

Hooray: /* Todo */

{{Feature to be removed|version=2023.3|reason=[[Plib]]/PUI is to be removed and replaced by a [[Canvas widget matrix|Canvas/Nasal based solution]] to help improve compatibility with [[OSG]] 3.6+ and [[OpenGL]] 4.x ([[Core Profile support|OpenGL Core Profile]], see [[2022.X Release plan]] ) and improve performance by [[Unifying the 2D rendering backend via canvas|phasing out legacy OpenGL code]]. Therefore, people should be careful when extending the '''PUI''' based legacy GUI engine<ref>https://sourceforge.net/p/flightgear/mailman/message/34921495/</ref><ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35157325/
|title = <nowiki> Re: [Flightgear-devel] GUI options (Was: Aircraft center) </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jun 14th, 2016
|added = Jun 14th, 2016
|script_version = 0.40
}}</ref> and coordinate any related work with the devel mailing list first-this applies particularly to adding any [[Template:PUI_widget|additional hard-coded PUI widgets]]. }}
[[File:Exit.png|thumb|FlightGear GUI dialog (exit.xml)stored in $FG_ROOT/gui/dialogs]]
{{GUI Navbar}}

[[File:Custom-autopilot-dialog.png|right|200px]]
[[PUI]] is the standard GUI engine used in FlightGear, it is part of [[PLIB]] and is using raw, fixed-pipeline, [[OpenGL]] code internally (no [[OpenSceneGraph]]). As of mid 2021, FlightGear is in the process of working towards adopting the OpenGL Core Profile, this means that [[PUI]] is causing trouble and needs to be replaced/disabled or ported.

PUI provides a fairly basic, but robust, set of widgets. PUI is also used for rendering the [[Menubar]].

FlightGear uses a GUI widget set that is implemented on top of raw (legacy) [[OpenGL]]. This has many advantages from a portability standpoint and from the standpoint of integrating with window systems. [[PUI]] doesn't have every feature under the sun, but it was never meant to. It's relatively small, lean, mean, and written on top of [[OpenGL]] which makes life *much* easier for us.

[[PUI]] already is a separate distinct library within Plib. It depends on some central utility stuff, but that's about it. So it is pretty stripped down and separate already.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg26011.html</ref>

We are to some extent hamstrung by the rather old GUI toolkit we use. However, replacing that is going to be non-trivial, and it would affect not just the core GUI but also all the dialog boxes that have been set up for particular aircraft.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg25985.html</ref>

Flightgear can look amazing when you use the HDR pipeline. We absolutely need this to stay relevant. The problem is that HDR is not compatible with OpenGL1 PUI. Work on getting rid of PUI has been going on for over a decade (longer than it took to implement it).<ref>https://sourceforge.net/p/flightgear/mailman/message/37727346/</ref>

[[File:menubar2.jpg|517px]]

== Replacement status ==
{{See also|FlightGear_and_OpenGL_ES#Example:_disabling_PUI}}

{{Note| Update 09/2022: The PUI replacement [[QtQuick_use_in_FlightGear#Background|was going to be Qt]] but it started to get very complicated with changes in Qt 5.15 + Qt 6, so James is going with a more light-weight Canvas based approach now.

Qt added support for Vulkan / Metal / D3D starting in 5.15, but FlightGear / OpenSceneGraph can’t support those, so integrating the two renderers went from being ‘complicated but ok’ to ‘very very complicated’.

So now James is going with something much more lightweight using some C++ compatibility code, some Nasal for styling and the existing [[Canvas widgets|Canvas widget rendering]] from Thomas Geymayer (TheTom) with some extensions and additions, based on the [[Howto:Processing_legacy_PUI_dialogs_using_Canvas#Original_Discussion|plans originally discussed when the Canvas GUI system was added to FlightGear]]: some pieces are in FlightGear & FGData already.

James has basic dialogs working okay but not the more complex ones and everything looks kind of ugly, he needs to improve the visual look before he shares screenshots to avoid everyone freaking out :) The disadvantage of this approach is James is far from expert at creating visual appearances this way, so it’s kind on unrewarding and slow for him. If someone likes messing with CSS-type styling, border-images and hover-states, ping him since we could probably move things also faster <ref>https://sourceforge.net/p/flightgear/mailman/message/37701750/</ref>}}

=== Motivation ===
{{Main article|Core Profile support}}

The bigger issue here is we need to ditch [[PUI]] (which is in progress) and some OpenGL 1.0 code (HUD, 2D panels especially - can be #ifdef for now) so we can enable Core profile on Mac - since Mac 4.x support (we only hit about 4.3 alas, but with some extensions to get in sight of 4.5) is Core profile only, no Compatability mode.

Improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, many people are convinced PUI needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

While most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so [using Qt5] would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

== Canvas Emulation ==
{{See also|Canvas widget matrix}}
'''Last updated: 04/2023 <ref>https://sourceforge.net/p/flightgear/mailman/message/37805054/</ref>
'''
=== Status ===
As of 01/2023, the replacement for PUI is making good progress<ref>https://sourceforge.net/p/flightgear/mailman/message/37765706/</ref>.

In February 2022, James reported having something in progress locally, and that should even be something we can try in March/April 2022. Hopefully that’s quick enough, knowing it has been a long time coming.<ref>https://sourceforge.net/p/flightgear/mailman/message/37606439/</ref>

There's now an XML to Nasal bridge, to keep PUI dialogs working (Disabled by a CMake option)
This is implemented on top of the [[Canvas]] system.

This builds equivalent C++ objects to what the [[PUI]] dialogs build, with properties exposed to Nasal.
Peer objects are created by Nasal [[callbacks]], which can implement the various dialog functions needed to keep compatibility, especially the [[#Background|‘update’ and ‘apply’ hooks]].<ref>https://sourceforge.net/p/flightgear/flightgear/ci/cbd5ef9e7b8f433dbc1ba97bae7d7cfc894e7cef/</ref>

Use the following [[Building using CMake|cmake option]] to enable this code: <code>-DENABLE_PUICOMPAT=ON</code>

The new Compatibility files can now be found in $FG_SRC/GUI:

* {{flightgear file|src/GUI/FGPUICompatDialog.cxx }}
* {{flightgear file|src/GUI/FGPUICompatDialog.hxx }}
* {{flightgear file|src/GUI/PUICompatObject.cxx }}

01/2023: James is slowly working on creating the pop-up menu and combo-box widgets [...]

One of the major things slowing down James' work on the popup-menu and combo box is time to restart the simulator for each change, he is looking for some solution to re-load the widget Nasal code independently. <ref><https://sourceforge.net/p/flightgear/mailman/message/37756183/</ref>

James has done about 75% (hah!) of the C++ work to enable live reloading of modules this way, but unfortunately there are some code paths that would become crashy if you use the feature for the Canvas: because it would reference the ‘old’ (pre-reload) Nasal code, and not the new one, and therefore you’d get a weird mix of old and new, and then just crash the sim. To fix it properly I need to track down those places that store a reference to Canvas and give them a re-init method, so we don’t keep the stale references.

The general non-fun-ness of that kind of debugging is James has been making such slow progress on my PUI replacement widgets recently <ref>https://sourceforge.net/p/flightgear/mailman/message/37756263/</ref>

=== Todo ===
Nothing in particular : help debugging the grid layout (which is in simgear) would be good. For now you could create a grid layout manually using some Nasal.

For the menubar, we need to expose the C++ data to Nasal : we need a FGCompatMenuBar (alongisde FGPUIMenuBar) implementing FGMenubar which calls _createMenuObject in MenuBar.nas, using the same way I lookup and call _createDialogPeer in XMLDialog.nas

(Make sure you don’t break the macOS native menubar in the process!)

You can probably pass a wrapped SGpropertyNode into this, and then fill in the stubs in that file to use the Menu widgets Frederic has written.

Global menu keybindings won’t worry but don’t touch that, I have a separate plan for it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37805736/</ref>

As of 04/2023, remaining items on the todo list are: <ref>https://sourceforge.net/p/flightgear/mailman/message/37805060/</ref>

* Grid layout
** GridLayout needs debugged: After this, the basic UI is usable, would probably make it a switchable option on ‘next’ (I can already use the simulator with the new UI today, but all the sizes are off in the grid layouts which we use everywhere)

* list
* table (and tree ?) models corresponding views
* waypoint list
* Re-write the waypoint list and airport dialog to work again (since these use custom widgets):
** log list
** airport-list equivalents
* Nasal access to the menu i18n functions
* selection support for single- and multi-line text (which is being worked on -> CanvasPangoText)
* Keyboard shortcut handling, although this is not really a PUI vs replacement issue, to me we should handle UI shortcuts in the same was normal keyboard.xml shortcuts
** this previously worked because PUI got ‘first chance’ at handling key input. But we always had duplication between keyboard.xml and other places, so I would rather standardise on keyboard.xml, but allow a UI element to set a scope for shortcuts. (So that Copy/paste shortcuts etc can work in a text input, at least … but probably some other standard ones) <ref>https://sourceforge.net/p/flightgear/mailman/message/37805188/</ref>
* Ensure all the places which use the PUI combo-box and list-widget work : there’s a few of these.

The CanvasPangoText stuff is needed but we can perfectly well run the UI on next without it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37805176/</ref>

=== Parser ===
{{Main article|pui2canvas}}
The corresponding Nasal/Canvas module to dynamically "translate" legacy PUI/XML dialogs into Canvas dialogs (at runtime), is to be found in {{fgdata file|Nasal/gui/XMLDialog.nas}} <ref>https://sourceforge.net/p/flightgear/fgdata/ci/fe7c87b21a69f88ddb87d89453c48d12b69660e2/</ref>

=== Widgets ===
{{Main article|Howto:Creating a Canvas GUI Widget}}

It’s split between Simgear (see classes with widget / layout in the name) and in FGData. (Eg widgets/Button.nas) To be able to use the existing dialog XML files un-modified (which is a design goal), James is extending the widget types with many additional ones (eg PUI has slider, dial, combo-box, checkbox, all of which need to be created, see [[Canvas widget matrix]].

This is about 30% done and is the bit he's very slow at). Thomas’s canvas widgets have a very good separation of API + state from appearance, so all styling is in its own file, and James is being very strict about maintaining this separation, so we also retain the re-styling feature of the PUI UI, which many people also rely on. This does make the process of adding new widgets more complex, however.

{{See also|Canvas widgets}}

=== Layouting ===
The other thing is to preserve all the layouting: James has added a grid layout to Simgear, since that is supported by the existing PUI code (even though the layouts are not actually part of PUI itself). The problem is getting the sizing / hinting of all the widgets to match the PUI values, so that dialogs look approximately the same under the new UI as they did with PUI; again this a design goal so that all existing dialogs in aircraft and add-ons, which we can’t update, continue to work and be usable. Debugging that is also proving quite tricky, since there’s all kinds of hard-coded assumptions built into PUI widgets about pixels, font-sizes etc which are not true in the new system.<ref>https://sourceforge.net/p/flightgear/mailman/message/37701792/</ref>

== Background ==
In FlightGear, PUI dialogs are standard [[PropertyList XML File]]s that are stored in $FG_ROOT/gui/dialogs, they can contain the widgets mentioned in {{readme file|gui}}, using a simple layout engine discussed in {{readme file|layout}}, and bindings using a combination of so called fgcommands operating on properties (see {{readme file|commands}}) and custom [[Nasal]] (FlightGear scripting) code.

In addition, each PUI/XML dialog may contain Nasal script sections that are executed when opening/closing the dialog, a feature which is commonly used for procedurally creating/updating widgets using the [[Nasal_library#cmdarg.28.29|cmdarg() API]], which allows the dialog tree to be traversed and manipulated prior to the dialog being rendered.
Widgets can be conditionally hidden/shown using a wrapper for [[Conditions|SGCondition]] in [[Nasal_library/props|props.nas]]
The <code>canvas</code> widget also supports its own embedded Nasal code section to execute arbitrary widget specific Nasal code upon opening/closing the dialog/widget.

PUI/XML dialogs can be loaded, dynamically created, updated and closed using a handful of fgcommands:
* {{fgcommand|dialog-new}}
* {{fgcommand|dialog-show}}
* {{fgcommand|dialog-update}}
* {{fgcommand|dialog-apply}}
* {{fgcommand|dialog-close}}

PUI related OpenGL code is particularly infamous for causing rendering artifacts for people on AMD/ATI and Intel hardware (especially in combination with certain fonts/styles and [[Effects|effects]]/[[Shaders|shaders]]), see {{Issue|2213}}.

PUI is also known to affect rendering performance quite significantly (see {{search |keywords=anthrax+gui}}), while also preventing FlightGear from using a more recent version of OpenGL<ref>http://sourceforge.net/p/flightgear/mailman/message/34532040/</ref><ref>http://forum.flightgear.org/viewtopic.php?f=71&t=24046</ref>.

However, improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Besides, while most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

But given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, graphics folks are also convinced it needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

In addition, [[OpenSceneGraph]] (OSG) can obviously not help optimize any PUI related GL code and PUI widgets are generally considered to be pretty archaic and not easy to extend<ref>http://sourceforge.net/p/flightgear/mailman/message/26832164/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587120/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587272/</ref>.

{{Note|We use the GUI code from PLIB, which doesn't know anything about OSG. See the SGPuDrawable class in $FG_SRC/Viewer/renderer.cxx for the implementation. The one catch is that OSG has a strong notion of separation between the update of a "scene" and its rendering, and that might not play well with arbitrary existing OpenGL code. }}

As of late 2015, there is heavy activity towards providing alternatives to a PUI-based UI:
* [[Integrated Web GUI]] (external, browser-based - fully asynchronous)
* [[Howto:Processing legacy PUI dialogs using Canvas]] (internal, using the [[Canvas]] system and a simple [[Nasal]] parser to deal with existing PUI/XML dialogs)

<gallery mode="packed">
Early-Phi-screen shot.PNG|Screenshot showing [[Phi]]
About-dialog-rendered-by-canvas.png|Screenshot showing a dialog rendered by the [[Howto:Processing legacy PUI dialogs using Canvas|pui2canvas parser]]
</gallery>

== History ==
{{Caution|This is merely kept for future reference, many of the ideas discussed below have become obsolete as of 09/2022, if in doubt, please get in touch via devel-list.}}
=== 2021 ===
In early 2021, James did a brief evaluation of [https://github.com/ocornut/imgui ImGUI] as a possibility - he's also evaluating it in some projects at his day job.

The API is interesting if you’re starting from scratch and only exclusively in C++, but it’s not a great fit for how we define GUIs in FG (via [[XML]]/[[Nasal]]): there is no back door that he could find, to access the persistent state of the GUI, or build it up in a data-driven way. So making a mapping to keep our existing GUI XML working (and updating correctly) becomes a bit of a chore.<ref>https://sourceforge.net/p/flightgear/mailman/message/37295586/</ref>

Pretty much all of the FlightGear GUI is defined in XML space, except for a few oddments. Let’s say 95% at this point.

Additionally, even if we were to change that for the core sim (and James' current plan is to keep the XML syntax and just extend it), the installed base of '''aircraft''' ship their own XML dialogs (eg., replacing the autopilot dialog with a custom one, or just adding their own aircraft-specific helper controls for doors / lights / cargo / whatever). So even if we found the most sublimely beautiful, intuitive, compact GUI description language in the world, we have to keep the XML syntax working as-is, for the foreseeable future.

Given this, James' intention is to replace the output side [[PUI]] but keep the front-end side (XML / properties / bindings) unchanged, and therefore backwards compatible, and simply add some new types / options / widget types going forward. This will mean we still have to deal with the slightly cumbersome XML+Nasal syntax, but, well, it’s not *that* cumbersome. <ref>https://sourceforge.net/p/flightgear/mailman/message/37296280/</ref>

In mid 2021, James reported that he is working on some ‘PUICompat’ classes which hold/own/represent the GUI state in C++, but which can be used with [[Nasal/CppBind|Nasal CppBind]]. And of course we could indeed expose those later on. <ref>https://sourceforge.net/p/flightgear/mailman/message/37297727/</ref>

In July 2021, James suggested not to worry about the existing GUI code, it’s going in the bin.<ref>https://sourceforge.net/p/flightgear/mailman/message/37325905/</ref>

For the time being, the in-sim GUi can’t do Unicode yet, but James is working on it, hopefully available soon.<ref>https://sourceforge.net/p/flightgear/mailman/message/37328200/</ref>
Also, the in-sim menubar will change with the new GUI, *and* we use a native menubar on macOS. Until James replaces the PUI fonts we can’t use Unicode symbols. So, will have to come back to it once the new GUI is merged.<ref>https://sourceforge.net/p/flightgear/mailman/message/37327237/</ref>

=== 2020 ===
As of 03/2020, the PLIB replacement was reported to be in the backlog <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36951255/
|title = <nowiki>Re: [Flightgear-devel] C++ and/or OSG question </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Mar 18th, 2020
|added = Mar 18th, 2020
|script_version = 0.50
}}</ref>.

With PLIB replacement work likely being re-scheduled for [[Post FlightGear 2020.2 LTS changes]] <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36985375/
|title = <nowiki>Re: [Flightgear-devel] Working Group Proposal - Boost and PLIB replacement - Delegation and Teamwork </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = April 18th, 2020
|added = April 18th, 2020
|script_version = 1.10
}}</ref>.

In 08/2020, James stated that he was still working (exceptionally slowly!) on replacing PUI (as part of removing legacy OpenGL code (PUI, HUD, 2d panels, porting Canvas away form ShivaVG), so we can switch to Vulkan/VSG at some point (ideally at some point before Apple turn off OpenGL support…)), and that he doesn't think /any/ of us *want* to be working on these features particularly, but projects like these need to be done before anyone can have fun with VSG or Vulkan (personally James would be very enthusiastic about working on VSG support (being on macOS, I also have the most to lose / gain from it)). Sometimes that’s just how it goes. Equally they will all benefit the project ultimately, but the payoff both for the individual and the project is very drawn out. <ref>https://sourceforge.net/p/flightgear/mailman/message/37077158/</ref>

In 10/2020, the estimation is that PUI should be going away really ‘soon’, the replacement code is already in next / 2020.2. (There’s no plan to actually /use/ the new UI code in 2020.2, but if the bugs in it prove simple, we could actually turn it for specific dialog: it seems very unlikely this makes sense for a stable release however)<ref>https://sourceforge.net/p/flightgear/mailman/message/37123818/</ref>

The fixed-function removal, is actively in hand (Gaetan is working on the 2D panel part, and James is going to focus on PUI in the rest of 2020). James hopes that means next year he can focus on Vulkan, or at least, using OSG as if /were/ VSG, so the migration in a year or two when VSG is stable, is not so painful.<ref>https://sourceforge.net/p/flightgear/mailman/message/37129098/</ref>

The PUI UI and replacement can co-exist in the same build (they already do, effectively.<ref>https://sourceforge.net/p/flightgear/mailman/message/37131297/</ref>

In 11/2020, James suggested not to worry about details such as PUI styling/theming etc: we’re not making such changes for the LTS, and PUI should be gone before the next release.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142225/</ref> Also, he recommended (to everyone) to stop touching GUI stuff for a few weeks, as he's about to turn it all on its head.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142356/</ref>

=== 2019 ===
The new GUI has been incubating for a few years, but there's apparently been a lot of progress as of 10/2019.

It is likely the new GUI will be a user opt-in feature - at least initially. The sunset of the PLIB library _could_ happen relatively soon, but
people will need to see the new GUI and react to it before we could commit to PLIB removal <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36784489/
|title = <nowiki>Re: [Flightgear-devel] in Flightgear/Simgear C++ Code: What needs Doing? What are YOU Doing? What would you do if you had the time? </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Oct 14th, 2019
|added = Oct 14th, 2019
|script_version = 0.50
}}</ref>.

In 02/2019, James stated that the new UI is coming quite soon. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36589420/
|title = <nowiki> Re: [Flightgear-devel] Lagging </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Feb 17th, 2019
|added = Feb 17th, 2019
|script_version = 0.40
}}</ref>

=== 2018 ===
{{See also|QtQuick use in FlightGear}}

According to James, we have to accept that changes like testing or making [[PUI]] a modular thing or moving the JS code tend to have an immediate pain for some people (because strange stuff gets broken, and takes some time to get fixed), whereas the payoff in terms of improved joystick handling or replacing the UI or testing of all subsystems will take some months or years to be felt.<ref>https://sourceforge.net/p/flightgear/mailman/message/36323240/</ref>

James said he was in the middle of porting the launcher’s final tab (location) to the new UI scheme, once that’s done he will start sketching out the ‘in sim’ settings UI using the same pieces. He’ll send a request for contributions around about that in the next three-four weeks, once he has enough templates & examples that there is a clear pattern to follow.<ref>https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/2d10f16c-ddc8-07f3-07e7-eca2a0a0d55f%40zaretto.com/#msg36293586</ref>

James announced that the launcher is now feature complete with the QtQuick UI, he’ll keep making bug-fixes of course as people report them, but my todo list for the core features is now done<ref>https://sourceforge.net/p/flightgear/mailman/message/36355833/</ref>.

=== 2017 ===

In 10/2017, James said he was getting really close to having the PUI replacement UI suitable for beta-testing.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36067646/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 7th, 2017
|added = Oct 7th, 2017
|script_version = 0.40
}}</ref>

Originally, James was hoping to land the PUI replacement GUI in the last dev cycle in 2017 (at least as a proof-of-concept, probably not as the default UI), so wouldn’t expend lots of effort on things like collapsible sections which might be a lot of work with the current PUI/Canvas approaches, but are trivial with the new [[QtQuick use in FlightGear|QtQuick based UI scheme]].<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36059822/
|title = <nowiki> Re: [Flightgear-devel] Canvas MapLayer for OpenStreetMap, OpenAIP,
VFR Sectionals </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 1st, 2017
|added = Oct 1st, 2017
|script_version = 0.40
}}</ref>

Once the basic new UI is in place we can experiment with different re-arrangements easily, without being limited by PUI. (James expects PUI to live on as the default / alternate UI while this happens)<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36061229/
|title = <nowiki> Re: [Flightgear-devel] FGFS macOS Menubar </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 2nd, 2017
|added = Oct 2nd, 2017
|script_version = 0.40
}}</ref>

Technically, this entails replacing dialog.cxx with some code which builds up some special ‘PUI-Emulation’ QtQuick controls, so that existing dialogs (especially from Aircraft) continue to work. This mode will look somewhat ugly but hopefully no more ugly than PUI! And it helps that the set of widgets we have in PUI is limited, and the ‘tricky’ widgets (map, scrolling list, etc) are in the dialogs will will replace with new ones first.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068767/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

This PUI emulation isn't going to use any code from PLIB<ref>https://sourceforge.net/p/flightgear/mailman/message/36985303/</ref>, so what will remain from it in FG afterwards will be the FNT and JS components (reworked).<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068817/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> Florent Rougon </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

=== 2016 ===
We need to explore if Qt Quick or widgets is the better way to go, with a preference towards Qt Quick, since it will allow things closer to current PUI (semi-transparent widgets on top of the 3D content). It still allows creating separate windows too (Erik’s use case), but means we get consistent, custom theming on all platforms, since standard desktop look is not so nice for a flight-sim.

James intention is to make a QML-hosting OSG-drawable, and add this as a concept in Qt-enabled builds, then port some PUI dialogs to it, and see how easy / painful the process is. Hell create some QObjects which expose commands and the property tree and Nasal.

This has the advantage of not touching the OSG window at all, QtQuick simply provides some additional OpenGL rendering on top, which we pass events to - pretty much exactly the same as what we already do for PUI, and hopefully can co-exist with it. James got this working in a local OSG tree in a standalone demo, but that’s based on osgQt - he wants to see if he can make it work on a normal, non-Qt OSG window inside FlightGear.<ref>https://sourceforge.net/p/flightgear/mailman/message/35156051/</ref>

The idea is to host an XML dialog (Currently done with PUI) from Qt also. The question is if that can be done keeping ‘source compatibility’ exactly with the current UI XML and Nasal interface. It probably can be, but many of the PUI widgets have really ugly APIs, especially for combo-boxes, drop-down menus and scrolling lists, where it makes sense to map a Nasal class to a Qt ItemModel, which would be more elegant and easy to work with in both Nasal and integrate on the Qt side. But obviously would mean changing the dialog sources.

Of course, aircraft dialogs tend to be simpler, and not use the more complex PUI widgets, precisely for reasons like this, but that’s a limitation it would be best to remove.<ref>https://sourceforge.net/p/flightgear/mailman/message/35155721/</ref>


== References ==
{{Appendix}}

[[Category:PUI| ]]
[[Category:Rendering roadblocks]]

Template:Canvas Widget Matrix

2023-04-19T11:35:00Z

Hooray: /* Status */

{{Note|If you'd like to get involved in working on widgets or creating new ones, please get in touch via the devel-mailing list to coordinate related efforts with James Turner first.}}
The following tablet represents a list of Canvas GUI widgets, with the goal being to implement a sufficient number of widgets to re-implement/emulate basic [[PUI]] functionality by using the new {{Fgdata file|Nasal/gui/XMLDialog.nas}} module that translates existing PUI/XML dialogs into Canvas dialogs dynamically (i.e. at runtime). To learn more about the rationale, please see [[PUI#Replacement status]], [[Unifying the 2D rendering backend via canvas]] and [[Hackathon Proposal:Canvas Widgets]].

For a (somewhat outdated) overview of PUI widgets used by FlightGear, see {{Readme file|gui}}.
To learn more about undocumented widgets, see: [[Template:PUI widget]]

For an authoritative list of PUI based widgets used by FlightGear, please refer to {{Flightgear source|src/GUI/FGPUIDialog.cxx|line=882}}.

== Status ==
{{See also|PUI#Status}}
'''Last updated: 01/2023
'''
* Implementation of missing widgets to emulate [[PUI]] {{Progressbar|70}} (7/20 missing)
* add the menubar to the widget factory dialog {{Done}}
* Once the menubar widget is working properly and once we can parse/translate menubar.xml, we should consider using a separate dialog to show the fully translated menubar {{Not done}}
* Introduce a dialog to preview dialogs generated by XMLDialog.nas, so that more contributors can get involved in previewing/testing existing dialogs (including those outside fgdata) {{Not done}}
* C++ additions:
** expose [[SG_LOG]] stream for the loglist widget {{Not done}}
** expose translations for the menubar {{not done}}
** before porting the [[Map dialog|mapWidget]] (and before phasing it out), we need to revisit a long standing issue, i.e. not having back-ported the projection handling fix to the Canvas system: {{Issue|550}} and {{Issue|454}} (for details see [[Canvas_development#Projections]] and [[Howto:Adding new projections to Canvas Map]]) <ref>https://forum.flightgear.org/search.php?st=0&sk=t&sd=d&sr=posts&keywords=canvas+projection+map</ref>
** when opening 3+ concurrent instances of the new propertyTree dialog, fgfs will be massively slowed down, and that seems due to how labels are dynamically updated in Nasal space - we should probably extend label properties to optionally be based on on an sprintf-style string, and a list of properties to be read, and handle updates directly in C++ space rather than in Nasal space. Also, it might make sense to only update visible items? (for now, it's a really good stress test!)
** there seems to be a rather serious memory leak when using the Canvas GUI subsystem: the number of refs/objs and the size of Nasal memory pools never reduces upon closing said dialogs/windows (unlike PUI!), this applies to any Canvas GUI dialog/window, including tooltips
* Introduce meta information at the PropertyList/XML level to be able to version dialogs, for future changes to the underlying format
* Clean up the existing UI:
** especially the introduction of submenu support will make it possible to declutter the menubar (debug menu etc) {{Not done}}
** furthermore, introducing proper {{tag|tab}} support will make it possible to simplify a few existing dialogs {{Not done}}
* Optimizing and simplifying existing dialogs by introducing new layouting/widget primitives {{Not done}}

== Widgets ==

The majority of missing widgets can be implemented/approximated by using existing ones or adapting/extending those as needed. To get started with widget development, it's a good idea to look at some of the really simple ones first, and then take it from there - for instance, the Label widget is a comparatively simple widget:

{| class="wikitable"
! Status !!PUI widget {{Flightgear source|src/GUI/FGPUIDialog.cxx|line=882}} !! Complexity (0-10) !! Priority !! Canvas widget !! Remarks
|-
| {{Done}} || {{tag|frame}} || 1 || not critical || {{Canvas Widget|widget=Frame}} || see {{Fgdata commit|459dea77e5ceac592d0d5d58a059ccad1fce6daa}}
|-
| {{Done}} || {{tag|hrule}}/{{tag|vrule}}|| 1 || not critical || {{Canvas Widget|widget=Rule}} || {{Fgdata commit|459dea77e5ceac592d0d5d58a059ccad1fce6daa}}
|-
| {{Done}} || {{tag|list}} || 5|| high || {{Canvas Widget|widget=List}} || list, combo and select should probably be tackled together, there's plenty of common/similar functionality - these could all be based on the same superclass internally, which should probably be structured so that specific list types (airport list, property list, waypoint list, log list) can be implemented on top of the existing list widget.
|-
| {{Not done}} || {{tag|airport-list}} || 5|| || {{N/a|Not implemented}} ||trivial using navdb APIs and ScrollArea with buttons/labels for each entry and a corresponding event handler [[Howto:Processing_legacy_PUI_dialogs_using_Canvas#Use_Case:_airports.xml]]
|-
| {{Done}} || {{tag|property-list}} || 5|| || {{N/a|Not implemented}} || [[Property Browser]], [[Howto:Processing_legacy_PUI_dialogs_using_Canvas#Coming_up_with_a_property-list|rough prototype]] exists already, basically mapping 3 props.nas APIs to a ScrollArea with buttons for each property/node, allowing the tree to be travsersed interactively. Could be also implemented by using text labels and ASCII art, analogous to [[Nasal_Browser]] or using the new ListView widget
|-
| {{Not done}} || {{tag|waypointlist}} || 6|| || {{N/a|Not implemented}} || trivial using navdb APIs and ScrollArea with buttons
|-
| {{Not done}} || {{tag|loglist}} || 4|| || {{N/a|Not implemented}} || needs [[SG_LOG]] logstream exposed via [[Nasal/CppBind]]
|-
| {{Done}} || {{tag|input}} || 3 || || {{fgdata file|Nasal/canvas/gui/widgets/LineEdit.nas|t=LineEdit}} ||
|-
| {{Done}} || {{tag|text}} || 6|| || {{fgdata file|Nasal/canvas/gui/widgets/Label.nas|t=Label}} ||
|-
| {{Done}} || {{tag|checkbox}} || 4|| || {{fgdata file|Nasal/canvas/gui/widgets/Checkbox.nas|t=Checkbox}} ||
|-
| {{Done}} || {{tag|radio}} || 2|| || {{Canvas Widget|widget=RadioButton}} ||
|-
| {{Done}} || {{tag|button}} || 2|| || {{fgdata file|Nasal/canvas/gui/widgets/Button.nas|t=Button}} ||
|-
| {{Not done}} || {{tag|canvas}} || 4|| || should be implemented prior to {{tag|map}} || While we don't necessarily need a proper canvas widget, we need to map the PUI widget to a corresponding equivalent, i.e. an embedded Canvas with its own scripting block to animate the whole thing. The original pui2canvas parser simply set up an embedded Canvas via a Label with the raster image set up to show the Canvas instead: [[Howto:Processing_legacy_PUI_dialogs_using_Canvas#Embedded_Canvas]]
|-
| {{Not done}} || {{tag|map}} || 5|| || should honor the original property interface, and be based on the {{tag|canvas}} widget {{N/a|Not implemented, see also [[Canvas MapStructure]]}} || {{Progressbar|20}} [[Howto:Creating_a_Canvas_GUI_Widget#Implementing_a_Map_widget]]
|-
| {{Done}} || {{tag|combo}} || 6|| || {{N/a|Not implemented}} || list, combo and select can be unified
|-
| {{Not done}} || {{tag|select}} || 7|| {{N/a|Not implemented}} ||list, combo and select can be unified
|-
| {{Done}} || {{tag|slider}} || 4|| || {{fgdata file|Nasal/canvas/gui/widgets/Slider.nas|t=Slider}} ||
|-
| {{Done}} || {{tag|dial}} || 3|| || {{fgdata file|Nasal/canvas/gui/widgets/Dial.nas|t=Dial}} ||
|-
| {{Done}} || {{tag|textbox}} || 6|| || {{fgdata file|Nasal/canvas/gui/widgets/LineEdit.nas|t=LineEdit}} and/or {{fgdata file|Nasal/canvas/gui/widgets/Label.nas|t=Label}} ||
|}

== Menubar ==

Furthermore, we need to replace the [[Menubar]] itself, which is also implemented via PUI - for that purpose, there are some special widgets needed:
{| class="wikitable"
! Status || Complexity (0-10) !! Priority !! Canvas widget !! Remarks
|-
| {{Done}} || 3 || 10 || {{Canvas Widget|widget=MenuBar}} || see {{Fgdata commit|459dea77e5ceac592d0d5d58a059ccad1fce6daa}}
|-
| {{Done}} || 3 || 10 || {{Canvas Widget|widget=PopupMenu}} || see {{Merge-request|project=fgdata|id=305|text=Merge request:Implement canvas menus}}
see {{Fgdata commit|459dea77e5ceac592d0d5d58a059ccad1fce6daa}} <ref>https://sourceforge.net/p/flightgear/mailman/message/37756296/</ref><ref>https://sourceforge.net/p/flightgear/mailman/message/37756390/</ref><ref>https://sourceforge.net/p/flightgear/mailman/message/37756347/</ref>

|-
| {{Done}}|| 3 || 10 || {{Canvas Widget|widget=MenuItem}} || the design goal of MenuItem is to allow both simple items (text) but also check-ables ones, and in the future, simple widgets to be inside an item (eg, a slider or +/- controls in a menu item, or a multi-state selector of a few choices)

So, the aim was to have a constructor taking either a text string, or a callback which creates the widget content on demand (when the menu is shown)
<ref>https://sourceforge.net/p/flightgear/mailman/message/37756408/</ref> It's using an
item-orientated approach, and the menu has an addItem method to add an
arbitrary widget (in most cases this will be a MenuItem instance, but you
could use a slider just as well) and a createItem method that takes a text
and a callback and an optional icon, from which a new MenuItem is created.<ref>https://sourceforge.net/p/flightgear/mailman/message/37756436/</ref>
|-
| {{Done}}|| || 10 || {{Canvas Widget|widget=Menu}} || see {{Fgdata commit|459dea77e5ceac592d0d5d58a059ccad1fce6daa}}
|-
|}

In addition, there are some Canvas specific widgets that are not currently supported by PUI:

{| class="wikitable"
! Complexity (0-10) !! Priority !! Canvas widget !! Remarks
|-
| 6 || || {{fgdata file|Nasal/canvas/gui/widgets/ScrollArea.nas|t=ScrollArea}} || serves as the generic building block for any PUI list-type (waypoints/airports) with labels/buttons added for each entry shown
|-
| 4|| || {{fgdata file|Nasal/canvas/gui/widgets/TabWidget.nas|t=TabWidget}} || A [https://sourceforge.net/p/flightgear/mailman/message/37754597/ tab widget] as everyone knows it from their web browsr (pending review as of 12/2022 see {{Merge-request|project=fgdata|id=303|text=Merge request:Canvas tab widget implementation}})
|}

== General Improvements ==
With the new GUI system (!!) we could even do a mode which opens the property inspector at a particular branch of the property tree, and have a an option that reads "manually select loading settings [click here to edit values]"
… to keep the power tweakers happy without having a custom dialog box for every set of properties. (We do need to ensure they get auto-saved though, for this UI flow to be non-annoying) <ref>https://sourceforge.net/p/flightgear/mailman/message/37771124/</ref>

And that is something that we talked about and actually previously experimented with with Florent when the Addon system was being developed: There are some things in fgfs that don't really have a proper "config dialog" (yet) - but the property tree holds almost sufficient information to procedurally create a corresponding UI merely by doing a <code>foreach(var node; tree)</code> and by traversing a node to procedurally build a simple UI.

Having some sort of "overlay mode" for property-based dialogs would seem like a straightforward thing to do - we can easily support 3-5 optional attributes per node, and even recognize those dynamically inside the property browser, to provide this sort of "view" - and we could even register such nodes via a dedicated "hash" to make these available in a more direct fashion via the menubar.

The idea we had back then was to use optional XML/node attributes to add meta-info to such nodes, that way a "label" or "tooltip" attribute could be added, and even a "ui-type" node, so that such a loop could serve as a simple dialog builder for such annotated property nodes:

https://wiki.flightgear.org/Draw_masks
[[File:Draw-masks-via-canvas.png|thumb|FlightGear [[Draw masks]] GUI dialog procedurally created by the [[Canvas]] system.s]]

I guess you can see just how simple but powerful this idea is: as long as we add such meta information to certain properties, a simple loop could procedurally generate simple dialogs, without having to use separate files.

To prototype/test this sort of idea, we could use your tab widget inside the new property tree widget, and support a different sort of "view" for such nodes - basically like an "overlay", where such properties are dynamically interpreted to provide a simple UI without having to view/edit raw property values.

We could then annotate relevant property trees using optional attributes like:
* ui:label
* ui:tooltip
* ui:help (help string, could be shown via '?' button rendered next to each of these widgets)
* ui:type [toggle, checkbox, slider etc]
* ui:index (to influence in what order/manner such properties are mapped to widgets)
* ui:validate (to select applicable validation)

This sort of markup would make it very easy for fgdata/aircraft developers to create UIs without ever having to create a single dialog, just by providing sufficient meta information so that the Canvas GUI system could automatically create basic, but working, dialogs.

Imagine, a property tree node having optional attributes, e.g. along the lines of:
<syntaxhighlight language="xml">


<hostname type="string" ui:type="textbox" ui:label="Host name" ui:tooltip="enter a hostname" ui:validate:""/>
</syntaxhighlight>

We could then use a wrapper Class to map <code>props.Node</code> hierarchies to such dialogs using the equivalent of an <code>PropsOverlayBuilder</code> helper - the idea being to provide a UI overlay for nodes with rich meta info.

This sort of approach would also allow us to easily configure whether we want these settings to be stored with the userarchive flag set or not, or to save/load custom defaults via $FG_HOME/Export

== Styling ==
Fahim was also working on an alternate style since James wants to ensure we have correct model-view separation between the core widgets (which is the public API) and the style code that builds the visual appearance.

In general, help with making the styling parts is the piece I am slowest with though, so any help, especially creating border-images (scale9) that work as the backgrounds / frames for the various elements would be lovely.<ref>https://sourceforge.net/p/flightgear/mailman/message/37718562/</ref>

<ref>https://sourceforge.net/p/flightgear/mailman/message/37756178/</ref>

We need to figure out the split of DefaultStyle.nas, but James is very keen to ensure we add a second style alongside the default, before we change much here.

Regarding styling, James is worried about us ending up putting code into the wrong side of the widget / Style split, if we don’t have a second alternative style implementation to ‘keep us honest’<ref>https://sourceforge.net/p/flightgear/mailman/message/37756178/</ref>

We really have two kinds of ’styles’

* tweaking margins, font sizes, colours etc should indeed be done in XML as you wrote : this is also analogous to styles in the PUI sense

* making radically different ways of presenting the same logical widgets: eg text label of checkbox in a different position relative to the button (of Surface vs Material vs iOS style, if you know web/mobile UIs)

For the second kind we would use a different Nasal style implementation and that’s the abstraction James thinks it is very important to maintain.

It of course going to be a lot of work to make additional styles this way but it’s a very valuable feature to keep the possiblity, since it enables alternate UIs for user accessibility or different presentation modes such as VR.

What James doesn't want to do is add lots of widgets assuming we only care about DefaultStyle.nas, and then have an impossible mountain to climb when someone needs an alternate Nasal style. We don’t have to make a complete alternate style now, but I don’t want to take shortcuts the make it impossible in the future. So James wants to really think carefully about what is widget code and what is style code. <ref>https://sourceforge.net/p/flightgear/mailman/message/37756261/</ref>

Also, it is worth nothing that treating DefaultStyle.nas that way, is a straightforward mechanism to allow aircraft developers to customize their own styling for all sort of MFD purposes, without having to create complete widget sets from scratch - this is how Tom originally designed the whole thing, for his C130J.

== Widget Validation ==
At some point in the future, we may want to introduce support for optional constraints/restrictions for certain types of widgets (think headings/bearings/courses, frequencies, latitude/longitude, date/time, navaids, airports, file path, property path, metar string etc):

Things like password entry mode, restrictions on permitted characters (eg onl allowing numbers or an IP address), max number of characters entered, etc would all be config options as we add those kind of things gradually. That’s why I like it as an API: it avoids an explosion of setters for rarely used things, and it can be passed into the Style implementation ‘as is’ without each possible option needing to be explicitly handed over.<ref>https://sourceforge.net/p/flightgear/mailman/message/37765245/</ref>

== Cleaning up dialogs ==

Once the PUI/XML widget set is fully supported by the XMLDialog parser, it will make sense to review existing dialogs to identify opportunities to introduce new widgets and simplify existing dialogs.
As a matter of fact, a number of PUI/XML dialogs are currently working around PUI limitations by using awkward hacks to implement custom widgets. These show up by making excessive use of Nasal blobs as well as usage of the cmdarg() API, and they're a pain to maintain:

{{collapsible script
| title = PUI/XML dialogs making excessive use of embedded Nasal
| script =
* $FG_ROOT/gui/dialogs/airports.xml Total Nasal LOC: 415
* $FG_ROOT/gui/dialogs/advanced-graphics-options.xml Total Nasal LOC: 413
* $FG_ROOT/gui/dialogs/checklist.xml Total Nasal LOC: 399
* $FG_ROOT/gui/dialogs/weather.xml Total Nasal LOC: 298
* $FG_ROOT/gui/dialogs/chat-menu.xml Total Nasal LOC: 297
* $FG_ROOT/gui/dialogs/static-lod.xml Total Nasal LOC: 270
* $FG_ROOT/gui/dialogs/route-manager.xml Total Nasal LOC: 263
* $FG_ROOT/gui/dialogs/map-canvas.xml Total Nasal LOC: 188
* $FG_ROOT/gui/dialogs/file-select.xml Total Nasal LOC: 161
* $FG_ROOT/gui/dialogs/joystick-config.xml Total Nasal LOC: 159
* $FG_ROOT/gui/dialogs/location-in-air.xml Total Nasal LOC: 153
* $FG_ROOT/gui/dialogs/gps.xml Total Nasal LOC: 138
* $FG_ROOT/gui/dialogs/nasal-console.xml Total Nasal LOC: 132
* $FG_ROOT/gui/dialogs/button-config.xml Total Nasal LOC: 124
* $FG_ROOT/gui/dialogs/property-browser.xml Total Nasal LOC: 121
* $FG_ROOT/gui/dialogs/replay.xml Total Nasal LOC: 115
* $FG_ROOT/gui/dialogs/marker-adjust.xml Total Nasal LOC: 105
* $FG_ROOT/gui/dialogs/jetways-adjust.xml Total Nasal LOC: 103
* $FG_ROOT/gui/dialogs/multiplayer.xml Total Nasal LOC: 98
* $FG_ROOT/gui/dialogs/autopilot.xml Total Nasal LOC: 97
* $FG_ROOT/gui/dialogs/flight-recorder-load.xml Total Nasal LOC: 89
* $FG_ROOT/gui/dialogs/fgcom.xml Total Nasal LOC: 85
}}

== Introducing new Widgets ==
There is great scope to make /better/ Nasal APIs for items such as combo-boxes and pickers, especially ICAO and radio frequency pickers, but that's all 'improving the GUI' work than can happen once we've ditched PLIB and have something hackable.<ref>https://sourceforge.net/p/flightgear/mailman/message/29583931/</ref>

It's been repeatedly pointed out by a number of contributors, that the sheer amount of Nasal blobs embedded in PUI/XML dialogs is making UI development quite a hassle (especially those outside bindings, i.e. inside open/close blocks and the canvas load equivalent). Thus, it will make sense to review which new widgets could be introduced to get rid of these Nasal blobs:

{| class="wikitable"
! Status || Complexity (0-10) !! Priority !! Canvas widget !! Remarks
|-
| {{Not done}} || 4|| low || AirportView || this would help simplify airports.xml
|-
| {{Not done}} || 4|| low || ChecklistWidget || this would help simplify checklists.xml
|-
| {{Not done}} || 4|| low || PilotList || pilot list dialog
|-
| {{Not done}} || 4|| low || SubsystemList || performance monitor
|}

== Meta info for dialogs ==

These changes will also simplify development of the Phi/mongoose based UI, because we would be introducting dedicated widgets, which could just as well be implemented in JavaScript. However, for these changes to be introduced, we need to make some additions to the PropertyList/XML format used by GUI/XML files, namely:

* introducing a version attribute for the {{tag|PropertyList}} root
* introducing a {{tag|FileType}} node to specify that the file is a GUI/XML description: <code><FileType>GUI</FileType></code>
* introducing a {{tag|version}} node to be able to make breaking changes in the future

This way, we can easily update widgets/layouting primitives or introduce new ones, without having to be concerned about existing UI resources.

For instance, here's $FG_ROOT/gui/dialogs/scenery_loaded.xml with additional meta information, so that we can safely make changes in the future:
<syntaxhighlight lang="xml">
<?xml version="1.0"?>
<PropertyList version="1.0">
<FileType>GUIResource</FileType>
<version>1.0</version>
<name>scenery_loading</name>
<layout>vbox</layout>
<modal>true</modal>
<text>
<label>Scenery Loading...</label>
<padding>30</padding>
</text>
</PropertyList>

</syntaxhighlight>

== Reusability ==
Once our existing PUI widgets and dialogs are fully emulated, and dialogs have become better optimized (=less Nasal blobs). It will be a good idea to revisit some concerns and ideas expressed by Torsten D. based on his experience creating Phi:

Torsten once stated rightly that it would be benefical for any new UI to separate the logic included in most dialogs from the presentation anyway to make it reusable.
His vision was to have some kind of service implemented in FlightGear that wraps all complex tasks into service calls and responses. The command system is a
good start to trigger something, but it does not yet return anything.

Currently, all dialogs are a mixture of calling fg-commands and setting properties directly.

Phi already has some basic support for aircraft specific elements. <ref>https://sourceforge.net/p/flightgear/mailman/message/34532860/</ref>

We should discuss and prototype a new type of asynchronous fgcommand layer that may also return properties/values, this could benefit both: The Canvas UI, but also Phi. In the future, Canvas UI dialogs may thus also use these same fgcommands which would be running asynchronously (possibly over the same/existing non-blocking HTTP back-end already used by Phi).

At that point it will become increasingly feasible to also provide a module for Phi to interpret these new PUI/XML dialogs, because these would be primarily XML-based, should contain zero (or very little) code. And the new could be that Nasal code that still needs to stay inside such dialogs, will always need to be registered with the SGCommandMgr via the addCommand() API - that way, both front-ends would be able to interpret/execute such dialogs, which would mean that aircraft developers would not need to port/maintain two different sets of dialogs to support both front-ends.

Also, future updates to the UI will become tremendously easier once our dialogs are purely declarative/XML.

{{Appendix}}

PUI

2023-04-19T11:32:12Z

Hooray: /* Canvas Emulation */

{{Feature to be removed|version=2023.3|reason=[[Plib]]/PUI is to be removed and replaced by a [[Canvas widget matrix|Canvas/Nasal based solution]] to help improve compatibility with [[OSG]] 3.6+ and [[OpenGL]] 4.x ([[Core Profile support|OpenGL Core Profile]], see [[2022.X Release plan]] ) and improve performance by [[Unifying the 2D rendering backend via canvas|phasing out legacy OpenGL code]]. Therefore, people should be careful when extending the '''PUI''' based legacy GUI engine<ref>https://sourceforge.net/p/flightgear/mailman/message/34921495/</ref><ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35157325/
|title = <nowiki> Re: [Flightgear-devel] GUI options (Was: Aircraft center) </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jun 14th, 2016
|added = Jun 14th, 2016
|script_version = 0.40
}}</ref> and coordinate any related work with the devel mailing list first-this applies particularly to adding any [[Template:PUI_widget|additional hard-coded PUI widgets]]. }}
[[File:Exit.png|thumb|FlightGear GUI dialog (exit.xml)stored in $FG_ROOT/gui/dialogs]]
{{GUI Navbar}}

[[File:Custom-autopilot-dialog.png|right|200px]]
[[PUI]] is the standard GUI engine used in FlightGear, it is part of [[PLIB]] and is using raw, fixed-pipeline, [[OpenGL]] code internally (no [[OpenSceneGraph]]). As of mid 2021, FlightGear is in the process of working towards adopting the OpenGL Core Profile, this means that [[PUI]] is causing trouble and needs to be replaced/disabled or ported.

PUI provides a fairly basic, but robust, set of widgets. PUI is also used for rendering the [[Menubar]].

FlightGear uses a GUI widget set that is implemented on top of raw (legacy) [[OpenGL]]. This has many advantages from a portability standpoint and from the standpoint of integrating with window systems. [[PUI]] doesn't have every feature under the sun, but it was never meant to. It's relatively small, lean, mean, and written on top of [[OpenGL]] which makes life *much* easier for us.

[[PUI]] already is a separate distinct library within Plib. It depends on some central utility stuff, but that's about it. So it is pretty stripped down and separate already.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg26011.html</ref>

We are to some extent hamstrung by the rather old GUI toolkit we use. However, replacing that is going to be non-trivial, and it would affect not just the core GUI but also all the dialog boxes that have been set up for particular aircraft.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg25985.html</ref>

Flightgear can look amazing when you use the HDR pipeline. We absolutely need this to stay relevant. The problem is that HDR is not compatible with OpenGL1 PUI. Work on getting rid of PUI has been going on for over a decade (longer than it took to implement it).<ref>https://sourceforge.net/p/flightgear/mailman/message/37727346/</ref>

[[File:menubar2.jpg|517px]]

== Replacement status ==
{{See also|FlightGear_and_OpenGL_ES#Example:_disabling_PUI}}

{{Note| Update 09/2022: The PUI replacement [[QtQuick_use_in_FlightGear#Background|was going to be Qt]] but it started to get very complicated with changes in Qt 5.15 + Qt 6, so James is going with a more light-weight Canvas based approach now.

Qt added support for Vulkan / Metal / D3D starting in 5.15, but FlightGear / OpenSceneGraph can’t support those, so integrating the two renderers went from being ‘complicated but ok’ to ‘very very complicated’.

So now James is going with something much more lightweight using some C++ compatibility code, some Nasal for styling and the existing [[Canvas widgets|Canvas widget rendering]] from Thomas Geymayer (TheTom) with some extensions and additions, based on the [[Howto:Processing_legacy_PUI_dialogs_using_Canvas#Original_Discussion|plans originally discussed when the Canvas GUI system was added to FlightGear]]: some pieces are in FlightGear & FGData already.

James has basic dialogs working okay but not the more complex ones and everything looks kind of ugly, he needs to improve the visual look before he shares screenshots to avoid everyone freaking out :) The disadvantage of this approach is James is far from expert at creating visual appearances this way, so it’s kind on unrewarding and slow for him. If someone likes messing with CSS-type styling, border-images and hover-states, ping him since we could probably move things also faster <ref>https://sourceforge.net/p/flightgear/mailman/message/37701750/</ref>}}

=== Motivation ===
{{Main article|Core Profile support}}

The bigger issue here is we need to ditch [[PUI]] (which is in progress) and some OpenGL 1.0 code (HUD, 2D panels especially - can be #ifdef for now) so we can enable Core profile on Mac - since Mac 4.x support (we only hit about 4.3 alas, but with some extensions to get in sight of 4.5) is Core profile only, no Compatability mode.

Improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, many people are convinced PUI needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

While most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so [using Qt5] would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

== Canvas Emulation ==
{{See also|Canvas widget matrix}}
'''Last updated: 04/2023 <ref>https://sourceforge.net/p/flightgear/mailman/message/37805054/</ref>
'''
=== Status ===
As of 01/2023, the replacement for PUI is making good progress<ref>https://sourceforge.net/p/flightgear/mailman/message/37765706/</ref>.

In February 2022, James reported having something in progress locally, and that should even be something we can try in March/April 2022. Hopefully that’s quick enough, knowing it has been a long time coming.<ref>https://sourceforge.net/p/flightgear/mailman/message/37606439/</ref>

There's now an XML to Nasal bridge, to keep PUI dialogs working (Disabled by a CMake option)
This is implemented on top of the [[Canvas]] system.

This builds equivalent C++ objects to what the [[PUI]] dialogs build, with properties exposed to Nasal.
Peer objects are created by Nasal [[callbacks]], which can implement the various dialog functions needed to keep compatibility, especially the [[#Background|‘update’ and ‘apply’ hooks]].<ref>https://sourceforge.net/p/flightgear/flightgear/ci/cbd5ef9e7b8f433dbc1ba97bae7d7cfc894e7cef/</ref>

Use the following [[Building using CMake|cmake option]] to enable this code: <code>-DENABLE_PUICOMPAT=ON</code>

The new Compatibility files can now be found in $FG_SRC/GUI:

* {{flightgear file|src/GUI/FGPUICompatDialog.cxx }}
* {{flightgear file|src/GUI/FGPUICompatDialog.hxx }}
* {{flightgear file|src/GUI/PUICompatObject.cxx }}

01/2023: James is slowly working on creating the pop-up menu and combo-box widgets [...]

One of the major things slowing down James' work on the popup-menu and combo box is time to restart the simulator for each change, he is looking for some solution to re-load the widget Nasal code independently. <ref><https://sourceforge.net/p/flightgear/mailman/message/37756183/</ref>

=== Todo ===
Nothing in particular : help debugging the grid layout (which is in simgear) would be good. For now you could create a grid layout manually using some Nasal.

For the menubar, we need to expose the C++ data to Nasal : we need a FGCompatMenuBar (alongisde FGPUIMenuBar) implementing FGMenubar which calls _createMenuObject in MenuBar.nas, using the same way I lookup and call _createDialogPeer in XMLDialog.nas

(Make sure you don’t break the macOS native menubar in the process!)

You can probably pass a wrapped SGpropertyNode into this, and then fill in the stubs in that file to use the Menu widgets Frederic has written.

Global menu keybindings won’t worry but don’t touch that, I have a separate plan for it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37805736/</ref>

James has done about 75% (hah!) of the C++ work to enable live reloading of modules this way, but unfortunately there are some code paths that would become crashy if you use the feature for the Canvas: because it would reference the ‘old’ (pre-reload) Nasal code, and not the new one, and therefore you’d get a weird mix of old and new, and then just crash the sim. To fix it properly I need to track down those places that store a reference to Canvas and give them a re-init method, so we don’t keep the stale references.

The general non-fun-ness of that kind of debugging is James has been making such slow progress on my PUI replacement widgets recently <ref>https://sourceforge.net/p/flightgear/mailman/message/37756263/</ref>

As of 04/2023, remaining items on the todo list are: <ref>https://sourceforge.net/p/flightgear/mailman/message/37805060/</ref>

* Grid layout
** GridLayout needs debugged: After this, the basic UI is usable, would probably make it a switchable option on ‘next’ (I can already use the simulator with the new UI today, but all the sizes are off in the grid layouts which we use everywhere)

* list
* table (and tree ?) models corresponding views
* waypoint list
* Re-write the waypoint list and airport dialog to work again (since these use custom widgets):
** log list
** airport-list equivalents
* Nasal access to the menu i18n functions
* selection support for single- and multi-line text (which is being worked on -> CanvasPangoText)
* Keyboard shortcut handling, although this is not really a PUI vs replacement issue, to me we should handle UI shortcuts in the same was normal keyboard.xml shortcuts
** this previously worked because PUI got ‘first chance’ at handling key input. But we always had duplication between keyboard.xml and other places, so I would rather standardise on keyboard.xml, but allow a UI element to set a scope for shortcuts. (So that Copy/paste shortcuts etc can work in a text input, at least … but probably some other standard ones) <ref>https://sourceforge.net/p/flightgear/mailman/message/37805188/</ref>
* Ensure all the places which use the PUI combo-box and list-widget work : there’s a few of these.

The CanvasPangoText stuff is needed but we can perfectly well run the UI on next without it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37805176/</ref>

=== Parser ===
{{Main article|pui2canvas}}
The corresponding Nasal/Canvas module to dynamically "translate" legacy PUI/XML dialogs into Canvas dialogs (at runtime), is to be found in {{fgdata file|Nasal/gui/XMLDialog.nas}} <ref>https://sourceforge.net/p/flightgear/fgdata/ci/fe7c87b21a69f88ddb87d89453c48d12b69660e2/</ref>

=== Widgets ===
{{Main article|Howto:Creating a Canvas GUI Widget}}

It’s split between Simgear (see classes with widget / layout in the name) and in FGData. (Eg widgets/Button.nas) To be able to use the existing dialog XML files un-modified (which is a design goal), James is extending the widget types with many additional ones (eg PUI has slider, dial, combo-box, checkbox, all of which need to be created, see [[Canvas widget matrix]].

This is about 30% done and is the bit he's very slow at). Thomas’s canvas widgets have a very good separation of API + state from appearance, so all styling is in its own file, and James is being very strict about maintaining this separation, so we also retain the re-styling feature of the PUI UI, which many people also rely on. This does make the process of adding new widgets more complex, however.

{{See also|Canvas widgets}}

=== Layouting ===
The other thing is to preserve all the layouting: James has added a grid layout to Simgear, since that is supported by the existing PUI code (even though the layouts are not actually part of PUI itself). The problem is getting the sizing / hinting of all the widgets to match the PUI values, so that dialogs look approximately the same under the new UI as they did with PUI; again this a design goal so that all existing dialogs in aircraft and add-ons, which we can’t update, continue to work and be usable. Debugging that is also proving quite tricky, since there’s all kinds of hard-coded assumptions built into PUI widgets about pixels, font-sizes etc which are not true in the new system.<ref>https://sourceforge.net/p/flightgear/mailman/message/37701792/</ref>

== Background ==
In FlightGear, PUI dialogs are standard [[PropertyList XML File]]s that are stored in $FG_ROOT/gui/dialogs, they can contain the widgets mentioned in {{readme file|gui}}, using a simple layout engine discussed in {{readme file|layout}}, and bindings using a combination of so called fgcommands operating on properties (see {{readme file|commands}}) and custom [[Nasal]] (FlightGear scripting) code.

In addition, each PUI/XML dialog may contain Nasal script sections that are executed when opening/closing the dialog, a feature which is commonly used for procedurally creating/updating widgets using the [[Nasal_library#cmdarg.28.29|cmdarg() API]], which allows the dialog tree to be traversed and manipulated prior to the dialog being rendered.
Widgets can be conditionally hidden/shown using a wrapper for [[Conditions|SGCondition]] in [[Nasal_library/props|props.nas]]
The <code>canvas</code> widget also supports its own embedded Nasal code section to execute arbitrary widget specific Nasal code upon opening/closing the dialog/widget.

PUI/XML dialogs can be loaded, dynamically created, updated and closed using a handful of fgcommands:
* {{fgcommand|dialog-new}}
* {{fgcommand|dialog-show}}
* {{fgcommand|dialog-update}}
* {{fgcommand|dialog-apply}}
* {{fgcommand|dialog-close}}

PUI related OpenGL code is particularly infamous for causing rendering artifacts for people on AMD/ATI and Intel hardware (especially in combination with certain fonts/styles and [[Effects|effects]]/[[Shaders|shaders]]), see {{Issue|2213}}.

PUI is also known to affect rendering performance quite significantly (see {{search |keywords=anthrax+gui}}), while also preventing FlightGear from using a more recent version of OpenGL<ref>http://sourceforge.net/p/flightgear/mailman/message/34532040/</ref><ref>http://forum.flightgear.org/viewtopic.php?f=71&t=24046</ref>.

However, improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Besides, while most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

But given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, graphics folks are also convinced it needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

In addition, [[OpenSceneGraph]] (OSG) can obviously not help optimize any PUI related GL code and PUI widgets are generally considered to be pretty archaic and not easy to extend<ref>http://sourceforge.net/p/flightgear/mailman/message/26832164/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587120/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587272/</ref>.

{{Note|We use the GUI code from PLIB, which doesn't know anything about OSG. See the SGPuDrawable class in $FG_SRC/Viewer/renderer.cxx for the implementation. The one catch is that OSG has a strong notion of separation between the update of a "scene" and its rendering, and that might not play well with arbitrary existing OpenGL code. }}

As of late 2015, there is heavy activity towards providing alternatives to a PUI-based UI:
* [[Integrated Web GUI]] (external, browser-based - fully asynchronous)
* [[Howto:Processing legacy PUI dialogs using Canvas]] (internal, using the [[Canvas]] system and a simple [[Nasal]] parser to deal with existing PUI/XML dialogs)

<gallery mode="packed">
Early-Phi-screen shot.PNG|Screenshot showing [[Phi]]
About-dialog-rendered-by-canvas.png|Screenshot showing a dialog rendered by the [[Howto:Processing legacy PUI dialogs using Canvas|pui2canvas parser]]
</gallery>

== History ==
{{Caution|This is merely kept for future reference, many of the ideas discussed below have become obsolete as of 09/2022, if in doubt, please get in touch via devel-list.}}
=== 2021 ===
In early 2021, James did a brief evaluation of [https://github.com/ocornut/imgui ImGUI] as a possibility - he's also evaluating it in some projects at his day job.

The API is interesting if you’re starting from scratch and only exclusively in C++, but it’s not a great fit for how we define GUIs in FG (via [[XML]]/[[Nasal]]): there is no back door that he could find, to access the persistent state of the GUI, or build it up in a data-driven way. So making a mapping to keep our existing GUI XML working (and updating correctly) becomes a bit of a chore.<ref>https://sourceforge.net/p/flightgear/mailman/message/37295586/</ref>

Pretty much all of the FlightGear GUI is defined in XML space, except for a few oddments. Let’s say 95% at this point.

Additionally, even if we were to change that for the core sim (and James' current plan is to keep the XML syntax and just extend it), the installed base of '''aircraft''' ship their own XML dialogs (eg., replacing the autopilot dialog with a custom one, or just adding their own aircraft-specific helper controls for doors / lights / cargo / whatever). So even if we found the most sublimely beautiful, intuitive, compact GUI description language in the world, we have to keep the XML syntax working as-is, for the foreseeable future.

Given this, James' intention is to replace the output side [[PUI]] but keep the front-end side (XML / properties / bindings) unchanged, and therefore backwards compatible, and simply add some new types / options / widget types going forward. This will mean we still have to deal with the slightly cumbersome XML+Nasal syntax, but, well, it’s not *that* cumbersome. <ref>https://sourceforge.net/p/flightgear/mailman/message/37296280/</ref>

In mid 2021, James reported that he is working on some ‘PUICompat’ classes which hold/own/represent the GUI state in C++, but which can be used with [[Nasal/CppBind|Nasal CppBind]]. And of course we could indeed expose those later on. <ref>https://sourceforge.net/p/flightgear/mailman/message/37297727/</ref>

In July 2021, James suggested not to worry about the existing GUI code, it’s going in the bin.<ref>https://sourceforge.net/p/flightgear/mailman/message/37325905/</ref>

For the time being, the in-sim GUi can’t do Unicode yet, but James is working on it, hopefully available soon.<ref>https://sourceforge.net/p/flightgear/mailman/message/37328200/</ref>
Also, the in-sim menubar will change with the new GUI, *and* we use a native menubar on macOS. Until James replaces the PUI fonts we can’t use Unicode symbols. So, will have to come back to it once the new GUI is merged.<ref>https://sourceforge.net/p/flightgear/mailman/message/37327237/</ref>

=== 2020 ===
As of 03/2020, the PLIB replacement was reported to be in the backlog <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36951255/
|title = <nowiki>Re: [Flightgear-devel] C++ and/or OSG question </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Mar 18th, 2020
|added = Mar 18th, 2020
|script_version = 0.50
}}</ref>.

With PLIB replacement work likely being re-scheduled for [[Post FlightGear 2020.2 LTS changes]] <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36985375/
|title = <nowiki>Re: [Flightgear-devel] Working Group Proposal - Boost and PLIB replacement - Delegation and Teamwork </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = April 18th, 2020
|added = April 18th, 2020
|script_version = 1.10
}}</ref>.

In 08/2020, James stated that he was still working (exceptionally slowly!) on replacing PUI (as part of removing legacy OpenGL code (PUI, HUD, 2d panels, porting Canvas away form ShivaVG), so we can switch to Vulkan/VSG at some point (ideally at some point before Apple turn off OpenGL support…)), and that he doesn't think /any/ of us *want* to be working on these features particularly, but projects like these need to be done before anyone can have fun with VSG or Vulkan (personally James would be very enthusiastic about working on VSG support (being on macOS, I also have the most to lose / gain from it)). Sometimes that’s just how it goes. Equally they will all benefit the project ultimately, but the payoff both for the individual and the project is very drawn out. <ref>https://sourceforge.net/p/flightgear/mailman/message/37077158/</ref>

In 10/2020, the estimation is that PUI should be going away really ‘soon’, the replacement code is already in next / 2020.2. (There’s no plan to actually /use/ the new UI code in 2020.2, but if the bugs in it prove simple, we could actually turn it for specific dialog: it seems very unlikely this makes sense for a stable release however)<ref>https://sourceforge.net/p/flightgear/mailman/message/37123818/</ref>

The fixed-function removal, is actively in hand (Gaetan is working on the 2D panel part, and James is going to focus on PUI in the rest of 2020). James hopes that means next year he can focus on Vulkan, or at least, using OSG as if /were/ VSG, so the migration in a year or two when VSG is stable, is not so painful.<ref>https://sourceforge.net/p/flightgear/mailman/message/37129098/</ref>

The PUI UI and replacement can co-exist in the same build (they already do, effectively.<ref>https://sourceforge.net/p/flightgear/mailman/message/37131297/</ref>

In 11/2020, James suggested not to worry about details such as PUI styling/theming etc: we’re not making such changes for the LTS, and PUI should be gone before the next release.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142225/</ref> Also, he recommended (to everyone) to stop touching GUI stuff for a few weeks, as he's about to turn it all on its head.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142356/</ref>

=== 2019 ===
The new GUI has been incubating for a few years, but there's apparently been a lot of progress as of 10/2019.

It is likely the new GUI will be a user opt-in feature - at least initially. The sunset of the PLIB library _could_ happen relatively soon, but
people will need to see the new GUI and react to it before we could commit to PLIB removal <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36784489/
|title = <nowiki>Re: [Flightgear-devel] in Flightgear/Simgear C++ Code: What needs Doing? What are YOU Doing? What would you do if you had the time? </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Oct 14th, 2019
|added = Oct 14th, 2019
|script_version = 0.50
}}</ref>.

In 02/2019, James stated that the new UI is coming quite soon. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36589420/
|title = <nowiki> Re: [Flightgear-devel] Lagging </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Feb 17th, 2019
|added = Feb 17th, 2019
|script_version = 0.40
}}</ref>

=== 2018 ===
{{See also|QtQuick use in FlightGear}}

According to James, we have to accept that changes like testing or making [[PUI]] a modular thing or moving the JS code tend to have an immediate pain for some people (because strange stuff gets broken, and takes some time to get fixed), whereas the payoff in terms of improved joystick handling or replacing the UI or testing of all subsystems will take some months or years to be felt.<ref>https://sourceforge.net/p/flightgear/mailman/message/36323240/</ref>

James said he was in the middle of porting the launcher’s final tab (location) to the new UI scheme, once that’s done he will start sketching out the ‘in sim’ settings UI using the same pieces. He’ll send a request for contributions around about that in the next three-four weeks, once he has enough templates & examples that there is a clear pattern to follow.<ref>https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/2d10f16c-ddc8-07f3-07e7-eca2a0a0d55f%40zaretto.com/#msg36293586</ref>

James announced that the launcher is now feature complete with the QtQuick UI, he’ll keep making bug-fixes of course as people report them, but my todo list for the core features is now done<ref>https://sourceforge.net/p/flightgear/mailman/message/36355833/</ref>.

=== 2017 ===

In 10/2017, James said he was getting really close to having the PUI replacement UI suitable for beta-testing.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36067646/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 7th, 2017
|added = Oct 7th, 2017
|script_version = 0.40
}}</ref>

Originally, James was hoping to land the PUI replacement GUI in the last dev cycle in 2017 (at least as a proof-of-concept, probably not as the default UI), so wouldn’t expend lots of effort on things like collapsible sections which might be a lot of work with the current PUI/Canvas approaches, but are trivial with the new [[QtQuick use in FlightGear|QtQuick based UI scheme]].<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36059822/
|title = <nowiki> Re: [Flightgear-devel] Canvas MapLayer for OpenStreetMap, OpenAIP,
VFR Sectionals </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 1st, 2017
|added = Oct 1st, 2017
|script_version = 0.40
}}</ref>

Once the basic new UI is in place we can experiment with different re-arrangements easily, without being limited by PUI. (James expects PUI to live on as the default / alternate UI while this happens)<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36061229/
|title = <nowiki> Re: [Flightgear-devel] FGFS macOS Menubar </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 2nd, 2017
|added = Oct 2nd, 2017
|script_version = 0.40
}}</ref>

Technically, this entails replacing dialog.cxx with some code which builds up some special ‘PUI-Emulation’ QtQuick controls, so that existing dialogs (especially from Aircraft) continue to work. This mode will look somewhat ugly but hopefully no more ugly than PUI! And it helps that the set of widgets we have in PUI is limited, and the ‘tricky’ widgets (map, scrolling list, etc) are in the dialogs will will replace with new ones first.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068767/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

This PUI emulation isn't going to use any code from PLIB<ref>https://sourceforge.net/p/flightgear/mailman/message/36985303/</ref>, so what will remain from it in FG afterwards will be the FNT and JS components (reworked).<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068817/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> Florent Rougon </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

=== 2016 ===
We need to explore if Qt Quick or widgets is the better way to go, with a preference towards Qt Quick, since it will allow things closer to current PUI (semi-transparent widgets on top of the 3D content). It still allows creating separate windows too (Erik’s use case), but means we get consistent, custom theming on all platforms, since standard desktop look is not so nice for a flight-sim.

James intention is to make a QML-hosting OSG-drawable, and add this as a concept in Qt-enabled builds, then port some PUI dialogs to it, and see how easy / painful the process is. Hell create some QObjects which expose commands and the property tree and Nasal.

This has the advantage of not touching the OSG window at all, QtQuick simply provides some additional OpenGL rendering on top, which we pass events to - pretty much exactly the same as what we already do for PUI, and hopefully can co-exist with it. James got this working in a local OSG tree in a standalone demo, but that’s based on osgQt - he wants to see if he can make it work on a normal, non-Qt OSG window inside FlightGear.<ref>https://sourceforge.net/p/flightgear/mailman/message/35156051/</ref>

The idea is to host an XML dialog (Currently done with PUI) from Qt also. The question is if that can be done keeping ‘source compatibility’ exactly with the current UI XML and Nasal interface. It probably can be, but many of the PUI widgets have really ugly APIs, especially for combo-boxes, drop-down menus and scrolling lists, where it makes sense to map a Nasal class to a Qt ItemModel, which would be more elegant and easy to work with in both Nasal and integrate on the Qt side. But obviously would mean changing the dialog sources.

Of course, aircraft dialogs tend to be simpler, and not use the more complex PUI widgets, precisely for reasons like this, but that’s a limitation it would be best to remove.<ref>https://sourceforge.net/p/flightgear/mailman/message/35155721/</ref>


== References ==
{{Appendix}}

[[Category:PUI| ]]
[[Category:Rendering roadblocks]]

PUI

2023-04-19T11:31:20Z

Hooray: /* Status */ https://sourceforge.net/p/flightgear/mailman/message/37805736/

{{Feature to be removed|version=2023.3|reason=[[Plib]]/PUI is to be removed and replaced by a [[Canvas widget matrix|Canvas/Nasal based solution]] to help improve compatibility with [[OSG]] 3.6+ and [[OpenGL]] 4.x ([[Core Profile support|OpenGL Core Profile]], see [[2022.X Release plan]] ) and improve performance by [[Unifying the 2D rendering backend via canvas|phasing out legacy OpenGL code]]. Therefore, people should be careful when extending the '''PUI''' based legacy GUI engine<ref>https://sourceforge.net/p/flightgear/mailman/message/34921495/</ref><ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35157325/
|title = <nowiki> Re: [Flightgear-devel] GUI options (Was: Aircraft center) </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jun 14th, 2016
|added = Jun 14th, 2016
|script_version = 0.40
}}</ref> and coordinate any related work with the devel mailing list first-this applies particularly to adding any [[Template:PUI_widget|additional hard-coded PUI widgets]]. }}
[[File:Exit.png|thumb|FlightGear GUI dialog (exit.xml)stored in $FG_ROOT/gui/dialogs]]
{{GUI Navbar}}

[[File:Custom-autopilot-dialog.png|right|200px]]
[[PUI]] is the standard GUI engine used in FlightGear, it is part of [[PLIB]] and is using raw, fixed-pipeline, [[OpenGL]] code internally (no [[OpenSceneGraph]]). As of mid 2021, FlightGear is in the process of working towards adopting the OpenGL Core Profile, this means that [[PUI]] is causing trouble and needs to be replaced/disabled or ported.

PUI provides a fairly basic, but robust, set of widgets. PUI is also used for rendering the [[Menubar]].

FlightGear uses a GUI widget set that is implemented on top of raw (legacy) [[OpenGL]]. This has many advantages from a portability standpoint and from the standpoint of integrating with window systems. [[PUI]] doesn't have every feature under the sun, but it was never meant to. It's relatively small, lean, mean, and written on top of [[OpenGL]] which makes life *much* easier for us.

[[PUI]] already is a separate distinct library within Plib. It depends on some central utility stuff, but that's about it. So it is pretty stripped down and separate already.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg26011.html</ref>

We are to some extent hamstrung by the rather old GUI toolkit we use. However, replacing that is going to be non-trivial, and it would affect not just the core GUI but also all the dialog boxes that have been set up for particular aircraft.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg25985.html</ref>

Flightgear can look amazing when you use the HDR pipeline. We absolutely need this to stay relevant. The problem is that HDR is not compatible with OpenGL1 PUI. Work on getting rid of PUI has been going on for over a decade (longer than it took to implement it).<ref>https://sourceforge.net/p/flightgear/mailman/message/37727346/</ref>

[[File:menubar2.jpg|517px]]

== Replacement status ==
{{See also|FlightGear_and_OpenGL_ES#Example:_disabling_PUI}}

{{Note| Update 09/2022: The PUI replacement [[QtQuick_use_in_FlightGear#Background|was going to be Qt]] but it started to get very complicated with changes in Qt 5.15 + Qt 6, so James is going with a more light-weight Canvas based approach now.

Qt added support for Vulkan / Metal / D3D starting in 5.15, but FlightGear / OpenSceneGraph can’t support those, so integrating the two renderers went from being ‘complicated but ok’ to ‘very very complicated’.

So now James is going with something much more lightweight using some C++ compatibility code, some Nasal for styling and the existing [[Canvas widgets|Canvas widget rendering]] from Thomas Geymayer (TheTom) with some extensions and additions, based on the [[Howto:Processing_legacy_PUI_dialogs_using_Canvas#Original_Discussion|plans originally discussed when the Canvas GUI system was added to FlightGear]]: some pieces are in FlightGear & FGData already.

James has basic dialogs working okay but not the more complex ones and everything looks kind of ugly, he needs to improve the visual look before he shares screenshots to avoid everyone freaking out :) The disadvantage of this approach is James is far from expert at creating visual appearances this way, so it’s kind on unrewarding and slow for him. If someone likes messing with CSS-type styling, border-images and hover-states, ping him since we could probably move things also faster <ref>https://sourceforge.net/p/flightgear/mailman/message/37701750/</ref>}}

=== Motivation ===
{{Main article|Core Profile support}}

The bigger issue here is we need to ditch [[PUI]] (which is in progress) and some OpenGL 1.0 code (HUD, 2D panels especially - can be #ifdef for now) so we can enable Core profile on Mac - since Mac 4.x support (we only hit about 4.3 alas, but with some extensions to get in sight of 4.5) is Core profile only, no Compatability mode.

Improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, many people are convinced PUI needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

While most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so [using Qt5] would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

== Canvas Emulation ==
'''Last updated: 04/2023 <ref>https://sourceforge.net/p/flightgear/mailman/message/37805054/</ref>
'''
=== Status ===
As of 01/2023, the replacement for PUI is making good progress<ref>https://sourceforge.net/p/flightgear/mailman/message/37765706/</ref>.

In February 2022, James reported having something in progress locally, and that should even be something we can try in March/April 2022. Hopefully that’s quick enough, knowing it has been a long time coming.<ref>https://sourceforge.net/p/flightgear/mailman/message/37606439/</ref>

There's now an XML to Nasal bridge, to keep PUI dialogs working (Disabled by a CMake option)
This is implemented on top of the [[Canvas]] system.

This builds equivalent C++ objects to what the [[PUI]] dialogs build, with properties exposed to Nasal.
Peer objects are created by Nasal [[callbacks]], which can implement the various dialog functions needed to keep compatibility, especially the [[#Background|‘update’ and ‘apply’ hooks]].<ref>https://sourceforge.net/p/flightgear/flightgear/ci/cbd5ef9e7b8f433dbc1ba97bae7d7cfc894e7cef/</ref>

Use the following [[Building using CMake|cmake option]] to enable this code: <code>-DENABLE_PUICOMPAT=ON</code>

The new Compatibility files can now be found in $FG_SRC/GUI:

* {{flightgear file|src/GUI/FGPUICompatDialog.cxx }}
* {{flightgear file|src/GUI/FGPUICompatDialog.hxx }}
* {{flightgear file|src/GUI/PUICompatObject.cxx }}

01/2023: James is slowly working on creating the pop-up menu and combo-box widgets [...]

One of the major things slowing down James' work on the popup-menu and combo box is time to restart the simulator for each change, he is looking for some solution to re-load the widget Nasal code independently. <ref><https://sourceforge.net/p/flightgear/mailman/message/37756183/</ref>

=== Todo ===
Nothing in particular : help debugging the grid layout (which is in simgear) would be good. For now you could create a grid layout manually using some Nasal.

For the menubar, we need to expose the C++ data to Nasal : we need a FGCompatMenuBar (alongisde FGPUIMenuBar) implementing FGMenubar which calls _createMenuObject in MenuBar.nas, using the same way I lookup and call _createDialogPeer in XMLDialog.nas

(Make sure you don’t break the macOS native menubar in the process!)

You can probably pass a wrapped SGpropertyNode into this, and then fill in the stubs in that file to use the Menu widgets Frederic has written.

Global menu keybindings won’t worry but don’t touch that, I have a separate plan for it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37805736/</ref>

James has done about 75% (hah!) of the C++ work to enable live reloading of modules this way, but unfortunately there are some code paths that would become crashy if you use the feature for the Canvas: because it would reference the ‘old’ (pre-reload) Nasal code, and not the new one, and therefore you’d get a weird mix of old and new, and then just crash the sim. To fix it properly I need to track down those places that store a reference to Canvas and give them a re-init method, so we don’t keep the stale references.

The general non-fun-ness of that kind of debugging is James has been making such slow progress on my PUI replacement widgets recently <ref>https://sourceforge.net/p/flightgear/mailman/message/37756263/</ref>

As of 04/2023, remaining items on the todo list are: <ref>https://sourceforge.net/p/flightgear/mailman/message/37805060/</ref>

* Grid layout
** GridLayout needs debugged: After this, the basic UI is usable, would probably make it a switchable option on ‘next’ (I can already use the simulator with the new UI today, but all the sizes are off in the grid layouts which we use everywhere)

* list
* table (and tree ?) models corresponding views
* waypoint list
* Re-write the waypoint list and airport dialog to work again (since these use custom widgets):
** log list
** airport-list equivalents
* Nasal access to the menu i18n functions
* selection support for single- and multi-line text (which is being worked on -> CanvasPangoText)
* Keyboard shortcut handling, although this is not really a PUI vs replacement issue, to me we should handle UI shortcuts in the same was normal keyboard.xml shortcuts
** this previously worked because PUI got ‘first chance’ at handling key input. But we always had duplication between keyboard.xml and other places, so I would rather standardise on keyboard.xml, but allow a UI element to set a scope for shortcuts. (So that Copy/paste shortcuts etc can work in a text input, at least … but probably some other standard ones) <ref>https://sourceforge.net/p/flightgear/mailman/message/37805188/</ref>
* Ensure all the places which use the PUI combo-box and list-widget work : there’s a few of these.

The CanvasPangoText stuff is needed but we can perfectly well run the UI on next without it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37805176/</ref>

=== Parser ===
{{Main article|pui2canvas}}
The corresponding Nasal/Canvas module to dynamically "translate" legacy PUI/XML dialogs into Canvas dialogs (at runtime), is to be found in {{fgdata file|Nasal/gui/XMLDialog.nas}} <ref>https://sourceforge.net/p/flightgear/fgdata/ci/fe7c87b21a69f88ddb87d89453c48d12b69660e2/</ref>

=== Widgets ===
{{Main article|Howto:Creating a Canvas GUI Widget}}

It’s split between Simgear (see classes with widget / layout in the name) and in FGData. (Eg widgets/Button.nas) To be able to use the existing dialog XML files un-modified (which is a design goal), James is extending the widget types with many additional ones (eg PUI has slider, dial, combo-box, checkbox, all of which need to be created, see [[Canvas widget matrix]].

This is about 30% done and is the bit he's very slow at). Thomas’s canvas widgets have a very good separation of API + state from appearance, so all styling is in its own file, and James is being very strict about maintaining this separation, so we also retain the re-styling feature of the PUI UI, which many people also rely on. This does make the process of adding new widgets more complex, however.

{{See also|Canvas widgets}}

=== Layouting ===
The other thing is to preserve all the layouting: James has added a grid layout to Simgear, since that is supported by the existing PUI code (even though the layouts are not actually part of PUI itself). The problem is getting the sizing / hinting of all the widgets to match the PUI values, so that dialogs look approximately the same under the new UI as they did with PUI; again this a design goal so that all existing dialogs in aircraft and add-ons, which we can’t update, continue to work and be usable. Debugging that is also proving quite tricky, since there’s all kinds of hard-coded assumptions built into PUI widgets about pixels, font-sizes etc which are not true in the new system.<ref>https://sourceforge.net/p/flightgear/mailman/message/37701792/</ref>

== Background ==
In FlightGear, PUI dialogs are standard [[PropertyList XML File]]s that are stored in $FG_ROOT/gui/dialogs, they can contain the widgets mentioned in {{readme file|gui}}, using a simple layout engine discussed in {{readme file|layout}}, and bindings using a combination of so called fgcommands operating on properties (see {{readme file|commands}}) and custom [[Nasal]] (FlightGear scripting) code.

In addition, each PUI/XML dialog may contain Nasal script sections that are executed when opening/closing the dialog, a feature which is commonly used for procedurally creating/updating widgets using the [[Nasal_library#cmdarg.28.29|cmdarg() API]], which allows the dialog tree to be traversed and manipulated prior to the dialog being rendered.
Widgets can be conditionally hidden/shown using a wrapper for [[Conditions|SGCondition]] in [[Nasal_library/props|props.nas]]
The <code>canvas</code> widget also supports its own embedded Nasal code section to execute arbitrary widget specific Nasal code upon opening/closing the dialog/widget.

PUI/XML dialogs can be loaded, dynamically created, updated and closed using a handful of fgcommands:
* {{fgcommand|dialog-new}}
* {{fgcommand|dialog-show}}
* {{fgcommand|dialog-update}}
* {{fgcommand|dialog-apply}}
* {{fgcommand|dialog-close}}

PUI related OpenGL code is particularly infamous for causing rendering artifacts for people on AMD/ATI and Intel hardware (especially in combination with certain fonts/styles and [[Effects|effects]]/[[Shaders|shaders]]), see {{Issue|2213}}.

PUI is also known to affect rendering performance quite significantly (see {{search |keywords=anthrax+gui}}), while also preventing FlightGear from using a more recent version of OpenGL<ref>http://sourceforge.net/p/flightgear/mailman/message/34532040/</ref><ref>http://forum.flightgear.org/viewtopic.php?f=71&t=24046</ref>.

However, improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Besides, while most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

But given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, graphics folks are also convinced it needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

In addition, [[OpenSceneGraph]] (OSG) can obviously not help optimize any PUI related GL code and PUI widgets are generally considered to be pretty archaic and not easy to extend<ref>http://sourceforge.net/p/flightgear/mailman/message/26832164/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587120/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587272/</ref>.

{{Note|We use the GUI code from PLIB, which doesn't know anything about OSG. See the SGPuDrawable class in $FG_SRC/Viewer/renderer.cxx for the implementation. The one catch is that OSG has a strong notion of separation between the update of a "scene" and its rendering, and that might not play well with arbitrary existing OpenGL code. }}

As of late 2015, there is heavy activity towards providing alternatives to a PUI-based UI:
* [[Integrated Web GUI]] (external, browser-based - fully asynchronous)
* [[Howto:Processing legacy PUI dialogs using Canvas]] (internal, using the [[Canvas]] system and a simple [[Nasal]] parser to deal with existing PUI/XML dialogs)

<gallery mode="packed">
Early-Phi-screen shot.PNG|Screenshot showing [[Phi]]
About-dialog-rendered-by-canvas.png|Screenshot showing a dialog rendered by the [[Howto:Processing legacy PUI dialogs using Canvas|pui2canvas parser]]
</gallery>

== History ==
{{Caution|This is merely kept for future reference, many of the ideas discussed below have become obsolete as of 09/2022, if in doubt, please get in touch via devel-list.}}
=== 2021 ===
In early 2021, James did a brief evaluation of [https://github.com/ocornut/imgui ImGUI] as a possibility - he's also evaluating it in some projects at his day job.

The API is interesting if you’re starting from scratch and only exclusively in C++, but it’s not a great fit for how we define GUIs in FG (via [[XML]]/[[Nasal]]): there is no back door that he could find, to access the persistent state of the GUI, or build it up in a data-driven way. So making a mapping to keep our existing GUI XML working (and updating correctly) becomes a bit of a chore.<ref>https://sourceforge.net/p/flightgear/mailman/message/37295586/</ref>

Pretty much all of the FlightGear GUI is defined in XML space, except for a few oddments. Let’s say 95% at this point.

Additionally, even if we were to change that for the core sim (and James' current plan is to keep the XML syntax and just extend it), the installed base of '''aircraft''' ship their own XML dialogs (eg., replacing the autopilot dialog with a custom one, or just adding their own aircraft-specific helper controls for doors / lights / cargo / whatever). So even if we found the most sublimely beautiful, intuitive, compact GUI description language in the world, we have to keep the XML syntax working as-is, for the foreseeable future.

Given this, James' intention is to replace the output side [[PUI]] but keep the front-end side (XML / properties / bindings) unchanged, and therefore backwards compatible, and simply add some new types / options / widget types going forward. This will mean we still have to deal with the slightly cumbersome XML+Nasal syntax, but, well, it’s not *that* cumbersome. <ref>https://sourceforge.net/p/flightgear/mailman/message/37296280/</ref>

In mid 2021, James reported that he is working on some ‘PUICompat’ classes which hold/own/represent the GUI state in C++, but which can be used with [[Nasal/CppBind|Nasal CppBind]]. And of course we could indeed expose those later on. <ref>https://sourceforge.net/p/flightgear/mailman/message/37297727/</ref>

In July 2021, James suggested not to worry about the existing GUI code, it’s going in the bin.<ref>https://sourceforge.net/p/flightgear/mailman/message/37325905/</ref>

For the time being, the in-sim GUi can’t do Unicode yet, but James is working on it, hopefully available soon.<ref>https://sourceforge.net/p/flightgear/mailman/message/37328200/</ref>
Also, the in-sim menubar will change with the new GUI, *and* we use a native menubar on macOS. Until James replaces the PUI fonts we can’t use Unicode symbols. So, will have to come back to it once the new GUI is merged.<ref>https://sourceforge.net/p/flightgear/mailman/message/37327237/</ref>

=== 2020 ===
As of 03/2020, the PLIB replacement was reported to be in the backlog <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36951255/
|title = <nowiki>Re: [Flightgear-devel] C++ and/or OSG question </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Mar 18th, 2020
|added = Mar 18th, 2020
|script_version = 0.50
}}</ref>.

With PLIB replacement work likely being re-scheduled for [[Post FlightGear 2020.2 LTS changes]] <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36985375/
|title = <nowiki>Re: [Flightgear-devel] Working Group Proposal - Boost and PLIB replacement - Delegation and Teamwork </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = April 18th, 2020
|added = April 18th, 2020
|script_version = 1.10
}}</ref>.

In 08/2020, James stated that he was still working (exceptionally slowly!) on replacing PUI (as part of removing legacy OpenGL code (PUI, HUD, 2d panels, porting Canvas away form ShivaVG), so we can switch to Vulkan/VSG at some point (ideally at some point before Apple turn off OpenGL support…)), and that he doesn't think /any/ of us *want* to be working on these features particularly, but projects like these need to be done before anyone can have fun with VSG or Vulkan (personally James would be very enthusiastic about working on VSG support (being on macOS, I also have the most to lose / gain from it)). Sometimes that’s just how it goes. Equally they will all benefit the project ultimately, but the payoff both for the individual and the project is very drawn out. <ref>https://sourceforge.net/p/flightgear/mailman/message/37077158/</ref>

In 10/2020, the estimation is that PUI should be going away really ‘soon’, the replacement code is already in next / 2020.2. (There’s no plan to actually /use/ the new UI code in 2020.2, but if the bugs in it prove simple, we could actually turn it for specific dialog: it seems very unlikely this makes sense for a stable release however)<ref>https://sourceforge.net/p/flightgear/mailman/message/37123818/</ref>

The fixed-function removal, is actively in hand (Gaetan is working on the 2D panel part, and James is going to focus on PUI in the rest of 2020). James hopes that means next year he can focus on Vulkan, or at least, using OSG as if /were/ VSG, so the migration in a year or two when VSG is stable, is not so painful.<ref>https://sourceforge.net/p/flightgear/mailman/message/37129098/</ref>

The PUI UI and replacement can co-exist in the same build (they already do, effectively.<ref>https://sourceforge.net/p/flightgear/mailman/message/37131297/</ref>

In 11/2020, James suggested not to worry about details such as PUI styling/theming etc: we’re not making such changes for the LTS, and PUI should be gone before the next release.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142225/</ref> Also, he recommended (to everyone) to stop touching GUI stuff for a few weeks, as he's about to turn it all on its head.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142356/</ref>

=== 2019 ===
The new GUI has been incubating for a few years, but there's apparently been a lot of progress as of 10/2019.

It is likely the new GUI will be a user opt-in feature - at least initially. The sunset of the PLIB library _could_ happen relatively soon, but
people will need to see the new GUI and react to it before we could commit to PLIB removal <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36784489/
|title = <nowiki>Re: [Flightgear-devel] in Flightgear/Simgear C++ Code: What needs Doing? What are YOU Doing? What would you do if you had the time? </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Oct 14th, 2019
|added = Oct 14th, 2019
|script_version = 0.50
}}</ref>.

In 02/2019, James stated that the new UI is coming quite soon. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36589420/
|title = <nowiki> Re: [Flightgear-devel] Lagging </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Feb 17th, 2019
|added = Feb 17th, 2019
|script_version = 0.40
}}</ref>

=== 2018 ===
{{See also|QtQuick use in FlightGear}}

According to James, we have to accept that changes like testing or making [[PUI]] a modular thing or moving the JS code tend to have an immediate pain for some people (because strange stuff gets broken, and takes some time to get fixed), whereas the payoff in terms of improved joystick handling or replacing the UI or testing of all subsystems will take some months or years to be felt.<ref>https://sourceforge.net/p/flightgear/mailman/message/36323240/</ref>

James said he was in the middle of porting the launcher’s final tab (location) to the new UI scheme, once that’s done he will start sketching out the ‘in sim’ settings UI using the same pieces. He’ll send a request for contributions around about that in the next three-four weeks, once he has enough templates & examples that there is a clear pattern to follow.<ref>https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/2d10f16c-ddc8-07f3-07e7-eca2a0a0d55f%40zaretto.com/#msg36293586</ref>

James announced that the launcher is now feature complete with the QtQuick UI, he’ll keep making bug-fixes of course as people report them, but my todo list for the core features is now done<ref>https://sourceforge.net/p/flightgear/mailman/message/36355833/</ref>.

=== 2017 ===

In 10/2017, James said he was getting really close to having the PUI replacement UI suitable for beta-testing.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36067646/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 7th, 2017
|added = Oct 7th, 2017
|script_version = 0.40
}}</ref>

Originally, James was hoping to land the PUI replacement GUI in the last dev cycle in 2017 (at least as a proof-of-concept, probably not as the default UI), so wouldn’t expend lots of effort on things like collapsible sections which might be a lot of work with the current PUI/Canvas approaches, but are trivial with the new [[QtQuick use in FlightGear|QtQuick based UI scheme]].<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36059822/
|title = <nowiki> Re: [Flightgear-devel] Canvas MapLayer for OpenStreetMap, OpenAIP,
VFR Sectionals </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 1st, 2017
|added = Oct 1st, 2017
|script_version = 0.40
}}</ref>

Once the basic new UI is in place we can experiment with different re-arrangements easily, without being limited by PUI. (James expects PUI to live on as the default / alternate UI while this happens)<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36061229/
|title = <nowiki> Re: [Flightgear-devel] FGFS macOS Menubar </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 2nd, 2017
|added = Oct 2nd, 2017
|script_version = 0.40
}}</ref>

Technically, this entails replacing dialog.cxx with some code which builds up some special ‘PUI-Emulation’ QtQuick controls, so that existing dialogs (especially from Aircraft) continue to work. This mode will look somewhat ugly but hopefully no more ugly than PUI! And it helps that the set of widgets we have in PUI is limited, and the ‘tricky’ widgets (map, scrolling list, etc) are in the dialogs will will replace with new ones first.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068767/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

This PUI emulation isn't going to use any code from PLIB<ref>https://sourceforge.net/p/flightgear/mailman/message/36985303/</ref>, so what will remain from it in FG afterwards will be the FNT and JS components (reworked).<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068817/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> Florent Rougon </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

=== 2016 ===
We need to explore if Qt Quick or widgets is the better way to go, with a preference towards Qt Quick, since it will allow things closer to current PUI (semi-transparent widgets on top of the 3D content). It still allows creating separate windows too (Erik’s use case), but means we get consistent, custom theming on all platforms, since standard desktop look is not so nice for a flight-sim.

James intention is to make a QML-hosting OSG-drawable, and add this as a concept in Qt-enabled builds, then port some PUI dialogs to it, and see how easy / painful the process is. Hell create some QObjects which expose commands and the property tree and Nasal.

This has the advantage of not touching the OSG window at all, QtQuick simply provides some additional OpenGL rendering on top, which we pass events to - pretty much exactly the same as what we already do for PUI, and hopefully can co-exist with it. James got this working in a local OSG tree in a standalone demo, but that’s based on osgQt - he wants to see if he can make it work on a normal, non-Qt OSG window inside FlightGear.<ref>https://sourceforge.net/p/flightgear/mailman/message/35156051/</ref>

The idea is to host an XML dialog (Currently done with PUI) from Qt also. The question is if that can be done keeping ‘source compatibility’ exactly with the current UI XML and Nasal interface. It probably can be, but many of the PUI widgets have really ugly APIs, especially for combo-boxes, drop-down menus and scrolling lists, where it makes sense to map a Nasal class to a Qt ItemModel, which would be more elegant and easy to work with in both Nasal and integrate on the Qt side. But obviously would mean changing the dialog sources.

Of course, aircraft dialogs tend to be simpler, and not use the more complex PUI widgets, precisely for reasons like this, but that’s a limitation it would be best to remove.<ref>https://sourceforge.net/p/flightgear/mailman/message/35155721/</ref>


== References ==
{{Appendix}}

[[Category:PUI| ]]
[[Category:Rendering roadblocks]]

PUI

2023-04-19T10:11:55Z

Hooray: /* Canvas Emulation */ https://sourceforge.net/p/flightgear/mailman/message/37805176/

{{Feature to be removed|version=2023.3|reason=[[Plib]]/PUI is to be removed and replaced by a [[Canvas widget matrix|Canvas/Nasal based solution]] to help improve compatibility with [[OSG]] 3.6+ and [[OpenGL]] 4.x ([[Core Profile support|OpenGL Core Profile]], see [[2022.X Release plan]] ) and improve performance by [[Unifying the 2D rendering backend via canvas|phasing out legacy OpenGL code]]. Therefore, people should be careful when extending the '''PUI''' based legacy GUI engine<ref>https://sourceforge.net/p/flightgear/mailman/message/34921495/</ref><ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35157325/
|title = <nowiki> Re: [Flightgear-devel] GUI options (Was: Aircraft center) </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jun 14th, 2016
|added = Jun 14th, 2016
|script_version = 0.40
}}</ref> and coordinate any related work with the devel mailing list first-this applies particularly to adding any [[Template:PUI_widget|additional hard-coded PUI widgets]]. }}
[[File:Exit.png|thumb|FlightGear GUI dialog (exit.xml)stored in $FG_ROOT/gui/dialogs]]
{{GUI Navbar}}

[[File:Custom-autopilot-dialog.png|right|200px]]
[[PUI]] is the standard GUI engine used in FlightGear, it is part of [[PLIB]] and is using raw, fixed-pipeline, [[OpenGL]] code internally (no [[OpenSceneGraph]]). As of mid 2021, FlightGear is in the process of working towards adopting the OpenGL Core Profile, this means that [[PUI]] is causing trouble and needs to be replaced/disabled or ported.

PUI provides a fairly basic, but robust, set of widgets. PUI is also used for rendering the [[Menubar]].

FlightGear uses a GUI widget set that is implemented on top of raw (legacy) [[OpenGL]]. This has many advantages from a portability standpoint and from the standpoint of integrating with window systems. [[PUI]] doesn't have every feature under the sun, but it was never meant to. It's relatively small, lean, mean, and written on top of [[OpenGL]] which makes life *much* easier for us.

[[PUI]] already is a separate distinct library within Plib. It depends on some central utility stuff, but that's about it. So it is pretty stripped down and separate already.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg26011.html</ref>

We are to some extent hamstrung by the rather old GUI toolkit we use. However, replacing that is going to be non-trivial, and it would affect not just the core GUI but also all the dialog boxes that have been set up for particular aircraft.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg25985.html</ref>

Flightgear can look amazing when you use the HDR pipeline. We absolutely need this to stay relevant. The problem is that HDR is not compatible with OpenGL1 PUI. Work on getting rid of PUI has been going on for over a decade (longer than it took to implement it).<ref>https://sourceforge.net/p/flightgear/mailman/message/37727346/</ref>

[[File:menubar2.jpg|517px]]

== Replacement status ==
{{See also|FlightGear_and_OpenGL_ES#Example:_disabling_PUI}}

{{Note| Update 09/2022: The PUI replacement [[QtQuick_use_in_FlightGear#Background|was going to be Qt]] but it started to get very complicated with changes in Qt 5.15 + Qt 6, so James is going with a more light-weight Canvas based approach now.

Qt added support for Vulkan / Metal / D3D starting in 5.15, but FlightGear / OpenSceneGraph can’t support those, so integrating the two renderers went from being ‘complicated but ok’ to ‘very very complicated’.

So now James is going with something much more lightweight using some C++ compatibility code, some Nasal for styling and the existing [[Canvas widgets|Canvas widget rendering]] from Thomas Geymayer (TheTom) with some extensions and additions, based on the [[Howto:Processing_legacy_PUI_dialogs_using_Canvas#Original_Discussion|plans originally discussed when the Canvas GUI system was added to FlightGear]]: some pieces are in FlightGear & FGData already.

James has basic dialogs working okay but not the more complex ones and everything looks kind of ugly, he needs to improve the visual look before he shares screenshots to avoid everyone freaking out :) The disadvantage of this approach is James is far from expert at creating visual appearances this way, so it’s kind on unrewarding and slow for him. If someone likes messing with CSS-type styling, border-images and hover-states, ping him since we could probably move things also faster <ref>https://sourceforge.net/p/flightgear/mailman/message/37701750/</ref>}}

=== Motivation ===
{{Main article|Core Profile support}}

The bigger issue here is we need to ditch [[PUI]] (which is in progress) and some OpenGL 1.0 code (HUD, 2D panels especially - can be #ifdef for now) so we can enable Core profile on Mac - since Mac 4.x support (we only hit about 4.3 alas, but with some extensions to get in sight of 4.5) is Core profile only, no Compatability mode.

Improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, many people are convinced PUI needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

While most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so [using Qt5] would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

== Canvas Emulation ==
'''Last updated: 04/2023 <ref>https://sourceforge.net/p/flightgear/mailman/message/37805054/</ref>
'''
=== Status ===
As of 01/2023, the replacement for PUI is making good progress<ref>https://sourceforge.net/p/flightgear/mailman/message/37765706/</ref>.

In February 2022, James reported having something in progress locally, and that should even be something we can try in March/April 2022. Hopefully that’s quick enough, knowing it has been a long time coming.<ref>https://sourceforge.net/p/flightgear/mailman/message/37606439/</ref>

There's now an XML to Nasal bridge, to keep PUI dialogs working (Disabled by a CMake option)
This is implemented on top of the [[Canvas]] system.

This builds equivalent C++ objects to what the [[PUI]] dialogs build, with properties exposed to Nasal.
Peer objects are created by Nasal [[callbacks]], which can implement the various dialog functions needed to keep compatibility, especially the [[#Background|‘update’ and ‘apply’ hooks]].<ref>https://sourceforge.net/p/flightgear/flightgear/ci/cbd5ef9e7b8f433dbc1ba97bae7d7cfc894e7cef/</ref>

Use the following [[Building using CMake|cmake option]] to enable this code: <code>-DENABLE_PUICOMPAT=ON</code>

The new Compatibility files can now be found in $FG_SRC/GUI:

* {{flightgear file|src/GUI/FGPUICompatDialog.cxx }}
* {{flightgear file|src/GUI/FGPUICompatDialog.hxx }}
* {{flightgear file|src/GUI/PUICompatObject.cxx }}

01/2023: James is slowly working on creating the pop-up menu and combo-box widgets [...]

One of the major things slowing down James' work on the popup-menu and combo box is time to restart the simulator for each change, he is looking for some solution to re-load the widget Nasal code independently. <ref><https://sourceforge.net/p/flightgear/mailman/message/37756183/</ref>

James has done about 75% (hah!) of the C++ work to enable live reloading of modules this way, but unfortunately there are some code paths that would become crashy if you use the feature for the Canvas: because it would reference the ‘old’ (pre-reload) Nasal code, and not the new one, and therefore you’d get a weird mix of old and new, and then just crash the sim. To fix it properly I need to track down those places that store a reference to Canvas and give them a re-init method, so we don’t keep the stale references.

The general non-fun-ness of that kind of debugging is James has been making such slow progress on my PUI replacement widgets recently <ref>https://sourceforge.net/p/flightgear/mailman/message/37756263/</ref>

As of 04/2023, remaining items on the todo list are: <ref>https://sourceforge.net/p/flightgear/mailman/message/37805060/</ref>

* Grid layout
** GridLayout needs debugged: After this, the basic UI is usable, would probably make it a switchable option on ‘next’ (I can already use the simulator with the new UI today, but all the sizes are off in the grid layouts which we use everywhere)

* list
* table (and tree ?) models corresponding views
* waypoint list
* Re-write the waypoint list and airport dialog to work again (since these use custom widgets):
** log list
** airport-list equivalents
* Nasal access to the menu i18n functions
* selection support for single- and multi-line text (which is being worked on -> CanvasPangoText)
* Keyboard shortcut handling, although this is not really a PUI vs replacement issue, to me we should handle UI shortcuts in the same was normal keyboard.xml shortcuts
** this previously worked because PUI got ‘first chance’ at handling key input. But we always had duplication between keyboard.xml and other places, so I would rather standardise on keyboard.xml, but allow a UI element to set a scope for shortcuts. (So that Copy/paste shortcuts etc can work in a text input, at least … but probably some other standard ones) <ref>https://sourceforge.net/p/flightgear/mailman/message/37805188/</ref>
* Ensure all the places which use the PUI combo-box and list-widget work : there’s a few of these.

The CanvasPangoText stuff is needed but we can perfectly well run the UI on next without it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37805176/</ref>

=== Parser ===
{{Main article|pui2canvas}}
The corresponding Nasal/Canvas module to dynamically "translate" legacy PUI/XML dialogs into Canvas dialogs (at runtime), is to be found in {{fgdata file|Nasal/gui/XMLDialog.nas}} <ref>https://sourceforge.net/p/flightgear/fgdata/ci/fe7c87b21a69f88ddb87d89453c48d12b69660e2/</ref>

=== Widgets ===
{{Main article|Howto:Creating a Canvas GUI Widget}}

It’s split between Simgear (see classes with widget / layout in the name) and in FGData. (Eg widgets/Button.nas) To be able to use the existing dialog XML files un-modified (which is a design goal), James is extending the widget types with many additional ones (eg PUI has slider, dial, combo-box, checkbox, all of which need to be created, see [[Canvas widget matrix]].

This is about 30% done and is the bit he's very slow at). Thomas’s canvas widgets have a very good separation of API + state from appearance, so all styling is in its own file, and James is being very strict about maintaining this separation, so we also retain the re-styling feature of the PUI UI, which many people also rely on. This does make the process of adding new widgets more complex, however.

{{See also|Canvas widgets}}

=== Layouting ===
The other thing is to preserve all the layouting: James has added a grid layout to Simgear, since that is supported by the existing PUI code (even though the layouts are not actually part of PUI itself). The problem is getting the sizing / hinting of all the widgets to match the PUI values, so that dialogs look approximately the same under the new UI as they did with PUI; again this a design goal so that all existing dialogs in aircraft and add-ons, which we can’t update, continue to work and be usable. Debugging that is also proving quite tricky, since there’s all kinds of hard-coded assumptions built into PUI widgets about pixels, font-sizes etc which are not true in the new system.<ref>https://sourceforge.net/p/flightgear/mailman/message/37701792/</ref>

== Background ==
In FlightGear, PUI dialogs are standard [[PropertyList XML File]]s that are stored in $FG_ROOT/gui/dialogs, they can contain the widgets mentioned in {{readme file|gui}}, using a simple layout engine discussed in {{readme file|layout}}, and bindings using a combination of so called fgcommands operating on properties (see {{readme file|commands}}) and custom [[Nasal]] (FlightGear scripting) code.

In addition, each PUI/XML dialog may contain Nasal script sections that are executed when opening/closing the dialog, a feature which is commonly used for procedurally creating/updating widgets using the [[Nasal_library#cmdarg.28.29|cmdarg() API]], which allows the dialog tree to be traversed and manipulated prior to the dialog being rendered.
Widgets can be conditionally hidden/shown using a wrapper for [[Conditions|SGCondition]] in [[Nasal_library/props|props.nas]]
The <code>canvas</code> widget also supports its own embedded Nasal code section to execute arbitrary widget specific Nasal code upon opening/closing the dialog/widget.

PUI/XML dialogs can be loaded, dynamically created, updated and closed using a handful of fgcommands:
* {{fgcommand|dialog-new}}
* {{fgcommand|dialog-show}}
* {{fgcommand|dialog-update}}
* {{fgcommand|dialog-apply}}
* {{fgcommand|dialog-close}}

PUI related OpenGL code is particularly infamous for causing rendering artifacts for people on AMD/ATI and Intel hardware (especially in combination with certain fonts/styles and [[Effects|effects]]/[[Shaders|shaders]]), see {{Issue|2213}}.

PUI is also known to affect rendering performance quite significantly (see {{search |keywords=anthrax+gui}}), while also preventing FlightGear from using a more recent version of OpenGL<ref>http://sourceforge.net/p/flightgear/mailman/message/34532040/</ref><ref>http://forum.flightgear.org/viewtopic.php?f=71&t=24046</ref>.

However, improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Besides, while most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

But given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, graphics folks are also convinced it needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

In addition, [[OpenSceneGraph]] (OSG) can obviously not help optimize any PUI related GL code and PUI widgets are generally considered to be pretty archaic and not easy to extend<ref>http://sourceforge.net/p/flightgear/mailman/message/26832164/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587120/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587272/</ref>.

{{Note|We use the GUI code from PLIB, which doesn't know anything about OSG. See the SGPuDrawable class in $FG_SRC/Viewer/renderer.cxx for the implementation. The one catch is that OSG has a strong notion of separation between the update of a "scene" and its rendering, and that might not play well with arbitrary existing OpenGL code. }}

As of late 2015, there is heavy activity towards providing alternatives to a PUI-based UI:
* [[Integrated Web GUI]] (external, browser-based - fully asynchronous)
* [[Howto:Processing legacy PUI dialogs using Canvas]] (internal, using the [[Canvas]] system and a simple [[Nasal]] parser to deal with existing PUI/XML dialogs)

<gallery mode="packed">
Early-Phi-screen shot.PNG|Screenshot showing [[Phi]]
About-dialog-rendered-by-canvas.png|Screenshot showing a dialog rendered by the [[Howto:Processing legacy PUI dialogs using Canvas|pui2canvas parser]]
</gallery>

== History ==
{{Caution|This is merely kept for future reference, many of the ideas discussed below have become obsolete as of 09/2022, if in doubt, please get in touch via devel-list.}}
=== 2021 ===
In early 2021, James did a brief evaluation of [https://github.com/ocornut/imgui ImGUI] as a possibility - he's also evaluating it in some projects at his day job.

The API is interesting if you’re starting from scratch and only exclusively in C++, but it’s not a great fit for how we define GUIs in FG (via [[XML]]/[[Nasal]]): there is no back door that he could find, to access the persistent state of the GUI, or build it up in a data-driven way. So making a mapping to keep our existing GUI XML working (and updating correctly) becomes a bit of a chore.<ref>https://sourceforge.net/p/flightgear/mailman/message/37295586/</ref>

Pretty much all of the FlightGear GUI is defined in XML space, except for a few oddments. Let’s say 95% at this point.

Additionally, even if we were to change that for the core sim (and James' current plan is to keep the XML syntax and just extend it), the installed base of '''aircraft''' ship their own XML dialogs (eg., replacing the autopilot dialog with a custom one, or just adding their own aircraft-specific helper controls for doors / lights / cargo / whatever). So even if we found the most sublimely beautiful, intuitive, compact GUI description language in the world, we have to keep the XML syntax working as-is, for the foreseeable future.

Given this, James' intention is to replace the output side [[PUI]] but keep the front-end side (XML / properties / bindings) unchanged, and therefore backwards compatible, and simply add some new types / options / widget types going forward. This will mean we still have to deal with the slightly cumbersome XML+Nasal syntax, but, well, it’s not *that* cumbersome. <ref>https://sourceforge.net/p/flightgear/mailman/message/37296280/</ref>

In mid 2021, James reported that he is working on some ‘PUICompat’ classes which hold/own/represent the GUI state in C++, but which can be used with [[Nasal/CppBind|Nasal CppBind]]. And of course we could indeed expose those later on. <ref>https://sourceforge.net/p/flightgear/mailman/message/37297727/</ref>

In July 2021, James suggested not to worry about the existing GUI code, it’s going in the bin.<ref>https://sourceforge.net/p/flightgear/mailman/message/37325905/</ref>

For the time being, the in-sim GUi can’t do Unicode yet, but James is working on it, hopefully available soon.<ref>https://sourceforge.net/p/flightgear/mailman/message/37328200/</ref>
Also, the in-sim menubar will change with the new GUI, *and* we use a native menubar on macOS. Until James replaces the PUI fonts we can’t use Unicode symbols. So, will have to come back to it once the new GUI is merged.<ref>https://sourceforge.net/p/flightgear/mailman/message/37327237/</ref>

=== 2020 ===
As of 03/2020, the PLIB replacement was reported to be in the backlog <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36951255/
|title = <nowiki>Re: [Flightgear-devel] C++ and/or OSG question </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Mar 18th, 2020
|added = Mar 18th, 2020
|script_version = 0.50
}}</ref>.

With PLIB replacement work likely being re-scheduled for [[Post FlightGear 2020.2 LTS changes]] <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36985375/
|title = <nowiki>Re: [Flightgear-devel] Working Group Proposal - Boost and PLIB replacement - Delegation and Teamwork </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = April 18th, 2020
|added = April 18th, 2020
|script_version = 1.10
}}</ref>.

In 08/2020, James stated that he was still working (exceptionally slowly!) on replacing PUI (as part of removing legacy OpenGL code (PUI, HUD, 2d panels, porting Canvas away form ShivaVG), so we can switch to Vulkan/VSG at some point (ideally at some point before Apple turn off OpenGL support…)), and that he doesn't think /any/ of us *want* to be working on these features particularly, but projects like these need to be done before anyone can have fun with VSG or Vulkan (personally James would be very enthusiastic about working on VSG support (being on macOS, I also have the most to lose / gain from it)). Sometimes that’s just how it goes. Equally they will all benefit the project ultimately, but the payoff both for the individual and the project is very drawn out. <ref>https://sourceforge.net/p/flightgear/mailman/message/37077158/</ref>

In 10/2020, the estimation is that PUI should be going away really ‘soon’, the replacement code is already in next / 2020.2. (There’s no plan to actually /use/ the new UI code in 2020.2, but if the bugs in it prove simple, we could actually turn it for specific dialog: it seems very unlikely this makes sense for a stable release however)<ref>https://sourceforge.net/p/flightgear/mailman/message/37123818/</ref>

The fixed-function removal, is actively in hand (Gaetan is working on the 2D panel part, and James is going to focus on PUI in the rest of 2020). James hopes that means next year he can focus on Vulkan, or at least, using OSG as if /were/ VSG, so the migration in a year or two when VSG is stable, is not so painful.<ref>https://sourceforge.net/p/flightgear/mailman/message/37129098/</ref>

The PUI UI and replacement can co-exist in the same build (they already do, effectively.<ref>https://sourceforge.net/p/flightgear/mailman/message/37131297/</ref>

In 11/2020, James suggested not to worry about details such as PUI styling/theming etc: we’re not making such changes for the LTS, and PUI should be gone before the next release.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142225/</ref> Also, he recommended (to everyone) to stop touching GUI stuff for a few weeks, as he's about to turn it all on its head.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142356/</ref>

=== 2019 ===
The new GUI has been incubating for a few years, but there's apparently been a lot of progress as of 10/2019.

It is likely the new GUI will be a user opt-in feature - at least initially. The sunset of the PLIB library _could_ happen relatively soon, but
people will need to see the new GUI and react to it before we could commit to PLIB removal <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36784489/
|title = <nowiki>Re: [Flightgear-devel] in Flightgear/Simgear C++ Code: What needs Doing? What are YOU Doing? What would you do if you had the time? </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Oct 14th, 2019
|added = Oct 14th, 2019
|script_version = 0.50
}}</ref>.

In 02/2019, James stated that the new UI is coming quite soon. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36589420/
|title = <nowiki> Re: [Flightgear-devel] Lagging </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Feb 17th, 2019
|added = Feb 17th, 2019
|script_version = 0.40
}}</ref>

=== 2018 ===
{{See also|QtQuick use in FlightGear}}

According to James, we have to accept that changes like testing or making [[PUI]] a modular thing or moving the JS code tend to have an immediate pain for some people (because strange stuff gets broken, and takes some time to get fixed), whereas the payoff in terms of improved joystick handling or replacing the UI or testing of all subsystems will take some months or years to be felt.<ref>https://sourceforge.net/p/flightgear/mailman/message/36323240/</ref>

James said he was in the middle of porting the launcher’s final tab (location) to the new UI scheme, once that’s done he will start sketching out the ‘in sim’ settings UI using the same pieces. He’ll send a request for contributions around about that in the next three-four weeks, once he has enough templates & examples that there is a clear pattern to follow.<ref>https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/2d10f16c-ddc8-07f3-07e7-eca2a0a0d55f%40zaretto.com/#msg36293586</ref>

James announced that the launcher is now feature complete with the QtQuick UI, he’ll keep making bug-fixes of course as people report them, but my todo list for the core features is now done<ref>https://sourceforge.net/p/flightgear/mailman/message/36355833/</ref>.

=== 2017 ===

In 10/2017, James said he was getting really close to having the PUI replacement UI suitable for beta-testing.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36067646/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 7th, 2017
|added = Oct 7th, 2017
|script_version = 0.40
}}</ref>

Originally, James was hoping to land the PUI replacement GUI in the last dev cycle in 2017 (at least as a proof-of-concept, probably not as the default UI), so wouldn’t expend lots of effort on things like collapsible sections which might be a lot of work with the current PUI/Canvas approaches, but are trivial with the new [[QtQuick use in FlightGear|QtQuick based UI scheme]].<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36059822/
|title = <nowiki> Re: [Flightgear-devel] Canvas MapLayer for OpenStreetMap, OpenAIP,
VFR Sectionals </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 1st, 2017
|added = Oct 1st, 2017
|script_version = 0.40
}}</ref>

Once the basic new UI is in place we can experiment with different re-arrangements easily, without being limited by PUI. (James expects PUI to live on as the default / alternate UI while this happens)<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36061229/
|title = <nowiki> Re: [Flightgear-devel] FGFS macOS Menubar </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 2nd, 2017
|added = Oct 2nd, 2017
|script_version = 0.40
}}</ref>

Technically, this entails replacing dialog.cxx with some code which builds up some special ‘PUI-Emulation’ QtQuick controls, so that existing dialogs (especially from Aircraft) continue to work. This mode will look somewhat ugly but hopefully no more ugly than PUI! And it helps that the set of widgets we have in PUI is limited, and the ‘tricky’ widgets (map, scrolling list, etc) are in the dialogs will will replace with new ones first.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068767/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

This PUI emulation isn't going to use any code from PLIB<ref>https://sourceforge.net/p/flightgear/mailman/message/36985303/</ref>, so what will remain from it in FG afterwards will be the FNT and JS components (reworked).<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068817/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> Florent Rougon </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

=== 2016 ===
We need to explore if Qt Quick or widgets is the better way to go, with a preference towards Qt Quick, since it will allow things closer to current PUI (semi-transparent widgets on top of the 3D content). It still allows creating separate windows too (Erik’s use case), but means we get consistent, custom theming on all platforms, since standard desktop look is not so nice for a flight-sim.

James intention is to make a QML-hosting OSG-drawable, and add this as a concept in Qt-enabled builds, then port some PUI dialogs to it, and see how easy / painful the process is. Hell create some QObjects which expose commands and the property tree and Nasal.

This has the advantage of not touching the OSG window at all, QtQuick simply provides some additional OpenGL rendering on top, which we pass events to - pretty much exactly the same as what we already do for PUI, and hopefully can co-exist with it. James got this working in a local OSG tree in a standalone demo, but that’s based on osgQt - he wants to see if he can make it work on a normal, non-Qt OSG window inside FlightGear.<ref>https://sourceforge.net/p/flightgear/mailman/message/35156051/</ref>

The idea is to host an XML dialog (Currently done with PUI) from Qt also. The question is if that can be done keeping ‘source compatibility’ exactly with the current UI XML and Nasal interface. It probably can be, but many of the PUI widgets have really ugly APIs, especially for combo-boxes, drop-down menus and scrolling lists, where it makes sense to map a Nasal class to a Qt ItemModel, which would be more elegant and easy to work with in both Nasal and integrate on the Qt side. But obviously would mean changing the dialog sources.

Of course, aircraft dialogs tend to be simpler, and not use the more complex PUI widgets, precisely for reasons like this, but that’s a limitation it would be best to remove.<ref>https://sourceforge.net/p/flightgear/mailman/message/35155721/</ref>


== References ==
{{Appendix}}

[[Category:PUI| ]]
[[Category:Rendering roadblocks]]

PUI

2023-04-19T10:08:37Z

Hooray: /* Canvas Emulation */ https://sourceforge.net/p/flightgear/mailman/message/37805060/

{{Feature to be removed|version=2023.3|reason=[[Plib]]/PUI is to be removed and replaced by a [[Canvas widget matrix|Canvas/Nasal based solution]] to help improve compatibility with [[OSG]] 3.6+ and [[OpenGL]] 4.x ([[Core Profile support|OpenGL Core Profile]], see [[2022.X Release plan]] ) and improve performance by [[Unifying the 2D rendering backend via canvas|phasing out legacy OpenGL code]]. Therefore, people should be careful when extending the '''PUI''' based legacy GUI engine<ref>https://sourceforge.net/p/flightgear/mailman/message/34921495/</ref><ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35157325/
|title = <nowiki> Re: [Flightgear-devel] GUI options (Was: Aircraft center) </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jun 14th, 2016
|added = Jun 14th, 2016
|script_version = 0.40
}}</ref> and coordinate any related work with the devel mailing list first-this applies particularly to adding any [[Template:PUI_widget|additional hard-coded PUI widgets]]. }}
[[File:Exit.png|thumb|FlightGear GUI dialog (exit.xml)stored in $FG_ROOT/gui/dialogs]]
{{GUI Navbar}}

[[File:Custom-autopilot-dialog.png|right|200px]]
[[PUI]] is the standard GUI engine used in FlightGear, it is part of [[PLIB]] and is using raw, fixed-pipeline, [[OpenGL]] code internally (no [[OpenSceneGraph]]). As of mid 2021, FlightGear is in the process of working towards adopting the OpenGL Core Profile, this means that [[PUI]] is causing trouble and needs to be replaced/disabled or ported.

PUI provides a fairly basic, but robust, set of widgets. PUI is also used for rendering the [[Menubar]].

FlightGear uses a GUI widget set that is implemented on top of raw (legacy) [[OpenGL]]. This has many advantages from a portability standpoint and from the standpoint of integrating with window systems. [[PUI]] doesn't have every feature under the sun, but it was never meant to. It's relatively small, lean, mean, and written on top of [[OpenGL]] which makes life *much* easier for us.

[[PUI]] already is a separate distinct library within Plib. It depends on some central utility stuff, but that's about it. So it is pretty stripped down and separate already.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg26011.html</ref>

We are to some extent hamstrung by the rather old GUI toolkit we use. However, replacing that is going to be non-trivial, and it would affect not just the core GUI but also all the dialog boxes that have been set up for particular aircraft.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg25985.html</ref>

Flightgear can look amazing when you use the HDR pipeline. We absolutely need this to stay relevant. The problem is that HDR is not compatible with OpenGL1 PUI. Work on getting rid of PUI has been going on for over a decade (longer than it took to implement it).<ref>https://sourceforge.net/p/flightgear/mailman/message/37727346/</ref>

[[File:menubar2.jpg|517px]]

== Replacement status ==
{{See also|FlightGear_and_OpenGL_ES#Example:_disabling_PUI}}

{{Note| Update 09/2022: The PUI replacement [[QtQuick_use_in_FlightGear#Background|was going to be Qt]] but it started to get very complicated with changes in Qt 5.15 + Qt 6, so James is going with a more light-weight Canvas based approach now.

Qt added support for Vulkan / Metal / D3D starting in 5.15, but FlightGear / OpenSceneGraph can’t support those, so integrating the two renderers went from being ‘complicated but ok’ to ‘very very complicated’.

So now James is going with something much more lightweight using some C++ compatibility code, some Nasal for styling and the existing [[Canvas widgets|Canvas widget rendering]] from Thomas Geymayer (TheTom) with some extensions and additions, based on the [[Howto:Processing_legacy_PUI_dialogs_using_Canvas#Original_Discussion|plans originally discussed when the Canvas GUI system was added to FlightGear]]: some pieces are in FlightGear & FGData already.

James has basic dialogs working okay but not the more complex ones and everything looks kind of ugly, he needs to improve the visual look before he shares screenshots to avoid everyone freaking out :) The disadvantage of this approach is James is far from expert at creating visual appearances this way, so it’s kind on unrewarding and slow for him. If someone likes messing with CSS-type styling, border-images and hover-states, ping him since we could probably move things also faster <ref>https://sourceforge.net/p/flightgear/mailman/message/37701750/</ref>}}

=== Motivation ===
{{Main article|Core Profile support}}

The bigger issue here is we need to ditch [[PUI]] (which is in progress) and some OpenGL 1.0 code (HUD, 2D panels especially - can be #ifdef for now) so we can enable Core profile on Mac - since Mac 4.x support (we only hit about 4.3 alas, but with some extensions to get in sight of 4.5) is Core profile only, no Compatability mode.

Improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, many people are convinced PUI needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

While most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so [using Qt5] would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

== Canvas Emulation ==
'''Last updated: 04/2023 <ref>https://sourceforge.net/p/flightgear/mailman/message/37805054/</ref>
'''
=== Status ===
As of 01/2023, the replacement for PUI is making good progress<ref>https://sourceforge.net/p/flightgear/mailman/message/37765706/</ref>.

In February 2022, James reported having something in progress locally, and that should even be something we can try in March/April 2022. Hopefully that’s quick enough, knowing it has been a long time coming.<ref>https://sourceforge.net/p/flightgear/mailman/message/37606439/</ref>

There's now an XML to Nasal bridge, to keep PUI dialogs working (Disabled by a CMake option)
This is implemented on top of the [[Canvas]] system.

This builds equivalent C++ objects to what the [[PUI]] dialogs build, with properties exposed to Nasal.
Peer objects are created by Nasal [[callbacks]], which can implement the various dialog functions needed to keep compatibility, especially the [[#Background|‘update’ and ‘apply’ hooks]].<ref>https://sourceforge.net/p/flightgear/flightgear/ci/cbd5ef9e7b8f433dbc1ba97bae7d7cfc894e7cef/</ref>

Use the following [[Building using CMake|cmake option]] to enable this code: <code>-DENABLE_PUICOMPAT=ON</code>

The new Compatibility files can now be found in $FG_SRC/GUI:

* {{flightgear file|src/GUI/FGPUICompatDialog.cxx }}
* {{flightgear file|src/GUI/FGPUICompatDialog.hxx }}
* {{flightgear file|src/GUI/PUICompatObject.cxx }}

01/2023: James is slowly working on creating the pop-up menu and combo-box widgets [...]

One of the major things slowing down James' work on the popup-menu and combo box is time to restart the simulator for each change, he is looking for some solution to re-load the widget Nasal code independently. <ref><https://sourceforge.net/p/flightgear/mailman/message/37756183/</ref>

James has done about 75% (hah!) of the C++ work to enable live reloading of modules this way, but unfortunately there are some code paths that would become crashy if you use the feature for the Canvas: because it would reference the ‘old’ (pre-reload) Nasal code, and not the new one, and therefore you’d get a weird mix of old and new, and then just crash the sim. To fix it properly I need to track down those places that store a reference to Canvas and give them a re-init method, so we don’t keep the stale references.

The general non-fun-ness of that kind of debugging is James has been making such slow progress on my PUI replacement widgets recently <ref>https://sourceforge.net/p/flightgear/mailman/message/37756263/</ref>

As of 04/2023, remaining items on the todo list are: <ref>https://sourceforge.net/p/flightgear/mailman/message/37805060/</ref>

* Grid layout
* list
* table (and tree ?) models corresponding views
* waypoint list
* log list
* airport-list equivalents
* Nasal access to the menu i18n functions
* selection support for single- and multi-line text (which is being worked on -> CanvasPangoText)

=== Parser ===
{{Main article|pui2canvas}}
The corresponding Nasal/Canvas module to dynamically "translate" legacy PUI/XML dialogs into Canvas dialogs (at runtime), is to be found in {{fgdata file|Nasal/gui/XMLDialog.nas}} <ref>https://sourceforge.net/p/flightgear/fgdata/ci/fe7c87b21a69f88ddb87d89453c48d12b69660e2/</ref>

=== Widgets ===
{{Main article|Howto:Creating a Canvas GUI Widget}}

It’s split between Simgear (see classes with widget / layout in the name) and in FGData. (Eg widgets/Button.nas) To be able to use the existing dialog XML files un-modified (which is a design goal), James is extending the widget types with many additional ones (eg PUI has slider, dial, combo-box, checkbox, all of which need to be created, see [[Canvas widget matrix]].

This is about 30% done and is the bit he's very slow at). Thomas’s canvas widgets have a very good separation of API + state from appearance, so all styling is in its own file, and James is being very strict about maintaining this separation, so we also retain the re-styling feature of the PUI UI, which many people also rely on. This does make the process of adding new widgets more complex, however.

{{See also|Canvas widgets}}

=== Layouting ===
The other thing is to preserve all the layouting: James has added a grid layout to Simgear, since that is supported by the existing PUI code (even though the layouts are not actually part of PUI itself). The problem is getting the sizing / hinting of all the widgets to match the PUI values, so that dialogs look approximately the same under the new UI as they did with PUI; again this a design goal so that all existing dialogs in aircraft and add-ons, which we can’t update, continue to work and be usable. Debugging that is also proving quite tricky, since there’s all kinds of hard-coded assumptions built into PUI widgets about pixels, font-sizes etc which are not true in the new system.<ref>https://sourceforge.net/p/flightgear/mailman/message/37701792/</ref>

== Background ==
In FlightGear, PUI dialogs are standard [[PropertyList XML File]]s that are stored in $FG_ROOT/gui/dialogs, they can contain the widgets mentioned in {{readme file|gui}}, using a simple layout engine discussed in {{readme file|layout}}, and bindings using a combination of so called fgcommands operating on properties (see {{readme file|commands}}) and custom [[Nasal]] (FlightGear scripting) code.

In addition, each PUI/XML dialog may contain Nasal script sections that are executed when opening/closing the dialog, a feature which is commonly used for procedurally creating/updating widgets using the [[Nasal_library#cmdarg.28.29|cmdarg() API]], which allows the dialog tree to be traversed and manipulated prior to the dialog being rendered.
Widgets can be conditionally hidden/shown using a wrapper for [[Conditions|SGCondition]] in [[Nasal_library/props|props.nas]]
The <code>canvas</code> widget also supports its own embedded Nasal code section to execute arbitrary widget specific Nasal code upon opening/closing the dialog/widget.

PUI/XML dialogs can be loaded, dynamically created, updated and closed using a handful of fgcommands:
* {{fgcommand|dialog-new}}
* {{fgcommand|dialog-show}}
* {{fgcommand|dialog-update}}
* {{fgcommand|dialog-apply}}
* {{fgcommand|dialog-close}}

PUI related OpenGL code is particularly infamous for causing rendering artifacts for people on AMD/ATI and Intel hardware (especially in combination with certain fonts/styles and [[Effects|effects]]/[[Shaders|shaders]]), see {{Issue|2213}}.

PUI is also known to affect rendering performance quite significantly (see {{search |keywords=anthrax+gui}}), while also preventing FlightGear from using a more recent version of OpenGL<ref>http://sourceforge.net/p/flightgear/mailman/message/34532040/</ref><ref>http://forum.flightgear.org/viewtopic.php?f=71&t=24046</ref>.

However, improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Besides, while most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

But given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, graphics folks are also convinced it needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

In addition, [[OpenSceneGraph]] (OSG) can obviously not help optimize any PUI related GL code and PUI widgets are generally considered to be pretty archaic and not easy to extend<ref>http://sourceforge.net/p/flightgear/mailman/message/26832164/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587120/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587272/</ref>.

{{Note|We use the GUI code from PLIB, which doesn't know anything about OSG. See the SGPuDrawable class in $FG_SRC/Viewer/renderer.cxx for the implementation. The one catch is that OSG has a strong notion of separation between the update of a "scene" and its rendering, and that might not play well with arbitrary existing OpenGL code. }}

As of late 2015, there is heavy activity towards providing alternatives to a PUI-based UI:
* [[Integrated Web GUI]] (external, browser-based - fully asynchronous)
* [[Howto:Processing legacy PUI dialogs using Canvas]] (internal, using the [[Canvas]] system and a simple [[Nasal]] parser to deal with existing PUI/XML dialogs)

<gallery mode="packed">
Early-Phi-screen shot.PNG|Screenshot showing [[Phi]]
About-dialog-rendered-by-canvas.png|Screenshot showing a dialog rendered by the [[Howto:Processing legacy PUI dialogs using Canvas|pui2canvas parser]]
</gallery>

== History ==
{{Caution|This is merely kept for future reference, many of the ideas discussed below have become obsolete as of 09/2022, if in doubt, please get in touch via devel-list.}}
=== 2021 ===
In early 2021, James did a brief evaluation of [https://github.com/ocornut/imgui ImGUI] as a possibility - he's also evaluating it in some projects at his day job.

The API is interesting if you’re starting from scratch and only exclusively in C++, but it’s not a great fit for how we define GUIs in FG (via [[XML]]/[[Nasal]]): there is no back door that he could find, to access the persistent state of the GUI, or build it up in a data-driven way. So making a mapping to keep our existing GUI XML working (and updating correctly) becomes a bit of a chore.<ref>https://sourceforge.net/p/flightgear/mailman/message/37295586/</ref>

Pretty much all of the FlightGear GUI is defined in XML space, except for a few oddments. Let’s say 95% at this point.

Additionally, even if we were to change that for the core sim (and James' current plan is to keep the XML syntax and just extend it), the installed base of '''aircraft''' ship their own XML dialogs (eg., replacing the autopilot dialog with a custom one, or just adding their own aircraft-specific helper controls for doors / lights / cargo / whatever). So even if we found the most sublimely beautiful, intuitive, compact GUI description language in the world, we have to keep the XML syntax working as-is, for the foreseeable future.

Given this, James' intention is to replace the output side [[PUI]] but keep the front-end side (XML / properties / bindings) unchanged, and therefore backwards compatible, and simply add some new types / options / widget types going forward. This will mean we still have to deal with the slightly cumbersome XML+Nasal syntax, but, well, it’s not *that* cumbersome. <ref>https://sourceforge.net/p/flightgear/mailman/message/37296280/</ref>

In mid 2021, James reported that he is working on some ‘PUICompat’ classes which hold/own/represent the GUI state in C++, but which can be used with [[Nasal/CppBind|Nasal CppBind]]. And of course we could indeed expose those later on. <ref>https://sourceforge.net/p/flightgear/mailman/message/37297727/</ref>

In July 2021, James suggested not to worry about the existing GUI code, it’s going in the bin.<ref>https://sourceforge.net/p/flightgear/mailman/message/37325905/</ref>

For the time being, the in-sim GUi can’t do Unicode yet, but James is working on it, hopefully available soon.<ref>https://sourceforge.net/p/flightgear/mailman/message/37328200/</ref>
Also, the in-sim menubar will change with the new GUI, *and* we use a native menubar on macOS. Until James replaces the PUI fonts we can’t use Unicode symbols. So, will have to come back to it once the new GUI is merged.<ref>https://sourceforge.net/p/flightgear/mailman/message/37327237/</ref>

=== 2020 ===
As of 03/2020, the PLIB replacement was reported to be in the backlog <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36951255/
|title = <nowiki>Re: [Flightgear-devel] C++ and/or OSG question </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Mar 18th, 2020
|added = Mar 18th, 2020
|script_version = 0.50
}}</ref>.

With PLIB replacement work likely being re-scheduled for [[Post FlightGear 2020.2 LTS changes]] <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36985375/
|title = <nowiki>Re: [Flightgear-devel] Working Group Proposal - Boost and PLIB replacement - Delegation and Teamwork </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = April 18th, 2020
|added = April 18th, 2020
|script_version = 1.10
}}</ref>.

In 08/2020, James stated that he was still working (exceptionally slowly!) on replacing PUI (as part of removing legacy OpenGL code (PUI, HUD, 2d panels, porting Canvas away form ShivaVG), so we can switch to Vulkan/VSG at some point (ideally at some point before Apple turn off OpenGL support…)), and that he doesn't think /any/ of us *want* to be working on these features particularly, but projects like these need to be done before anyone can have fun with VSG or Vulkan (personally James would be very enthusiastic about working on VSG support (being on macOS, I also have the most to lose / gain from it)). Sometimes that’s just how it goes. Equally they will all benefit the project ultimately, but the payoff both for the individual and the project is very drawn out. <ref>https://sourceforge.net/p/flightgear/mailman/message/37077158/</ref>

In 10/2020, the estimation is that PUI should be going away really ‘soon’, the replacement code is already in next / 2020.2. (There’s no plan to actually /use/ the new UI code in 2020.2, but if the bugs in it prove simple, we could actually turn it for specific dialog: it seems very unlikely this makes sense for a stable release however)<ref>https://sourceforge.net/p/flightgear/mailman/message/37123818/</ref>

The fixed-function removal, is actively in hand (Gaetan is working on the 2D panel part, and James is going to focus on PUI in the rest of 2020). James hopes that means next year he can focus on Vulkan, or at least, using OSG as if /were/ VSG, so the migration in a year or two when VSG is stable, is not so painful.<ref>https://sourceforge.net/p/flightgear/mailman/message/37129098/</ref>

The PUI UI and replacement can co-exist in the same build (they already do, effectively.<ref>https://sourceforge.net/p/flightgear/mailman/message/37131297/</ref>

In 11/2020, James suggested not to worry about details such as PUI styling/theming etc: we’re not making such changes for the LTS, and PUI should be gone before the next release.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142225/</ref> Also, he recommended (to everyone) to stop touching GUI stuff for a few weeks, as he's about to turn it all on its head.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142356/</ref>

=== 2019 ===
The new GUI has been incubating for a few years, but there's apparently been a lot of progress as of 10/2019.

It is likely the new GUI will be a user opt-in feature - at least initially. The sunset of the PLIB library _could_ happen relatively soon, but
people will need to see the new GUI and react to it before we could commit to PLIB removal <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36784489/
|title = <nowiki>Re: [Flightgear-devel] in Flightgear/Simgear C++ Code: What needs Doing? What are YOU Doing? What would you do if you had the time? </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Oct 14th, 2019
|added = Oct 14th, 2019
|script_version = 0.50
}}</ref>.

In 02/2019, James stated that the new UI is coming quite soon. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36589420/
|title = <nowiki> Re: [Flightgear-devel] Lagging </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Feb 17th, 2019
|added = Feb 17th, 2019
|script_version = 0.40
}}</ref>

=== 2018 ===
{{See also|QtQuick use in FlightGear}}

According to James, we have to accept that changes like testing or making [[PUI]] a modular thing or moving the JS code tend to have an immediate pain for some people (because strange stuff gets broken, and takes some time to get fixed), whereas the payoff in terms of improved joystick handling or replacing the UI or testing of all subsystems will take some months or years to be felt.<ref>https://sourceforge.net/p/flightgear/mailman/message/36323240/</ref>

James said he was in the middle of porting the launcher’s final tab (location) to the new UI scheme, once that’s done he will start sketching out the ‘in sim’ settings UI using the same pieces. He’ll send a request for contributions around about that in the next three-four weeks, once he has enough templates & examples that there is a clear pattern to follow.<ref>https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/2d10f16c-ddc8-07f3-07e7-eca2a0a0d55f%40zaretto.com/#msg36293586</ref>

James announced that the launcher is now feature complete with the QtQuick UI, he’ll keep making bug-fixes of course as people report them, but my todo list for the core features is now done<ref>https://sourceforge.net/p/flightgear/mailman/message/36355833/</ref>.

=== 2017 ===

In 10/2017, James said he was getting really close to having the PUI replacement UI suitable for beta-testing.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36067646/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 7th, 2017
|added = Oct 7th, 2017
|script_version = 0.40
}}</ref>

Originally, James was hoping to land the PUI replacement GUI in the last dev cycle in 2017 (at least as a proof-of-concept, probably not as the default UI), so wouldn’t expend lots of effort on things like collapsible sections which might be a lot of work with the current PUI/Canvas approaches, but are trivial with the new [[QtQuick use in FlightGear|QtQuick based UI scheme]].<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36059822/
|title = <nowiki> Re: [Flightgear-devel] Canvas MapLayer for OpenStreetMap, OpenAIP,
VFR Sectionals </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 1st, 2017
|added = Oct 1st, 2017
|script_version = 0.40
}}</ref>

Once the basic new UI is in place we can experiment with different re-arrangements easily, without being limited by PUI. (James expects PUI to live on as the default / alternate UI while this happens)<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36061229/
|title = <nowiki> Re: [Flightgear-devel] FGFS macOS Menubar </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 2nd, 2017
|added = Oct 2nd, 2017
|script_version = 0.40
}}</ref>

Technically, this entails replacing dialog.cxx with some code which builds up some special ‘PUI-Emulation’ QtQuick controls, so that existing dialogs (especially from Aircraft) continue to work. This mode will look somewhat ugly but hopefully no more ugly than PUI! And it helps that the set of widgets we have in PUI is limited, and the ‘tricky’ widgets (map, scrolling list, etc) are in the dialogs will will replace with new ones first.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068767/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

This PUI emulation isn't going to use any code from PLIB<ref>https://sourceforge.net/p/flightgear/mailman/message/36985303/</ref>, so what will remain from it in FG afterwards will be the FNT and JS components (reworked).<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068817/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> Florent Rougon </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

=== 2016 ===
We need to explore if Qt Quick or widgets is the better way to go, with a preference towards Qt Quick, since it will allow things closer to current PUI (semi-transparent widgets on top of the 3D content). It still allows creating separate windows too (Erik’s use case), but means we get consistent, custom theming on all platforms, since standard desktop look is not so nice for a flight-sim.

James intention is to make a QML-hosting OSG-drawable, and add this as a concept in Qt-enabled builds, then port some PUI dialogs to it, and see how easy / painful the process is. Hell create some QObjects which expose commands and the property tree and Nasal.

This has the advantage of not touching the OSG window at all, QtQuick simply provides some additional OpenGL rendering on top, which we pass events to - pretty much exactly the same as what we already do for PUI, and hopefully can co-exist with it. James got this working in a local OSG tree in a standalone demo, but that’s based on osgQt - he wants to see if he can make it work on a normal, non-Qt OSG window inside FlightGear.<ref>https://sourceforge.net/p/flightgear/mailman/message/35156051/</ref>

The idea is to host an XML dialog (Currently done with PUI) from Qt also. The question is if that can be done keeping ‘source compatibility’ exactly with the current UI XML and Nasal interface. It probably can be, but many of the PUI widgets have really ugly APIs, especially for combo-boxes, drop-down menus and scrolling lists, where it makes sense to map a Nasal class to a Qt ItemModel, which would be more elegant and easy to work with in both Nasal and integrate on the Qt side. But obviously would mean changing the dialog sources.

Of course, aircraft dialogs tend to be simpler, and not use the more complex PUI widgets, precisely for reasons like this, but that’s a limitation it would be best to remove.<ref>https://sourceforge.net/p/flightgear/mailman/message/35155721/</ref>


== References ==
{{Appendix}}

[[Category:PUI| ]]
[[Category:Rendering roadblocks]]

PUI

2023-04-19T10:06:33Z

Hooray: /* Status */ https://sourceforge.net/p/flightgear/mailman/message/37805054/

{{Feature to be removed|version=2023.3|reason=[[Plib]]/PUI is to be removed and replaced by a [[Canvas widget matrix|Canvas/Nasal based solution]] to help improve compatibility with [[OSG]] 3.6+ and [[OpenGL]] 4.x ([[Core Profile support|OpenGL Core Profile]], see [[2022.X Release plan]] ) and improve performance by [[Unifying the 2D rendering backend via canvas|phasing out legacy OpenGL code]]. Therefore, people should be careful when extending the '''PUI''' based legacy GUI engine<ref>https://sourceforge.net/p/flightgear/mailman/message/34921495/</ref><ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35157325/
|title = <nowiki> Re: [Flightgear-devel] GUI options (Was: Aircraft center) </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jun 14th, 2016
|added = Jun 14th, 2016
|script_version = 0.40
}}</ref> and coordinate any related work with the devel mailing list first-this applies particularly to adding any [[Template:PUI_widget|additional hard-coded PUI widgets]]. }}
[[File:Exit.png|thumb|FlightGear GUI dialog (exit.xml)stored in $FG_ROOT/gui/dialogs]]
{{GUI Navbar}}

[[File:Custom-autopilot-dialog.png|right|200px]]
[[PUI]] is the standard GUI engine used in FlightGear, it is part of [[PLIB]] and is using raw, fixed-pipeline, [[OpenGL]] code internally (no [[OpenSceneGraph]]). As of mid 2021, FlightGear is in the process of working towards adopting the OpenGL Core Profile, this means that [[PUI]] is causing trouble and needs to be replaced/disabled or ported.

PUI provides a fairly basic, but robust, set of widgets. PUI is also used for rendering the [[Menubar]].

FlightGear uses a GUI widget set that is implemented on top of raw (legacy) [[OpenGL]]. This has many advantages from a portability standpoint and from the standpoint of integrating with window systems. [[PUI]] doesn't have every feature under the sun, but it was never meant to. It's relatively small, lean, mean, and written on top of [[OpenGL]] which makes life *much* easier for us.

[[PUI]] already is a separate distinct library within Plib. It depends on some central utility stuff, but that's about it. So it is pretty stripped down and separate already.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg26011.html</ref>

We are to some extent hamstrung by the rather old GUI toolkit we use. However, replacing that is going to be non-trivial, and it would affect not just the core GUI but also all the dialog boxes that have been set up for particular aircraft.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg25985.html</ref>

Flightgear can look amazing when you use the HDR pipeline. We absolutely need this to stay relevant. The problem is that HDR is not compatible with OpenGL1 PUI. Work on getting rid of PUI has been going on for over a decade (longer than it took to implement it).<ref>https://sourceforge.net/p/flightgear/mailman/message/37727346/</ref>

[[File:menubar2.jpg|517px]]

== Replacement status ==
{{See also|FlightGear_and_OpenGL_ES#Example:_disabling_PUI}}

{{Note| Update 09/2022: The PUI replacement [[QtQuick_use_in_FlightGear#Background|was going to be Qt]] but it started to get very complicated with changes in Qt 5.15 + Qt 6, so James is going with a more light-weight Canvas based approach now.

Qt added support for Vulkan / Metal / D3D starting in 5.15, but FlightGear / OpenSceneGraph can’t support those, so integrating the two renderers went from being ‘complicated but ok’ to ‘very very complicated’.

So now James is going with something much more lightweight using some C++ compatibility code, some Nasal for styling and the existing [[Canvas widgets|Canvas widget rendering]] from Thomas Geymayer (TheTom) with some extensions and additions, based on the [[Howto:Processing_legacy_PUI_dialogs_using_Canvas#Original_Discussion|plans originally discussed when the Canvas GUI system was added to FlightGear]]: some pieces are in FlightGear & FGData already.

James has basic dialogs working okay but not the more complex ones and everything looks kind of ugly, he needs to improve the visual look before he shares screenshots to avoid everyone freaking out :) The disadvantage of this approach is James is far from expert at creating visual appearances this way, so it’s kind on unrewarding and slow for him. If someone likes messing with CSS-type styling, border-images and hover-states, ping him since we could probably move things also faster <ref>https://sourceforge.net/p/flightgear/mailman/message/37701750/</ref>}}

=== Motivation ===
{{Main article|Core Profile support}}

The bigger issue here is we need to ditch [[PUI]] (which is in progress) and some OpenGL 1.0 code (HUD, 2D panels especially - can be #ifdef for now) so we can enable Core profile on Mac - since Mac 4.x support (we only hit about 4.3 alas, but with some extensions to get in sight of 4.5) is Core profile only, no Compatability mode.

Improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, many people are convinced PUI needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

While most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so [using Qt5] would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

== Canvas Emulation ==
'''Last updated: 04/2023 <ref>https://sourceforge.net/p/flightgear/mailman/message/37805054/</ref>
'''
=== Status ===
As of 01/2023, the replacement for PUI is making good progress<ref>https://sourceforge.net/p/flightgear/mailman/message/37765706/</ref>.

In February 2022, James reported having something in progress locally, and that should even be something we can try in March/April 2022. Hopefully that’s quick enough, knowing it has been a long time coming.<ref>https://sourceforge.net/p/flightgear/mailman/message/37606439/</ref>

There's now an XML to Nasal bridge, to keep PUI dialogs working (Disabled by a CMake option)
This is implemented on top of the [[Canvas]] system.

This builds equivalent C++ objects to what the [[PUI]] dialogs build, with properties exposed to Nasal.
Peer objects are created by Nasal [[callbacks]], which can implement the various dialog functions needed to keep compatibility, especially the [[#Background|‘update’ and ‘apply’ hooks]].<ref>https://sourceforge.net/p/flightgear/flightgear/ci/cbd5ef9e7b8f433dbc1ba97bae7d7cfc894e7cef/</ref>

Use the following [[Building using CMake|cmake option]] to enable this code: <code>-DENABLE_PUICOMPAT=ON</code>

The new Compatibility files can now be found in $FG_SRC/GUI:

* {{flightgear file|src/GUI/FGPUICompatDialog.cxx }}
* {{flightgear file|src/GUI/FGPUICompatDialog.hxx }}
* {{flightgear file|src/GUI/PUICompatObject.cxx }}

01/2023: James is slowly working on creating the pop-up menu and combo-box widgets [...]

One of the major things slowing down James' work on the popup-menu and combo box is time to restart the simulator for each change, he is looking for some solution to re-load the widget Nasal code independently. <ref><https://sourceforge.net/p/flightgear/mailman/message/37756183/</ref>

James has done about 75% (hah!) of the C++ work to enable live reloading of modules this way, but unfortunately there are some code paths that would become crashy if you use the feature for the Canvas: because it would reference the ‘old’ (pre-reload) Nasal code, and not the new one, and therefore you’d get a weird mix of old and new, and then just crash the sim. To fix it properly I need to track down those places that store a reference to Canvas and give them a re-init method, so we don’t keep the stale references.

The general non-fun-ness of that kind of debugging is why I’ve been making such slow progress on my PUI replacement widgets recently <ref>https://sourceforge.net/p/flightgear/mailman/message/37756263/</ref>

=== Parser ===
{{Main article|pui2canvas}}
The corresponding Nasal/Canvas module to dynamically "translate" legacy PUI/XML dialogs into Canvas dialogs (at runtime), is to be found in {{fgdata file|Nasal/gui/XMLDialog.nas}} <ref>https://sourceforge.net/p/flightgear/fgdata/ci/fe7c87b21a69f88ddb87d89453c48d12b69660e2/</ref>

=== Widgets ===
{{Main article|Howto:Creating a Canvas GUI Widget}}

It’s split between Simgear (see classes with widget / layout in the name) and in FGData. (Eg widgets/Button.nas) To be able to use the existing dialog XML files un-modified (which is a design goal), James is extending the widget types with many additional ones (eg PUI has slider, dial, combo-box, checkbox, all of which need to be created, see [[Canvas widget matrix]].

This is about 30% done and is the bit he's very slow at). Thomas’s canvas widgets have a very good separation of API + state from appearance, so all styling is in its own file, and James is being very strict about maintaining this separation, so we also retain the re-styling feature of the PUI UI, which many people also rely on. This does make the process of adding new widgets more complex, however.

{{See also|Canvas widgets}}

=== Layouting ===
The other thing is to preserve all the layouting: James has added a grid layout to Simgear, since that is supported by the existing PUI code (even though the layouts are not actually part of PUI itself). The problem is getting the sizing / hinting of all the widgets to match the PUI values, so that dialogs look approximately the same under the new UI as they did with PUI; again this a design goal so that all existing dialogs in aircraft and add-ons, which we can’t update, continue to work and be usable. Debugging that is also proving quite tricky, since there’s all kinds of hard-coded assumptions built into PUI widgets about pixels, font-sizes etc which are not true in the new system.<ref>https://sourceforge.net/p/flightgear/mailman/message/37701792/</ref>

== Background ==
In FlightGear, PUI dialogs are standard [[PropertyList XML File]]s that are stored in $FG_ROOT/gui/dialogs, they can contain the widgets mentioned in {{readme file|gui}}, using a simple layout engine discussed in {{readme file|layout}}, and bindings using a combination of so called fgcommands operating on properties (see {{readme file|commands}}) and custom [[Nasal]] (FlightGear scripting) code.

In addition, each PUI/XML dialog may contain Nasal script sections that are executed when opening/closing the dialog, a feature which is commonly used for procedurally creating/updating widgets using the [[Nasal_library#cmdarg.28.29|cmdarg() API]], which allows the dialog tree to be traversed and manipulated prior to the dialog being rendered.
Widgets can be conditionally hidden/shown using a wrapper for [[Conditions|SGCondition]] in [[Nasal_library/props|props.nas]]
The <code>canvas</code> widget also supports its own embedded Nasal code section to execute arbitrary widget specific Nasal code upon opening/closing the dialog/widget.

PUI/XML dialogs can be loaded, dynamically created, updated and closed using a handful of fgcommands:
* {{fgcommand|dialog-new}}
* {{fgcommand|dialog-show}}
* {{fgcommand|dialog-update}}
* {{fgcommand|dialog-apply}}
* {{fgcommand|dialog-close}}

PUI related OpenGL code is particularly infamous for causing rendering artifacts for people on AMD/ATI and Intel hardware (especially in combination with certain fonts/styles and [[Effects|effects]]/[[Shaders|shaders]]), see {{Issue|2213}}.

PUI is also known to affect rendering performance quite significantly (see {{search |keywords=anthrax+gui}}), while also preventing FlightGear from using a more recent version of OpenGL<ref>http://sourceforge.net/p/flightgear/mailman/message/34532040/</ref><ref>http://forum.flightgear.org/viewtopic.php?f=71&t=24046</ref>.

However, improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Besides, while most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

But given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, graphics folks are also convinced it needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

In addition, [[OpenSceneGraph]] (OSG) can obviously not help optimize any PUI related GL code and PUI widgets are generally considered to be pretty archaic and not easy to extend<ref>http://sourceforge.net/p/flightgear/mailman/message/26832164/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587120/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587272/</ref>.

{{Note|We use the GUI code from PLIB, which doesn't know anything about OSG. See the SGPuDrawable class in $FG_SRC/Viewer/renderer.cxx for the implementation. The one catch is that OSG has a strong notion of separation between the update of a "scene" and its rendering, and that might not play well with arbitrary existing OpenGL code. }}

As of late 2015, there is heavy activity towards providing alternatives to a PUI-based UI:
* [[Integrated Web GUI]] (external, browser-based - fully asynchronous)
* [[Howto:Processing legacy PUI dialogs using Canvas]] (internal, using the [[Canvas]] system and a simple [[Nasal]] parser to deal with existing PUI/XML dialogs)

<gallery mode="packed">
Early-Phi-screen shot.PNG|Screenshot showing [[Phi]]
About-dialog-rendered-by-canvas.png|Screenshot showing a dialog rendered by the [[Howto:Processing legacy PUI dialogs using Canvas|pui2canvas parser]]
</gallery>

== History ==
{{Caution|This is merely kept for future reference, many of the ideas discussed below have become obsolete as of 09/2022, if in doubt, please get in touch via devel-list.}}
=== 2021 ===
In early 2021, James did a brief evaluation of [https://github.com/ocornut/imgui ImGUI] as a possibility - he's also evaluating it in some projects at his day job.

The API is interesting if you’re starting from scratch and only exclusively in C++, but it’s not a great fit for how we define GUIs in FG (via [[XML]]/[[Nasal]]): there is no back door that he could find, to access the persistent state of the GUI, or build it up in a data-driven way. So making a mapping to keep our existing GUI XML working (and updating correctly) becomes a bit of a chore.<ref>https://sourceforge.net/p/flightgear/mailman/message/37295586/</ref>

Pretty much all of the FlightGear GUI is defined in XML space, except for a few oddments. Let’s say 95% at this point.

Additionally, even if we were to change that for the core sim (and James' current plan is to keep the XML syntax and just extend it), the installed base of '''aircraft''' ship their own XML dialogs (eg., replacing the autopilot dialog with a custom one, or just adding their own aircraft-specific helper controls for doors / lights / cargo / whatever). So even if we found the most sublimely beautiful, intuitive, compact GUI description language in the world, we have to keep the XML syntax working as-is, for the foreseeable future.

Given this, James' intention is to replace the output side [[PUI]] but keep the front-end side (XML / properties / bindings) unchanged, and therefore backwards compatible, and simply add some new types / options / widget types going forward. This will mean we still have to deal with the slightly cumbersome XML+Nasal syntax, but, well, it’s not *that* cumbersome. <ref>https://sourceforge.net/p/flightgear/mailman/message/37296280/</ref>

In mid 2021, James reported that he is working on some ‘PUICompat’ classes which hold/own/represent the GUI state in C++, but which can be used with [[Nasal/CppBind|Nasal CppBind]]. And of course we could indeed expose those later on. <ref>https://sourceforge.net/p/flightgear/mailman/message/37297727/</ref>

In July 2021, James suggested not to worry about the existing GUI code, it’s going in the bin.<ref>https://sourceforge.net/p/flightgear/mailman/message/37325905/</ref>

For the time being, the in-sim GUi can’t do Unicode yet, but James is working on it, hopefully available soon.<ref>https://sourceforge.net/p/flightgear/mailman/message/37328200/</ref>
Also, the in-sim menubar will change with the new GUI, *and* we use a native menubar on macOS. Until James replaces the PUI fonts we can’t use Unicode symbols. So, will have to come back to it once the new GUI is merged.<ref>https://sourceforge.net/p/flightgear/mailman/message/37327237/</ref>

=== 2020 ===
As of 03/2020, the PLIB replacement was reported to be in the backlog <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36951255/
|title = <nowiki>Re: [Flightgear-devel] C++ and/or OSG question </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Mar 18th, 2020
|added = Mar 18th, 2020
|script_version = 0.50
}}</ref>.

With PLIB replacement work likely being re-scheduled for [[Post FlightGear 2020.2 LTS changes]] <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36985375/
|title = <nowiki>Re: [Flightgear-devel] Working Group Proposal - Boost and PLIB replacement - Delegation and Teamwork </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = April 18th, 2020
|added = April 18th, 2020
|script_version = 1.10
}}</ref>.

In 08/2020, James stated that he was still working (exceptionally slowly!) on replacing PUI (as part of removing legacy OpenGL code (PUI, HUD, 2d panels, porting Canvas away form ShivaVG), so we can switch to Vulkan/VSG at some point (ideally at some point before Apple turn off OpenGL support…)), and that he doesn't think /any/ of us *want* to be working on these features particularly, but projects like these need to be done before anyone can have fun with VSG or Vulkan (personally James would be very enthusiastic about working on VSG support (being on macOS, I also have the most to lose / gain from it)). Sometimes that’s just how it goes. Equally they will all benefit the project ultimately, but the payoff both for the individual and the project is very drawn out. <ref>https://sourceforge.net/p/flightgear/mailman/message/37077158/</ref>

In 10/2020, the estimation is that PUI should be going away really ‘soon’, the replacement code is already in next / 2020.2. (There’s no plan to actually /use/ the new UI code in 2020.2, but if the bugs in it prove simple, we could actually turn it for specific dialog: it seems very unlikely this makes sense for a stable release however)<ref>https://sourceforge.net/p/flightgear/mailman/message/37123818/</ref>

The fixed-function removal, is actively in hand (Gaetan is working on the 2D panel part, and James is going to focus on PUI in the rest of 2020). James hopes that means next year he can focus on Vulkan, or at least, using OSG as if /were/ VSG, so the migration in a year or two when VSG is stable, is not so painful.<ref>https://sourceforge.net/p/flightgear/mailman/message/37129098/</ref>

The PUI UI and replacement can co-exist in the same build (they already do, effectively.<ref>https://sourceforge.net/p/flightgear/mailman/message/37131297/</ref>

In 11/2020, James suggested not to worry about details such as PUI styling/theming etc: we’re not making such changes for the LTS, and PUI should be gone before the next release.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142225/</ref> Also, he recommended (to everyone) to stop touching GUI stuff for a few weeks, as he's about to turn it all on its head.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142356/</ref>

=== 2019 ===
The new GUI has been incubating for a few years, but there's apparently been a lot of progress as of 10/2019.

It is likely the new GUI will be a user opt-in feature - at least initially. The sunset of the PLIB library _could_ happen relatively soon, but
people will need to see the new GUI and react to it before we could commit to PLIB removal <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36784489/
|title = <nowiki>Re: [Flightgear-devel] in Flightgear/Simgear C++ Code: What needs Doing? What are YOU Doing? What would you do if you had the time? </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Oct 14th, 2019
|added = Oct 14th, 2019
|script_version = 0.50
}}</ref>.

In 02/2019, James stated that the new UI is coming quite soon. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36589420/
|title = <nowiki> Re: [Flightgear-devel] Lagging </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Feb 17th, 2019
|added = Feb 17th, 2019
|script_version = 0.40
}}</ref>

=== 2018 ===
{{See also|QtQuick use in FlightGear}}

According to James, we have to accept that changes like testing or making [[PUI]] a modular thing or moving the JS code tend to have an immediate pain for some people (because strange stuff gets broken, and takes some time to get fixed), whereas the payoff in terms of improved joystick handling or replacing the UI or testing of all subsystems will take some months or years to be felt.<ref>https://sourceforge.net/p/flightgear/mailman/message/36323240/</ref>

James said he was in the middle of porting the launcher’s final tab (location) to the new UI scheme, once that’s done he will start sketching out the ‘in sim’ settings UI using the same pieces. He’ll send a request for contributions around about that in the next three-four weeks, once he has enough templates & examples that there is a clear pattern to follow.<ref>https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/2d10f16c-ddc8-07f3-07e7-eca2a0a0d55f%40zaretto.com/#msg36293586</ref>

James announced that the launcher is now feature complete with the QtQuick UI, he’ll keep making bug-fixes of course as people report them, but my todo list for the core features is now done<ref>https://sourceforge.net/p/flightgear/mailman/message/36355833/</ref>.

=== 2017 ===

In 10/2017, James said he was getting really close to having the PUI replacement UI suitable for beta-testing.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36067646/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 7th, 2017
|added = Oct 7th, 2017
|script_version = 0.40
}}</ref>

Originally, James was hoping to land the PUI replacement GUI in the last dev cycle in 2017 (at least as a proof-of-concept, probably not as the default UI), so wouldn’t expend lots of effort on things like collapsible sections which might be a lot of work with the current PUI/Canvas approaches, but are trivial with the new [[QtQuick use in FlightGear|QtQuick based UI scheme]].<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36059822/
|title = <nowiki> Re: [Flightgear-devel] Canvas MapLayer for OpenStreetMap, OpenAIP,
VFR Sectionals </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 1st, 2017
|added = Oct 1st, 2017
|script_version = 0.40
}}</ref>

Once the basic new UI is in place we can experiment with different re-arrangements easily, without being limited by PUI. (James expects PUI to live on as the default / alternate UI while this happens)<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36061229/
|title = <nowiki> Re: [Flightgear-devel] FGFS macOS Menubar </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 2nd, 2017
|added = Oct 2nd, 2017
|script_version = 0.40
}}</ref>

Technically, this entails replacing dialog.cxx with some code which builds up some special ‘PUI-Emulation’ QtQuick controls, so that existing dialogs (especially from Aircraft) continue to work. This mode will look somewhat ugly but hopefully no more ugly than PUI! And it helps that the set of widgets we have in PUI is limited, and the ‘tricky’ widgets (map, scrolling list, etc) are in the dialogs will will replace with new ones first.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068767/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

This PUI emulation isn't going to use any code from PLIB<ref>https://sourceforge.net/p/flightgear/mailman/message/36985303/</ref>, so what will remain from it in FG afterwards will be the FNT and JS components (reworked).<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068817/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> Florent Rougon </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

=== 2016 ===
We need to explore if Qt Quick or widgets is the better way to go, with a preference towards Qt Quick, since it will allow things closer to current PUI (semi-transparent widgets on top of the 3D content). It still allows creating separate windows too (Erik’s use case), but means we get consistent, custom theming on all platforms, since standard desktop look is not so nice for a flight-sim.

James intention is to make a QML-hosting OSG-drawable, and add this as a concept in Qt-enabled builds, then port some PUI dialogs to it, and see how easy / painful the process is. Hell create some QObjects which expose commands and the property tree and Nasal.

This has the advantage of not touching the OSG window at all, QtQuick simply provides some additional OpenGL rendering on top, which we pass events to - pretty much exactly the same as what we already do for PUI, and hopefully can co-exist with it. James got this working in a local OSG tree in a standalone demo, but that’s based on osgQt - he wants to see if he can make it work on a normal, non-Qt OSG window inside FlightGear.<ref>https://sourceforge.net/p/flightgear/mailman/message/35156051/</ref>

The idea is to host an XML dialog (Currently done with PUI) from Qt also. The question is if that can be done keeping ‘source compatibility’ exactly with the current UI XML and Nasal interface. It probably can be, but many of the PUI widgets have really ugly APIs, especially for combo-boxes, drop-down menus and scrolling lists, where it makes sense to map a Nasal class to a Qt ItemModel, which would be more elegant and easy to work with in both Nasal and integrate on the Qt side. But obviously would mean changing the dialog sources.

Of course, aircraft dialogs tend to be simpler, and not use the more complex PUI widgets, precisely for reasons like this, but that’s a limitation it would be best to remove.<ref>https://sourceforge.net/p/flightgear/mailman/message/35155721/</ref>


== References ==
{{Appendix}}

[[Category:PUI| ]]
[[Category:Rendering roadblocks]]

Shiva Alternatives

2023-04-16T15:12:05Z

Hooray: /* Status */ https://sourceforge.net/p/flightgear/mailman/message/37804095/

{{Main article|Unifying the 2D rendering backend via canvas}}

{{Stub}}

{{forum|71|Canvas}}

{{infobox subsystem
|image = Anniversary4.png
|name = Canvas.Path port using shaders (deprecating Shiva)
|started = 02/2022 (Available on next)
|description = Canvas.Path being ported for [[Core Profile support]]
|status = Experimental (in the process of being integrated)
|developers = Erik, Scott, Fahim, Stuart, James (see references below)
|changelog = see commit {{Simgear commit|6451e505d8549f7d1e4bb440189559448f6aea5a|text=Add ShaderVG, a shader based version of ShivaVG}}

}}

To support [[Canvas]] on [[OpenGL]] [[FlightGear and OpenGL ES|Core profile]], the plan is to migrate the [[Canvas Path]] backend from [[Shiva]] to ‘something else’ which implements the required drawing operations. Unfortunately two of the probable solutions (Skia from Chrome and Cairo from Gtk) are both enormous and a pain to deploy on macOS and Windows.

The issue is mostly how the different libraries handle clipping. The problem is that for a non-rotated (or strictly, a 90-degree rotated) rectangular clip, you can use glSicssor to clip, which is ‘free’. For arbitrary shaped clips, or where the clip is transformed in some awkward way, the options are

# stencils (which I think is what ‘old’ Shiva uses)
# intermediate framebuffers
# geometric clipping but that’s a royal pain in the ass to combine with gradients / dash patterns

BTW this is why you should be super careful about using clips in a canvas: rectangular ones which are only translated / scaled are very efficient (due to glSicssor), but anything else can bite hard, especially on systems where the chosen solution (again, eg stencils) is not a common/fast path.<ref>https://sourceforge.net/p/flightgear/mailman/message/37610707/</ref>

There is the separate issue of Canvas being a little slow for some people, but that’s a separate task which we need to work on, and will change when we switch from Shiva to something more modern (as of 03/2023, [[#ShaderVG]] seems like the most likely candidate, for details see below). <ref>https://sourceforge.net/p/flightgear/mailman/message/37608469/</ref>

At the moment there are 4 version of ShivaVG/ShaderVG in SimGear.

In next there is the ancient version of ShivaVG (probably OpenGL
compatibility profile) and ShaderVG which is based on the ancient
version of ShivaVG but adds shaders for rendering paths and color maps.

In the topics/shivavg_update branch there is an updated version of
ShivaVG which requires OpenGL2.1 (and therefore I think leaves the
OpenGL compatibility profile behind) and a version of ShaderVG where the
changes between ShivaVG and ShaderVG have been applied on top of the new
ShivaVG.

For the time being, the first thing to check, maybe, is to see whether the version of
ShivaVG in the topics/shivavg_update branch is enough to get the core
profile working. I suspect it might.<ref>https://sourceforge.net/p/flightgear/mailman/message/37803242/</ref>

== Status ==
[[File:Canvas-shadervg-testpattern.png|thumb|Screen shot showing Erik's new test-pattern dialog, created as part of the effort to adapt Canvas Path in order to port it to a shader based approach using ShaderVG]]
* April 15th, 2023, Scott is hoping to investigate remaining issues <ref>https://sourceforge.net/p/flightgear/mailman/message/37803388/</ref> He took a closer look at the latest ShivaVG and confirmed that it is compatibility profile, not core profile. He also thinks, it's best to discard this as a viable option based on our goals toward core profile and Scott said, he'll start to explore ShaderVG, which he believes is a good path forward.<ref>https://sourceforge.net/p/flightgear/mailman/message/37804095/</ref>
* April 13th, 2023: the non-shader code paths are now working correctly, but as soon as one or both of the shaders are used things get whacky,and I suspect it has something to do with what used to be the ModelView matrix which don't match between OpenSceneGraph and the shaders. <ref>https://sourceforge.net/p/flightgear/mailman/message/37803242/</ref>
* March 8th, 2023: Erik seems to have got basic ShaderVG integration working with few remaining issues <ref>https://sourceforge.net/p/flightgear/mailman/message/37787634/</ref> {{Fgdata commit|61664836a45d7ea2757916b51f02adb4bb45ab77}}
* March 4th, 2023: Erik started adding custom shaders to FG for ShaderVG
* Feb 17th, 2022: Erik added ShaderVG to SimGear on next including a corresponding cmake build option

== Testing ==
{{Caution|any changes we make to Canvas rendering, need to be strict about compatibility: at least to pixel level, ideally even sub-pixel (but sub-pixel might be hard to achieve). Therefore we should really understand any differences, before touching any aircraft, and for sure check the FG-1000, the A320 displays, Henning’s CRJ and have someone check the shuttle.<ref>https://sourceforge.net/p/flightgear/mailman/message/37610762/</ref> }}

{{Canvas Navigation}}

bugman once came up with the idea to take screen shots and use those to do automated unit-testing for these things, he discussed that idea in detail with James and Stuart on the list back then, including specifically the idea to do "''Headless rendering that can be captured as a bitmap''"<ref>https://sourceforge.net/p/flightgear/mailman/message/37086044/</ref>.

The idea back then was to ''render frames to bitmaps on disk or in memory for per-pixel checks'' for regression testing purposes.<ref>https://sourceforge.net/p/flightgear/mailman/message/37345003/</ref>

Edward stated: ''we will need to implement a true "headless" mode. Querying the scene graph, including performing scene graph dumps,
could be useful for quite a number of tests. And, probably also of interest especially for debugging graphics card driver issues,
switching to offline rendering to dump to a bitmap and check individual pixels'' <ref>https://sourceforge.net/p/flightgear/mailman/message/36292929/</ref>

Referring to the Canvas specifically, it is trivial to add a screen shot handler, to take canvas-specific screen shots and dump those to disk to run a binary diff (or do so in memory): [[Canvas_troubleshooting#Serializing_a_Canvas_to_disk_.28as_raster_image.29]]

It might even be possible to add a new Canvas.Path2 element, to run shiva and shadervg in the same fgfs executable and execute those tests side-by-side that way. <ref>https://sourceforge.net/p/flightgear/mailman/message/37612255/</ref>

In the mid-term, the idea being to accept a boolean flag at the Canvas level (for each canvas) so that we can decide which back-end to use.
At that point, it would be trivial run existing Canvas code with both back-ends within the same binary, each rendering to a separate canvas FBO.

And then, all that we'd need to do is to use something like memcmp() to compare two Canvas FBOs/textures side-by-side.

We could expose the equivalent of a <code>compare-canvas</code> fgcommand that takes the SGPropertNode/path of two canvas textures and runs then memcmp() in a for-loop for each pixel.

If this sort of functionality could be added to next, it would enable early-adopters/core devs and fgdata committers to get involved in testing/troubleshooting, without breaking next/fgfs for users not wanting to tinker with ShaderVG at this point.

Later on, we could either expose ShaderVG via new dedicated Canvas.Path2 namespace (totally new and separate), and phase out Canvas.Path over time.

Or, if the port works well enough, support a custom uint "version number" for sc::Element, so that people can easily adopt the new version by setting the required version to "2" for their Canvas.Path instance (with 1 one being the current default).

This could go a long way to help people get involved in testing and troubleshooting, without having to be C++ developers, also all the deployment would be handled automatically.

And a corresponding fgcommand (or cppbind wrapper) to do a pixel/bit-wise comparison of two Canvas textures would seem like a straightforward thing to implement, if we can figure out the other parts.

To be really on the safe side, we could even implement unit tests in Nasal space for each OpenVG primitive and do a comparison of both textures after each instruction (optionally).

One simple test case would be to use SVG files (which are internally converted to OpenVG instructions via svg.nas) and then parse/load those to compare the functionality of both back-ends, while diff'ing the two resulting Canvas FBOs pixel by pixel.

If things are too difficult to port properly, introducing a dedicated Canvas.Path2 namespace while phasing out Canvas.Path, would seem like a straightforward option to help migrate to Core Profile, without having people complain that Canvas.Path (Shiva) no longer works - because there would be no guarantee it actually does for people using the new namespace...

Another option would be adding a new boolean property to each Canvas for an optional "shadow" canvas, that way the CanvasMgr itself could run optionally update TWO textures in parallel, one using the original shiva back-end, and the other one using the new ShaderVG based back-end, this sort of infrastructure should also come in very handy if/when other Canvas elements may need to be updated in the time to come.

Basically, if a "enable-canvas-tracking" property is set up, another ODGauge FBO would be set up, which would receive updates by the new sc::element/back-end. This could optionally happen per frame (costly), or at a configurable interval, or even per OpenVG instruction.

=== Headless ===
{{Mergeto|FlightGear Headless}}
More generally, Edward stated that this is an area that he had in mind for the test suite. However the basic infrastructure of starting up a minimal headless scene graph rendering to a buffer has not been implemented yet.

So, someone needs to look at OSG and work out how to set up headless rendering in a way that you can capture a bitmap of the scene. The rest is then a piece of cake.

He suggested talking to James about this, as he might be able to quickly implement a simple headless infrastructure and be able to capture the issue. This original Canvas Path issue looks like the perfect excuse to implement this test suite infrastructure that, in the future, will be immeasurably useful!

Besides, the previous headless code is not so much use. For the test suite you probably only need a one line code change to render to a 'pbuffer' in OSG, and an additional option to render to a texture. What is relevant is a short function starting up the minimal set of subsystems (and currently non-subsystem elements) to render a basic fgfs scene graph. And maybe a second function to set up what is required to capture this issue. The key is that the main bootstrap routine used in fgfs is not used in the test suite - but Fred's contribution assumes this full bootstrapped system up and running.

In the test suite we don't want that full system, but an absolute minimum set of subsystems and other code running. There will be a set of helper functions (in test_suite/FGTestApi/) to set up different OSG components for different tests. The complication is that most subsystems will segfault if they are not in normal bootstrap position - you are already well aware of their brittleness. Another complication is that certain elements are not subsystems, e.g. FGSky. So the difficulty is not the headless part but simply setting up the minimal subset, fixing up all the segfaulting.

== ShaderVG ==
{{Caution|ShaderVG support is quite experimental at this stage. If you do not want to pull the latest changes, you can also try to compile simgear explicitly with <pre>USE_SHADERVG=OFF</pre> during the cmake step to ensure it's disabled.<ref>https://sourceforge.net/p/flightgear/mailman/message/37637897/</ref>
}}

[[File:ShivaVG.jpg|thumb|Here is a comparison between ShivaVG and ShaderVG.Look at the Canvas Dialog top left and particularly the vertical airspeed bars <ref>https://sourceforge.net/p/flightgear/mailman/message/37610774/</ref>]]
[[File:ShaderVG.jpg|thumb|Here is a comparison.Look at the Canvas Dialog top left and particularly the vertical airspeed bars<ref>https://sourceforge.net/p/flightgear/mailman/message/37610774/</ref>]]
'''Status:''' As of 03/2022, Erik added ShaderVG next to ShivaVG in SimGear next for testing ({{Simgear commit|6451e505d8549f7d1e4bb440189559448f6aea5a}}). The local patches applied to ShivaVG for FlightGear have also been applied to ShaderVG where appropriate, but it's not yet fully functional.<ref>https://sourceforge.net/p/flightgear/mailman/message/37612255/</ref>

To get involved in testing, use the <pre>Cmake option: USE_SHADERVG</pre> {{Simgear commit|b157f9cb9f02a77577ef309391289e8926a9b164}}.
Refer to related commits for details, see {{Simgear commit|074ba34035e240d144e0bc31c10583efcf82e566/}}.

In 03/2023, Erik shared an update stating that he's now got the root of the problem:
In VGInitOperation.cxx the size of the OpenGL viewport is passed to vgCreateContextSH which is always (0, 0, 800, 600) for some reason.
ShaderVG takes this input as the maximum area to draw thereby ignoring the "view" property when creating a new canvas in Nasal.
If he manually matches the parameters parsed to vgCreateContextSH with the canvas "view" parameters everything renders okay.
One of the problems is that VGInitOperation is called from osg.

Now he needs to find out where that is done and how to make it retrieve Canvas::getViewport instead <ref>https://sourceforge.net/p/flightgear/mailman/message/37783708/</ref>

In April 2023, Erik mentioned a few remaining problems probably related to this: If I disable shader use in the code most of it seems to work properly.

But as soon as one or both of the shaders are used things get whacky,
and I suspect it has something to do with what used to be the ModelView
matrix which don't match between OpenSceneGraph and the shaders.

And to be honest, I don't know enough about both of them to fix this
issue. So I would greatly appreciate it of someone with more knowledge
on the subject could take a look.

The shaders have been moved from the code to FGSDATA/gui/shaders/
<ref>https://sourceforge.net/p/flightgear/mailman/message/37803242/</ref>

For the corresponding commits, refer to:
* {{Simgear commit|6e30dfddc0717ac099228f4e288786db8d0f6a96}}
* {{Flightgear commit|24012329699186ab77fc673d77d07ba1196dbac7}}
* {{Fgdata commit|cfef45c93be67b8bc75f82b70adf968c5ec663cd}}

Erik's most recent update stating that he's got basic integration working now with few remaining issues.<ref>https://sourceforge.net/p/flightgear/mailman/message/37787634/</ref> For details, please refer to {{Fgdata commit|61664836a45d7ea2757916b51f02adb4bb45ab77}} and {{Simgear commit|64be445a020e29a352b63bfaefc6ac5aca90837d}}.

An email on the devel-list early 2022 mentioned that nanoVG (see below) may not be super simple to drop in, so another idea was using ShaderVG which seems to follow exactly the same API as ShivaVG.<ref>https://sourceforge.net/p/flightgear/mailman/message/37610705/</ref>

Early experiments (patch [https://sourceforge.net/p/flightgear/mailman/message/37610741/]) in 02/2022 with ShaderVG were promising and suggest, that it ‘kind of sort of’ works, that’s already less work than integrating NanoVG.<ref>https://sourceforge.net/p/flightgear/mailman/message/37610750/</ref>

[https://github.com/tqm-dev/ShaderVG ShaderVG] is a fork of a fork of the original ShivaVG which seems to not use the fixed OpenGL pipeline (well, at least it doesn’t have any glBegin/glEnd calls etc).

It uses glSicssor for clipping, that's fine. vgMaskImage is unimplemented but we could add it if anyone ever requested it.

The actual path filling / stroking uses stencil ops: this avoids the need to specify a custom framebuffer internally: of course Canvas is often rendering using an OSG FrameBuffer but that’s same today. (Maybe ‘old’ Shiva also uses the stencil ops the same way, also)

All gradient / pattern filling is handled using shaders, that’s very nice, should make using linear/radial gradients and patterns much better than existing Shiva. (This is same as NanoVG)<ref>https://sourceforge.net/p/flightgear/mailman/message/37610713/</ref>

Also, running a diff against ShivaVG from git, it turns out that FlightGear does have a number of local changes compared to a clean
ShivaVG, among "setup GL projection" changed to "We handle viewport and projection ourselves" Something similar is probably required for ShaderVG.<ref>https://sourceforge.net/p/flightgear/mailman/message/37612162/</ref>

For the time being, it's not a one on one drop in replacement but it works quite nicely:
* For one the x,y positions are off comapared to ShivaVG making things slightly bigger (maybe too big for the screen).
* and one issue with the "title bar" being opaque.<ref>https://sourceforge.net/p/flightgear/mailman/message/37610740/</ref>

Possibly, ShaderVG is writing to a texture buffer on the graphics card, but for some reason a different texture buffer is being referenced by FG - in one case the building texture and in another a random bit of graphics card memory.<ref>https://sourceforge.net/p/flightgear/mailman/message/37613781/</ref>

== Nanovg ==
Stuart wondered, whether we could use nanovg to create the texture from the vector data, as I think we already include it for Canvas?<ref>https://sourceforge.net/p/flightgear/mailman/message/37660063/</ref>
Canvas uses Shiva VG. But there is a GPU implementation of it (called ShaderVG) lingering to get included after some bugs are ironed out.<ref>https://sourceforge.net/p/flightgear/mailman/message/37660251/</ref>

The original idea was to replace Shiva with this: https://github.com/inniyah/nanovg

.. which should be small enough to drop in directly, *and* we believe, supports the required Path rendering features which Canvas needs. (Eg, line thickness, dot/dash, clipping) Unlike Shiva, NanoVG can target Core-profile OpenGL, using its own shaders, and because they both aim to implement the same VG spec, should be close enough at the pixel level, to keep everything working. (Let’s see how that works in reality)

What could then be added to Canvas, is the option to use shaders when using a [[Canvas Image]]. Qt Quick calls this a ‘layer’ (like in Photoshop): basically when drawing this intermediate texture (which is what an Image or Canvas-in-a-Canvas is), add the option to use a custom shader in a very similar manner to an [[ALS]] filter. That would definitely be a nice enhancement to Canvas capabilities.<ref>https://sourceforge.net/p/flightgear/mailman/message/37606487/</ref>


== CPU renderer ==
{{See also|Canvas_news#Skia_backend|Canvas_news#Skia_talks}}
James has been recommending for some time, that it should be possible to render Canvas using CPU (not GPU) which for older machines could be a win for us. Even with us switching from ShivaVG to NanoVG for GPU accelerated drawing, there is some chance it’s still worth pursuing this.

(Basic idea is to use one of the mannnnnny software VG renderers, eg Cairo or something smaller : this would trade GPU time for CPU time, almost certain a bad idea on modern GPUs, but if the GPU is already the bottleneck, and CPU cores are idle, could potentially work well on older machines to make our use of resources more balanced)

It would be ‘some work’ but much less work than every aircraft dev duplicating their entire Canvas work. If someone is ever interested to try this, just ping James Turner, it’s quite a nice self-contained project.<ref>https://sourceforge.net/p/flightgear/mailman/flightgear-devel/</ref>

== References ==
{{Appendix}}