PUI: Difference between revisions

Jump to navigation Jump to search
4,920 bytes added ,  29 December 2022
Line 108: Line 108:


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>
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>
== 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. }}
For these reasons, we're hoping to phase out PUI in FlightGear. One of the lowest hanging fruits is re-implementing the [[Menubar]] by using a [[Howto:Making a Canvas Menubar|Nasal/Canvas translator]]
[[File:Canvas-menubar-jabberwocky-09-2014.png]]
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 ==
== History ==

Navigation menu