I think you'd be hard pressed to come up with evidence that I am fundamentally against Qt5 - in fact, you will find me having made references and suggestions related to it, long before people came up with certain solutions - such as the "webkit/Qt" reference below - all this was at least 6+ months ago, quoting just two postings I made back then (which is to say that I don't disagree with using Qt, but with the chaotic situation resulting from all those contradicting statements):
Technically, it is the right solution to get rid of legacy GL code, but also to get rid of Nasal code in the main loop, and to stop using niche solutions that are "home-grown".
A Canvas UI is certainly not perfect, it is true that it would introduce even more property/Nasal overhead into the main loop, and some widgets would also still need to be created/extended to support existing PUI functionality. But given the trivial nature of PUI, most functionality can be easily re-created.
Also, it would be entirely "custom", too - not unlike Nasal scripting in FG (which really isn't commonly used elsewhere). With the majority of FG components being unmaintained these days, it makes absolutely sense to adopt an industry standard like Qt.
However, a corresponding parser could be written with probably ~1k LOC - and it is straightforward to do, even compared to the existing NewGUI code wrapping PUI (mapping it to xml/properties), and there were plans being discussed to phase out the built-in UI anyway. So for the time being, Nasal/Canvas CAN provide an in-sim UI, without requiring Phi/Qt5. And that could be useful, even if just during the transition time.
As can be currently seen on the devel list, the situation and the repercussions resulting from it, are far from being clear.
According to recent devel list statements, 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).
In a perfect world, we could just discontinue features - i.e. in a major release like FG 4.00 and get rid of PUI entirely, while making Qt5 a mandatory build dependency, which would also help other parts of FG, unrelated to its UI (think threading, networking etc).
Even despite excellent documentation, support and tools - creating a Qt5 dialog is more akin to "coding" than creating a functional PUI/XML equivalent.
Given the current situation, making Phi the default UI scheme and rendering it to a WebKit overlay into the main FG window (like we talked about 6+ months ago) isn't all that unattractive after all ... And for that, not even Qt5 would be required, because WebKit could also be wrapped by a Canvas element - not unlike the PDF viewer idea we've been discussing.
However, it will be interesting to see what consensus people arrive at, and to see if/how that will materialize specifically.
In the meantime, people can refer to the wiki article for isolating themselves from the whole UI situation, by using/extending a snippet of Nasal code that can be used for loading existing dialogs - i.e. regardless of the outcome of the Phi/Qt5 discussion, there is a fallback - and time will show if we are going to need it or not.
Personally, I don't care at all if Qt5 is going to be mandatory or not, as long as the GUI library can render Canvas textures, and as long as the GUI library can render its widgets to a Canvas - which really is required for the MFD use-case.
Finally, the parser is currently at ~150 LOC, and you can throw most dialogs at it and the output will look reasonable, despite many features not even implemented yet - and "bindings" are working correctly, too - including even embedded Nasal code-I think, even if someone were to come up with a Qt/Phi equivalent of the existing UI, it would be easy to match/beat with minor additions to the Nasal parser-simply because we are really just writing a parser/converter here, and are not porting the whole set of PUI dialogs:
Then again, performance is far from perfect during dialog creation (at least on the netbook I was using while prototyping this), and it seems obvious that the Canvas system would benefit from a few optimizations/additions (e.g. widget/dialog caching), but those would be useful to the whole Canvas system, especially should people still want to unify the remaining 2D rendering back-end (e.g. HUDs and 2D panels).