20,741
edits
Howto talk:Processing legacy PUI dialogs using Canvas: Difference between revisions
Jump to navigation
Jump to search
Howto talk:Processing legacy PUI dialogs using Canvas (view source)
Revision as of 18:59, 11 December 2016
, 11 December 2016→To be added: new section
(→Turning the whole thing into a Nasal submodule: new section) |
(→To be added: new section) |
||
| Line 554: | Line 554: | ||
Need to change the code to turn it into a submodule that can be easily reloaded on-demand (for faster prototying/testing), including de-registration of the corresponding fgcommands. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:22, 9 October 2016 (EDT) | Need to change the code to turn it into a submodule that can be easily reloaded on-demand (for faster prototying/testing), including de-registration of the corresponding fgcommands. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:22, 9 October 2016 (EDT) | ||
== To be added == | |||
FlightGear is using a built-in GUI engine using legacy OpenGL code (using PLIB's PUI): [[PUI]] | |||
On the one hand, this is providing the menubar, on the other hand it basically provides all the GUI dialogs and widgets. | |||
For the time being, the only effort realistically able to "compete" with PUI is Torsten's mongoose/Phi work, because that's using industry standards like HTML5/jQuery (JavaScript): [[Phi]] | |||
However, that work happens to be "external" in the sense of having to be rendered by a browser (or GUI widget able to render DHTML). | |||
Then, there is the ongoing Qt5 effort - this is the most solid approach at implementing a cross-platform GUI because that is really what Qt is all about. However, it doesn't come with the capability to render the GUI externally (as per Phi) - also, it is complicated to coax Qt5 code into an existing OpenGL application whose context it also didn't create originally, especially an multi-threaded application like FlightGear that happens to use all kinds of threads for different purposes, in conjunction with tons of legacy OpenGL code that isn't even using OSG (OpenSceneGraph) yet. | |||
It would be much easier to start a new application from scratch with a Qt5 UI than integrating the whole thing at this point: [[FlightGear Qt launcher]] | |||
In addition, there are literally tons of legacy resources that must continue to be supported to /some/ degree - i.e. existing dialogs, some of which are dynamically/procedurally created, while others are outside the domain of fgdata/fgaddon (think aircraft specific dialogs). | |||
This is where simply "porting" (as in "converting" or translating) existing dialogs is becoming hugely complicated. | |||
The Phi approach is hitting significant challenges when it comes to supporting dialogs that contain tons of embedded FlightGear specific scripts (so called Nasal code). | |||
Then again, given the current state of affairs, Phi is the most mature, and most promising, path forward - because it's inherently asynchronous due it its design - as far as I am aware, there isn't a single Phi/mongoose related feature that causes segfaults in FlightGear, whereas the history of the Qt5 integration is hugely different, despite having been tackled by one of the most experienced FlightGear core developers with an enormous track record when it comes to SimGear/FlightGear and Qt5 matters, the Qt5 code has been introducing tons of regressions in the form of segfaults and race conditions. | |||
In addition, there is the issue of the Qt5 GUI component having to remain optional according to the original core developer consensus - whereas Phi is non-intrusive, i.e. there is no requirement to keep it optional. | |||
All of this is massively complicating matters for anyone interested in porting/updating the legacy GUI in FlightGear, especially in the light of the relatively low importance/impact of the UI on people actually using the flight sim. | |||
Besides, PUI inevitably must go sooner or later - simply because it's not playing nice with new/more modern OSG/OpenGL code, but for us to be able to get rid of PUI, we also must make sure not to cause any major regressions - no matter if that means retaining existing functionality, or retaining at least the same degree of accessibility (which is to say that people should continue to be able to modify/update and create GUI dialogs without necessarily having to be experienced C++ developers). | |||
As far as I can tell, the work that lies ahead to properly port the existing UI to a new framework has been massively underestimated, and while Phi is very promising, it's also demonstrated that we cannot afford ignoring the DRY-principle, because otherwise we end up with diverging functionality among different UI approaches - e.g. imagine having to use Phi to control the space shuttle, having to use PUI to fly the 777 etc | |||
Unfortuntely, there's not been much of a consensus (or holistic approach) between the folks working towards these solutions, despite original comments on designing, and providing a "common UI service layer". | |||
What's been happening instead is that Qt5 is promoted, Phi is maintained and PUI is extended, i.e. new hard-coded PUI widgets are still added, which goes to show that neither the Qt5 nor the Phi work is anywhere close to actually "replacing" PUI in the sense of dealing with the in-sim use case. | |||
Realistically, this means that there are some lessons to be learnt from this - e.g. by using Phi's approach at implementing am asynchronous UI using RPC/IPC in the form of non-blocking web sockets | |||
At some point, this may mean that Phi may actually work for the in-sim use-case, too - at the mere cost of rendering a webkit view to a Qt widget and showing that inside FlightGear. However, that still would not deal with the core developer requirement to retain an in-sim GUI that does not require on optional depencies, unless this requirement is revisited and reconsidered. | |||
Also, in the light of the challenges that the Qt5 integration has been facing, what would make more sense is wrapping a QWidget using a Canvas::Element sub-class - at which point, many issues would go away. | |||
Finally, there's the original idea to get rid of PUI by implementing a parser in Nasal that dyncamilly interprets arbitrary PUI/XML markup to translate that into the corresponding Canvas equivalent, this idea is based on the realiation that Canvas is all about 2D drawing, and that modern avionics are easily more complex than a standard GUI engine with a handful of widgets (in fact, PUI is rather archaic and simple in comparison to JavaScript/Qt5). | |||
This whole idea was originally brought up by core developer James Turner, as part of his idea to help unify the 2D rendering back-end (2D panels, HUDs, GUI etc), so that legacy OpenGL code could be replaced and unified using a single back-end that ends up using modern OpenSceneGraph code. | |||
More recently, the Qt5 effort has seen much more activity - however, the original proposal is definitely sound and implementing such a parser is not as much work as manually porting the whole GUI while retaining all existing functionality (checklists, joystick GUI, tutorials etc). | |||
Basically, anybody not adopting the parser-based approach to deal with existing resources (including thouse outside fgdata/fgaddon) is basically deluding themselves when it comes to the degree of regressions that would sooner or later be introduced, unless the same person (or team of people) is also willing to re-implement all existing functionality accordingly, which is representing years of work by dozens of contributors.<ref>{{cite web | |||
|url = https://forum.flightgear.org/viewtopic.php?p=300524#p300524 | |||
|title = <nowiki> Re: Any plans for a new GUI? </nowiki> | |||
|author = <nowiki> Hooray </nowiki> | |||
|date = Dec 3rd, 2016 | |||
|added = Dec 3rd, 2016 | |||
|script_version = 0.40 | |||
}}</ref> | |||