
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.
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.
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
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.
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.
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
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
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).
Hooray wrote:That should be trivial to do by looking at the original patch/diff that disabled the original Canvas based aircraft center: https://sourceforge.net/p/flightgear/fg ... 152d12c2a/
If this is something that people with non-Qt enabled builds want to try, I would suggest to edit $FG_ROOT/gui/menubar.xml according to the following (untested):
- Code: Select all
<item>
<name>aircraft-center</name>
<binding>
<command>nasal</command>
<script><![CDATA[
# https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Main/fg_scene_commands.cxx#l360
var haveQtLauncher = fgcommand("open-launcher");
if (!haveQtLauncher) {
# https://sourceforge.net/p/flightgear/fgdata/ci/654a343bbb7eb51b387060515e3415e152d12c2a/
canvas.loadDialog("AircraftCenter");
}
]]></script>
</binding>
</item>
Freel free to test/report back here and share if this works or not.
Obviously, it would also be possible to run the heuristics during startup and patch the open-launcher fgcommand using the addCommand() API.
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
James Turner wrote:Enable the Qt gui inside the sim.
Needs a lot of testing, but aircraft can be installed / changed and
location adjusted from within the sim. After some number of times the
sim will crash.
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:
- Code: Select all
lucio@fx:~/programmi/flightgear/exe$ bin/fgfs
FlightGear: Version 2018.3.1
FlightGear: Build Type Dev
Built with GNU C++ version 8.2
Jenkins number/ID 0:none
Settings migrated: Saved settings were migrated from a previous version of FlightGear. If you encounter any problems when using the system, try restoring the default settings, before reporting a problem. Saved settings can affect the appearance, performance and features of the simulator.
FGPropertyManager::GetNode() No node found for hydro/active-norm
Error: caught signal 11:
/lib/x86_64-linux-gnu/libc.so.6 : ()+0x35fc0
/usr/lib/x86_64-linux-gnu/libstdc++.so.6 : __dynamic_cast()+0x17
bin/fgfs : ()+0x1f0565f
bin/fgfs : SGTextureStateAttributeVisitor::apply(int, std::map<std::pair<osg::StateAttribute::Type, unsigned int>, std::pair<osg::ref_ptr<osg::StateAttribute>, unsigned int>, std::less<std::pair<osg::StateAttribute::Type, unsigned int> >, std::allocator<std::pair<std::pair<osg::StateAttribute::Type, unsigned int> const, std::pair<osg::ref_ptr<osg::StateAttribute>, unsigned int> > > >&)+0x85
bin/fgfs : SGTextureStateAttributeVisitor::apply(std::vector<std::map<std::pair<osg::StateAttribute::Type, unsigned int>, std::pair<osg::ref_ptr<osg::StateAttribute>, unsigned int>, std::less<std::pair<osg::StateAttribute::Type, unsigned int> >, std::allocator<std::pair<std::pair<osg::StateAttribute::Type, unsigned int> const, std::pair<osg::ref_ptr<osg::StateAttribute>, unsigned int> > > >, std::allocator<std::map<std::pair<osg::StateAttribute::Type, unsigned int>, std::pair<osg::ref_ptr<osg::StateAttribute>, unsigned int>, std::less<std::pair<osg::StateAttribute::Type, unsigned int> >, std::allocator<std::pair<std::pair<osg::StateAttribute::Type, unsigned int> const, std::pair<osg::ref_ptr<osg::StateAttribute>, unsigned int> > > > > >&)+0x64
bin/fgfs : SGTextureStateAttributeVisitor::apply(osg::StateSet*)+0x43
bin/fgfs : ()+0x1f0571f
bin/fgfs : SGTextureStateAttributeVisitor::apply(osg::Geode&)+0x98
/usr/lib/x86_64-linux-gnu/libosgDB.so.100 : osg::Geode::accept(osg::NodeVisitor&)+0x89
/usr/lib/x86_64-linux-gnu/libosg.so.100 : osg::Group::traverse(osg::NodeVisitor&)+0x33
bin/fgfs : osg::NodeVisitor::traverse(osg::Node&)+0x69
bin/fgfs : SGTextureStateAttributeVisitor::apply(osg::Node&)+0x4f
bin/fgfs : osg::Group::accept(osg::NodeVisitor&)+0x58
/usr/lib/x86_64-linux-gnu/libosg.so.100 : osg::Group::traverse(osg::NodeVisitor&)+0x33
bin/fgfs : osg::NodeVisitor::traverse(osg::Node&)+0x69
bin/fgfs : SGTextureStateAttributeVisitor::apply(osg::Node&)+0x4f
bin/fgfs : osg::Group::accept(osg::NodeVisitor&)+0x58
/usr/lib/x86_64-linux-gnu/libosg.so.100 : osg::Group::traverse(osg::NodeVisitor&)+0x33
bin/fgfs : osg::NodeVisitor::traverse(osg::Node&)+0x69
bin/fgfs : SGTextureStateAttributeVisitor::apply(osg::Node&)+0x4f
bin/fgfs : osg::Group::accept(osg::NodeVisitor&)+0x58
/usr/lib/x86_64-linux-gnu/libosg.so.100 : osg::Group::traverse(osg::NodeVisitor&)+0x33
bin/fgfs : osg::NodeVisitor::traverse(osg::Node&)+0x69
bin/fgfs : SGTextureStateAttributeVisitor::apply(osg::Node&)+0x4f
bin/fgfs : osg::Group::accept(osg::NodeVisitor&)+0x58
bin/fgfs : simgear::OptimizeModelPolicy::optimize(osg::Node*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, osgDB::Options const*)+0x8b
bin/fgfs : ACOptimizePolicy::optimize(osg::Node*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, osgDB::Options const*)+0x31
bin/fgfs : simgear::ModelRegistryCallback<ACProcessPolicy, simgear::DefaultCachePolicy, ACOptimizePolicy, simgear::OSGSubstitutePolicy, simgear::BuildLeafBVHPolicy>::readNode(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, osgDB::Options const*)+0x26e
bin/fgfs : simgear::ModelRegistry::readNode(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, osgDB::Options const*)+0x139
/usr/lib/x86_64-linux-gnu/libosgDB.so.100 : osgDB::readNodeFile(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, osgDB::Options const*)+0x1c1
bin/fgfs : ()+0x1f23f94
bin/fgfs : simgear::SGReaderWriterXML::readNode(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, osgDB::Options const*) const+0x11b
bin/fgfs : simgear::ModelRegistryCallback<simgear::DefaultProcessPolicy, simgear::NoCachePolicy, simgear::NoOptimizePolicy, simgear::NoSubstitutePolicy, simgear::BuildLeafBVHPolicy>::loadUsingReaderWriter(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, osgDB::Options const*)+0x90
bin/fgfs : simgear::ModelRegistryCallback<simgear::DefaultProcessPolicy, simgear::NoCachePolicy, simgear::NoOptimizePolicy, simgear::NoSubstitutePolicy, simgear::BuildLeafBVHPolicy>::readNode(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, osgDB::Options const*)+0x186
bin/fgfs : simgear::ModelRegistry::readNode(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, osgDB::Options const*)+0x139
/usr/lib/x86_64-linux-gnu/libosgDB.so.100 : osgDB::readRefNodeFile(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, osgDB::Options const*)+0x1d1
bin/fgfs : ()+0x1eaa59e
bin/fgfs : simgear::SGModelLib::loadModel(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, SGPropertyNode*, simgear::SGModelData*, bool)+0x193
bin/fgfs : ()+0x156734d
bin/fgfs : FGAircraftModel::init()+0x483
bin/fgfs : SGSubsystem::incrementalInit()+0x23
bin/fgfs : SGSubsystemGroup::incrementalInit()+0x148
bin/fgfs : SGSubsystemMgr::incrementalInit()+0x52
bin/fgfs : ()+0x1a587df
bin/fgfs : fgOSMainLoop()+0xce
bin/fgfs : fgMainInit(int, char**)+0x9d1
bin/fgfs : main()+0x20b
/lib/x86_64-linux-gnu/libc.so.6 : __libc_start_main()+0xe7
bin/fgfs : _start()+0x2a
cd $FG_SRC_DIR
git clone https://github.com/openscenegraph/OpenSceneGraph.git
cd OpenSceneGraph.git
git checkout OpenSceneGraph-3.2.3
cd ..
mkdir osg-build
cd osg-build
cmake -D CMAKE_BUILD_TYPE="Release" -D CMAKE_CXX_FLAGS_RELEASE="-O3 -pipe" -D CMAKE_C_FLAGS_RELEASE="-O3 -pipe" \
-D CMAKE_INSTALL_PREFIX:PATH="$FG_INSTALL_DIR" ../OpenSceneGraph.git
make
make install
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!
Return to The FlightGear project
Users browsing this forum: No registered users and 2 guests