FlightGear Forum
pb321 wrote in Sat Dec 08, 2018 1:36 am:Just realized the Aircraft (experimental) option (I think that is what is was called) is no longer available in the File tab on the menu in the latest (final) 2018.3.1. This was a good way to change aircraft or location (especially parking) without exiting the simulator and re-loading, and it seemed to work pretty well. I know the objective of this release was to provide a "stable" version of FG, and I also know that feature resulted in a few crashes (at least it happened to me on occasion), but it usually saved time when a change in location or aircraft was desired in the middle of a flying session. Will it be brought back or has it been eliminated from future consideration? Personally, it will be missed.
You are probably referring to the original "Aircraft Center" Canvas dialog?
If so, that was created by the core developer who developed the Canvas system (TheTom) at the encouragement of FlightGear core developer James Turner and it is internally using only Nasal scripting code and the built-in 2D rendering API called "Canvas": http://wiki.flightgear.org/Aircraft_Center
Curt mentioned plans on extending the "in-app aircraft center":
http://sourceforge.net/p/flightgear/mai ... /33451055/
Curt wrote:As we move forward with FlightGear development and future versions, we will be expanding the "in app" aircraft center. This dialog inside flightgear lets you select, download, and switch to any of the aircraft in the library.
At the same time, Torsten began working on Phi: http://wiki.flightgear.org/Phi
And when a number of people pointed out the potential overlap in functionality (referring to the package manager at the time), the generally-communicated consensus among core developers was that the back-end would be common, ie. shared by all potential front-ends that people may come up with, no matter if people decided to use Canvas, Phi or Qt5:
New Canvas GUI
Torsten wrote:There is currently heavy activity towards a new UI. There will be the HTML5 based version, I am currently working on and an internal implementation based on well supported libraries. Most likely, both will use a common service layer to provide necessary data.
Neither of those will use Nasal or Canvas to render the UI elements.
Torsten
A number of people (including a few core developers, e.g. F-JJTH/Clement) began using Nasal and Canvas to revamp the legacy UI, but ended up being actively discouraged by numerous long-term contributors, including a number of senior core developers.
Originally, the concern communicated in public was that re-doing a UI via Nasal and Canvas would be a tedious "mammoth task" and would end up being a huge waste of time and other community resources.
Subsequently, a new Qt5 based launcher was being prototyped (and in turn, the built-in aicraft center got disabled, but is still functional), but other core developers requested that new Qt5 component to remain entirely optional:
https://sourceforge.net/p/flightgear/ma ... /34196458/
http://wiki.flightgear.org/Integrated_Qt5_Launcher
Durk Talsma wrote:There's been a strong devision of opinion among a couple of core
developers with respect to the question whether a QT dependency is
desirable or not. In one of the hangouts, a couple of months ago, we had
the chance to discuss the pros and cons, when the most outspoken
developers regarding this issue were both present. We concluded that a
QT dependency was undesirable, unless it had a specific benefit. With
this in mind, I proposed to consider the option of allowing a QT
dependency in only one module (call it FGGui). For all practical
purposes, this would be a platform independent replacement of fgrun, but
because of the proposed modularity, it will appear to be seamlessly
integrated with FlightGear. Both developers representing the opposite
ends of the debate could live with this compromise.
In parallel, I prototyped a simple (and experimental) Nasal/Canvas based parser to see how feasible a Canvas based PUI replacement would be (proof-of-concept, i.e. under 500 LOC):
http://wiki.flightgear.org/Pui2canvas
Later on, the only core developer intimately familiar with the process of revamping the UI and the corresponding subsystems, simply conceded that he didn't want any competition, and was concerned about a Nasal/Canvas based alternative de-railing his own C++/Qt5/QQ efforts, so that he would stop his work should someone decide to continue working on a Canvas based option:
https://sourceforge.net/p/flightgear/ma ... /36199572/
James Turner wrote:My impression is that if you make a Canvas UI option, the Qt based solution will be still-born almost by default - because I won’t be able to create any enthusiasm or interest around it. Maybe I’m wrong about that, but for sure Canvas based approaches attract a lot more support and man-power very easily. And my guess each person who works on the Canvas based Ui is one fewer who might ever help out with the Qt based one. (That is not probably 100% true, but I guess there is some correlation)
So I have taken your proposal as your intention to build a full-fleged UI in Canvas, because you believe it will be better than what I’m proposing - which is fine, but again, I don’t see it a good use of people’s lives to do that work twice (again, if I’d been Miguel de Icaza, I would have joined in with KDE or gone to write something else, not started GNOME).
https://sourceforge.net/p/flightgear/ma ... /36199712/
James Turner wrote:Well let’s say the Qt UI is 1/4 of my time per week spent on FG (might be a little more, but I have lots of other things to work on), vs Thorsten’s time and 4 or 8 enthusiastic people he can recruit - I’m obviously going to fall massively behind in comparison - within three or six months they might build a complete replacement UI.
Subject: Flightgear source code terminates in GLExtension.cpp
Hooray wrote:wkitty42 wrote in Mon Sep 03, 2018 5:54 pm:disabling Qt may also affect the in-sim Aircraft Center... there are instructions somewhere (wiki?) on what to change in the sources to use the old Aircraft Center if it is desired in one's FG... it is only a coupld of lines, IIRC...
Yes, that's absolutely correct, even though I don't think I added those instructions to the wiki, but there should be a corresponding forum topic, it's a fairly simple change actually only involving a few lines of Nasal code.
As far as I know, the real issue however is that I don't think the package manager stuff received much/any testing by people not using Qt-enabled builds, so there may be plenty of issues that we are unaware of, because the original "Aircraft Center" simply got phased out when the Qt launcher got added.
Originally, the plans announced on the devel list/forum (respectively) stated that the new UI would use a common service layer back-end that could also be used by other front-ends, including Phi, but I am not sure how much of this ever materialized or not.
In other words, I am not sure if it's even supposed to be possible to use a non-Qt enabled build (e.g. via Phi) to download/install and manage aircraft/scenery or not ?
Then again, technically there is really no reason why the same back-end could not be exposed via a CLI (Command Line Interface) so that non-Qt5 builds/users can still make use of the package manager back-end, especially if everything works through fgcommands - besides, this could be a great asset from a troubleshooting standpoint, i.e. people could run all sorts of tests in a scripted fashion to see if their aircraft can be easily downloaded/installed and configured, without requiring an interactive UI.
This could work analogous to the package manager on any modern Linux distro.
EDIT: The instructions on re-enabling the original Nasal/Canvas based Aircraft Center are to be found here: Subject: Reinstating Canvas based Aircraft Center for non Qt builds
Subject: Aircraft Center | pui2canvas parser (devel-list follow-up)
Hooray wrote:bugman wrote in Tue Jun 14, 2016 1:10 pm:As for Qt being optional, over the last two years on the mailing list, that position has obviously evolved. I'm only stating what I see. And that is that it will be only optional for a tiny subset of people. The majority will use it, probably without knowing, as it will be the default GUI shipped with FG.
Just a little update, roughly ~12 months later, it seems indeed that bugman was right: the position on using Qt5 for the in-sim UI seems to have evolved (though, not exactly in line with bugman's original assertion a year ago):
https://sourceforge.net/p/flightgear/ma ... /35863607/James Turner wrote:I would say do the PUI fix for now, I am still very much undecided about which technology to use for in-sim GUI. I am somewhat inclined towards using the Canvas, because it avoids some rendering issues (but exposes a few more, + some performance ones) but the problem is I am fairly unhappy with the GUI / widget API in the Canvas right now - it does not satisfy my ideas about how simple + robust such an API should be. I need to evaluate if the current API can be improved or needs to be drastically changed.
The other issue is to use QtQuick rendered into OpenGL, which has a very nice robust and well-designed API, but adds some dependencies and complicates the rendering architecture, which makes me nervous about multi-window setups and other more esoteric OSG configs.
So, yes, I’d say do PUI for now, since this is worth a fairly quick fix as it’s the default airport.
Kind regards,
James
The original forum topics covering these developments (linking back to the corresponding topics on the devel list) can still be looked up here:
