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.

that was the aircraft hanger... yes, it is disabled in the release... it is a subsection of the new launcher and there are problems with using it as the hanger in the sim at this time... when those problems are corrected, it will be re-enabled in the sim so you can change craft without having to exit and restart the whole thing...

"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up.""Why not?" said Gurder."Dunno. It's frightened of heights, I guess."

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 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.

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:

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:

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:

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).

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.

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.

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):

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:

James Turner wrote:I can make it fall back, except: my impression is that creating a GUI in Canvas was an experiment which didn’t get far enough along to become viable.

Hence, the canvas-based aircraft centre is effectively a dead-end, even if it works - I’d rather make the Qt GUI more usable (since it’s easy for me).

Do note though, that this whole "dead-end" thing and the simplicity of working on a Qt based solution have de-facto turned out to be a "red herring", because we still have builds that lack Qt support, and because the launcher is still rather fragile, despite these discussions having taken place over the course of 3+ years meanwhile.

But primarily, the "fix" for builds not having/wanting the Qt5 based aircraft center boils down to 5 lines of code that you'll need to add to the menubar.xml:

Thank you, wkitty42 and Hooray. I checked FG 2018.1.1 and found the feature I refer to is called "Aircraft Center (Experimental)" on the File tab. Clicking it opens a dialog box with Summary, Aircraft, Location, Environment and Fly! icons on the left sidebar, allowing one to change Aircraft, Location and Environment parameters without exiting the program and re-opening it.

Should also mention the nicely improved cloud formations in 2018.3.1 and, when flying yesterday, saw a rainbow in FlightGear...that's the first time I've seen one in any Flight Simulator!

correct, the original Nasal/Canvas based "aircraft center" (that would work for everyone, even for people not having access to a Qt enabled build) got declared "experimental", and was disabled in menubar.xml so that the "new" Qt based "aircraft center" would receive wider testing:

James Turner wrote:Part of the reason for making this change was to get some feedback on how using the launcher inside the sim works

At the time, the funny/weird thing that caused quite a bit of irritation was to declare one working feature "experimental and obsolete" (without coordinating this with the people involved in creating that feature originally), in favor of another Qt based feature (read: required to be optional), that should also be considered "experimental" according to the commit logs:

Needs a lot of testing, but aircraft can be installed / changed andlocation adjusted from within the sim. After some number of times thesim will crash.

Rest assured though, you can be pretty sure that any Qt-based features will be restored to working order by the corresponding developer, the Qt stuff has been getting quite a bit of attention over the years.

lucrus wrote in Mon Nov 12, 2018 6:06 pm:I've build 2018.3 from sources on Linux (because I wanted to test it, but I couldn't find any 2018.3 precompiled Linux downloads). During startup, when it shows "initializing subsystems", it immediately shuts down and reports the following on the terminal:

I hope you read this - I've got the same error and with the help of James I solved it.

I suspect you are also on debian testing or similar? Since a few days there has been a compiler/libc-update that makes the distro version of libopenscenegraph incompatible. The easy fix is to build it yourself for the time being. Follow the instructions at the wiki to build flightgear and osg accordingly.

When installing flightgear 2018.3.1 I get the following message. 2018.3.1\data\Ai\Aircraft\Buccaneer\instruments\port_coaming_panel.png an error has occured while trying to copy a file: the source file is corrupted.

I've just taken a trip LIMJ-LSZH and I am stunned, how FG has developped.

Especially in respect to the clouds. The impression of flying past and trough clouds is fantastic.

FSX looks so lame in this respect. It was never really doing overcast situations, except by "bombing" the layer with clouds, until no visible patch left with frame rate unnessarily down.No fun for IFR.

Also I like the new C172-Cockpit! Outstanding.

An nice to find myself in the middle of AI-traffic. Is there a way to get vectors and clearances? Because between number 2 and number 3 for landing I had to make myself a hurried number 2.5...

I'd like to suggest, that the "back" button in the GUI is changed to "airport selection" or similar. Because it is not clear, that FG can be started directly from the airport of choice.Going to Honululu and then changing airport via the menu means double the loading time.For sure it can be started from the command prompt with options - but above might make it a bit more user friendly.

New clouds in 2018.3.1 are realy perfect.With FSX did You use FSXWX or some better payware like ActiveSky 2016 or some similar external weather engine ? I tested freeware FSXWX and perform very well - for example :

pb321 wrote in Sun Dec 09, 2018 2:01 am:Thank you, wkitty42 and Hooray. I checked FG 2018.1.1 and found the feature I refer to is called "Aircraft Center (Experimental)" on the File tab. Clicking it opens a dialog box with Summary, Aircraft, Location, Environment and Fly! icons on the left sidebar, allowing one to change Aircraft, Location and Environment parameters without exiting the program and re-opening it.

Should also mention the nicely improved cloud formations in 2018.3.1 and, when flying yesterday, saw a rainbow in FlightGear...that's the first time I've seen one in any Flight Simulator!