|Caution The feature documented below, in its current form, is currently being discussed/expected (or scheduled) to be significantly updated, or phased out, in future FlightGear versions. 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 and coordinate any related work with the devel mailing list-this applies particularly to adding any additional hard-coded PUI widgets.)
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.
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.
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.
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.
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.
As of 03/2020, the PLIB replacement was reported to be in the backlog .
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. 
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)
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.
The PUI UI and replacement can co-exist in the same build (they already do, effectively.
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. 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.
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 .
In 02/2019, James stated that the new UI is coming quite soon. 
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.
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.
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.
In 10/2017, James said he was getting really close to having the PUI replacement UI suitable for beta-testing.
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.
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)
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.
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
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:
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), see ticket #2213.
PUI is also known to affect rendering performance quite significantly (see forum search for anthrax+gui FlightGear Forum), while also preventing FlightGear from using a more recent version of OpenGL.
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
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.
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.
|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)