Like you said, the codebase/architecture could become really lean by getting rid of some of the features you mentioned - I am just not sure if it's going to be such a popular/successful step - these decisions must not be taken lightly, e.g. a few people have been wanting to get rid of Nasal, in favor of Python, Lua or JavaScript because of better "support" (maintenance, docs, examples, libraries etc) - without recognizing that the real bottleneck when it comes to FlightGear scripting is not Nasal the language (or its garbage collector), but the way the FlightGear main loop is structured, and the way Nasal code tends to be executed using the notion of timers and listeners - a different, more popular, scripting language like Python would make such problems even more prominent, within a few months time (release cycles) probably.
In theory, adopting Qt5 sounds great, and could help solve a bunch of long-standing issue, analogous to how adopting OSG has helped the project enormously - in practice however, a number of core developers have requested for all Qt5 related code to remain entirely optional and self-contained, i.e. encapsulated, using a corresponding Qt-module, so that theoretical benefits of adopting Qt5 would obviously also remain rather specific/encapsulated, i.e. unlikely to propagate to non-Qt5 areas of the codebase.
And as a matter of fact, we've had a number of people who pushed for wider adoption of boost or OpenSceneGraph, whereas the original person to actually initiate the OSG port (Mathias) has been encouraging people to encapsulate new depedencies properly, unrelated to the current popularity or maintenance status of the library in question - sounds like a lesson learnt, the hard way
https://sourceforge.net/p/flightgear/ma ... /22929621/Mathias Fröhlich wrote:we definitely have parts in a
simulation that just do not need to know that they run on osg/OpenGL.
Imagine you want to change the viewer library. All the physics is still the
same. By mixing osg classes into everything without any type abstraction in
between, you need to rewrite the whole pile of code. Even for parts that do
not depend on any viewing crap at all.
I already did so when I started to switch to osg and plenty of that work was
almost only for that reason we have all the sg types directly spread around.
So please avoid having osg::whatever spread around in the whole application
...
Appart from that, having more separate code paths in general for the
simulation parts and the viewer/scene parts would help for plenty of our
scalability problems a lot. So just thinking about general software design ...
So nothing is set in stone here, but it makes sense IMO to head into that
separation where possible/sensible.