danielHL wrote in Fri May 21, 2021 12:45 pm:Long story short: The fix you are proposing is in a GUI that is soon-ish going away and no new development on this GUI-Toolkit should be started.
To be honest, in a perfect world that would be true, but in reality that's a bit misleading unfortunately: The PUI GUI engine has been scheduled for removal/replacement for over half a decade meanwhile, with numerous public statements saying "it would be almost ready soon" over the course of several years now:
https://wiki.flightgear.org/PUI#Replacement_statusRealistically, the Qt based replacement isn't going to be available to all end-users as long as Qt5 is required to remain an optional dependency because some core developers say so:
https://wiki.flightgear.org/FlightGear_ ... BackgroundThat is why some aircraft developers have begun using Canvas based aircraft specific dialogs, to shield themselves from any significant changes in the UI department (with others simply using Phi).
Specifically, a number of core devs stated explicitly that the integration:
There also is the additional fact, that the PUI replacement is really only being worked on by single contributor - who happens to be the primary FlightGear core developer, too. In other words, that developer has plenty of stuff on his todo list. And the Qt5 based PUI replacement has never been shared, let alone completed, despite that developer being a professional Qt developer.
Behind the scenes, a number of folks have shared that the Qt5 replacement has been put on hold, since there are more urgent issues that need to be solved at the moment.
It's also been observed build issues (compilation problems) reported on the devel list are regularly related to Qt5 and dependency issues.
Also, if you look at the commit logs you will see, James himself has been committing stop-gap solutions by extending/fixing the PUI integration "for now" (well, for the last 5+ years). Thus, I wouldn't hold my breath - fgdata level improvements that get rid of PUI by using Canvas are almost certainly going to be welcomed - especially as long as it's unclear if/when the Qt5 replacement is going to be "ready".
For all the nitty gritty details and historical background, see:
https://wiki.flightgear.org/Howto:Proce ... ing_CanvasFurthermore a number of senior contributors are concerned about the fact that using Qt in conjunction with multi-threaded OSG apps is generally frowned upon, and at times even discouraged, on the osg-users list, e.g. by the OSG project lead himself (Robert Osfield):
Robert Osfield wrote:https://groups.google.com/d/msg/osg-use ... SD3DlPAAAJThe threading models that the OSG
provides reflect this, enabling threading of the update, event and
cull traversals in parallel with the draw thread. This is all
possible with a Qt based viewer, but different versions of Qt add
their own caveates/problems. If you care a about full screen
real-time performance then Qt probably isn't the best tool to use,
native osgViewer based viewer will work much better, but if you need
the 2D GUI elements that Qt provides then you'll need to jump through
the extra hoops that Qt throws into the mix.
https://groups.google.com/d/msg/osg-use ... _2gPlZAwAJUnfortunately Qt has created a
series of problems on the threading front that we've had to try and
work around, Qt then goes and moves the goal posts though between
releases. it's been a real pain to try and keep osgQt working well
over the years. If you don't need a traditional 2D UI then it's
generally best to avoid Qt as it causes problems because it has it's
way of working that doesn't fit well with the needs of real-time
visualization.
(It's also worth noting that Robert has been making these statements despite KDAB (James himself) showing up on osg-users to help improve OSG/Qt5 integration)
If in doubt, check back with the developer's mailing list - but according to the most recent "release plan", the Qt5 based PUI replacement is no longer on the roadmap at all, despite it having been created/drafted by James himself:
https://wiki.flightgear.org/2022.X_Release_planSo it's probably best not to put too much additional pressure on the whole Qt5 effort by telling end-users it will be ready "soon" unless James explicitly says so himself; the PUI/Qt5 replacement is already approaching the HLA/RTI "pie in the sky" dilemma we've been watching for another decade - so, let's try to learn our lesson here, after all this is a volunteer-based project
PS: See gui.nas for additional PUI based helpers to write text to the screen, which too, could be wrapped by a Canvas helper using the same backend (as per tooltips.nas)