PUI: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
mNo edit summary
m (→‎Replacement status: fix up some guess-timates ...)
(9 intermediate revisions by the same user not shown)
Line 15: Line 15:
[[File:menubar2.jpg|517px]]
[[File:menubar2.jpg|517px]]


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 (see {{readme file|commands}}) and custom [[Nasal]] code. In addition, each PUI/XML dialog may contain Nasal sections that are executed when opening/closing the dialog, a feature which is commonly used for procedurally creating/updating widgets using the cmdarg() API, which allows the dialog tree to be traversed and manipulated prior to the dialog being rendered.
== Replacement status ==
 
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>
 
 
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>
 
 
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, 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>
 
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>
 
== 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 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 SGCondition in props.nas  
Widgets can be conditionally hidden/shown using a wrapper for SGCondition in props.nas  
The <code>canvas</code> widget also supports its own embedded Nasal section to execute arbitrary widget specific Nasal code.
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:
PUI/XML dialogs can be loaded, dynamically created, updated and closed using a handful of fgcommands:
Line 26: Line 91:
* {{fgcommand|dialog-close}}
* {{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 styles and [[Effects|effects]]/[[Shaders|shaders]]).  
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]]).  


PUI is also known to affect rendering performance quite significantly, 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>.  
PUI is also known to affect rendering performance quite significantly, 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>.  
Line 56: Line 121:
   |script_version = 0.40  
   |script_version = 0.40  
   }}</ref>
   }}</ref>




Line 66: Line 130:


[[File:Canvas-menubar-jabberwocky-09-2014.png]]
[[File:Canvas-menubar-jabberwocky-09-2014.png]]
James is hoping to land the PUI replacement GUI in this dev cycle (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 approaches, but are trivial with the new 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. (I expect 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>





Revision as of 19:33, 17 February 2019

Caution  The feature documented below, in its current form, is currently being scheduled/expected (or discussed) to be significantly updated, or phased out, in future FlightGear versions + (rough estimate). This should be taken into account if you're interested in working on the feature or developing it further. If in doubt, please get in touch via the devel list first.

(PUI is likely to be removed to help improve compatibility with OSG/OpenGL 3.x and improve performance by phasing out legacy OpenGL code. Therefore, people should be careful when using/extending the PUI based legacy GUI engine[1][2] and coordinate any related work with the devel mailing list-this applies particularly to adding any additional hard-coded PUI widgets.)

FlightGear GUI dialog (exit.xml)stored in $FG_ROOT/gui/dialogs


Custom-autopilot-dialog.png

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). PUI provides a fairly basic, but robust, set of widgets. PUI is also used for rendering the Menubar:

Menubar2.jpg

Replacement status

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 based UI scheme.[3]


In 10/2017, James said he was getting really close to having the PUI replacement UI suitable for beta-testing.[4]


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)[5]

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.[6]

This PUI emulation isn't going to use any code from PLIB, so what will remain from it in FG afterwards will be the FNT and JS components (reworked).[7]

In 02/2019, James stated that the new UI is coming quite soon. [8]

Background

In FlightGear, PUI dialogs are standard PropertyList XML Files that are stored in $FG_ROOT/gui/dialogs, they can contain the widgets mentioned in $FG_ROOT/Docs/README.gui, using a simple layout engine discussed in $FG_ROOT/Docs/README.layout, and bindings using a combination of so called fgcommands operating on properties (see $FG_ROOT/Docs/README.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 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 SGCondition in props.nas The canvas 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:

  • dialog-new
  • dialog-show
  • dialog-update
  • dialog-apply
  • 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/shaders).

PUI is also known to affect rendering performance quite significantly, while also preventing FlightGear from using a more recent version of OpenGL[9][10].

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[11]

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.[12]

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.[13]


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[14][15][16].

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 Nasal/Canvas translator

Canvas-menubar-jabberwocky-09-2014.png


As of late 2015, there is heavy activity towards providing alternatives to a PUI-based UI:

References

References