> Here are a few ideas: > > - we could extend fgrun (to add such features as flight planning, AI > objects editing), > > - we could create another app, which would be meant to communicate with > FlightGear in realtime (probably via the telnet interface), something > more elaborate than the http interface, in the same way that fgrun does > for command-line options
I also thought about this as an option for a GUI. The main advantage would be that this approach ensures there's no GUI code in FG and there is a well designed API/Protocol to it. Writing alternative GUI's should be easy using that API/Protocol. Having the GUI seperated also makes it easy to distribute the apps across machines, i.e. having a simulator with an instructors workplace (changing weather, fail engines...) > - in any case, it would be best to make sure that FG is able to change > aircraft (FDM, 3D model, systems) on the fly, because that is probably > the only start-up-time setting that can't be changed so far once > FlightGear is running. That would be a great improvement. Having spend most of the weekend trying to install CVS versions of all the FG dependencies I only spent a few hours designing a new order/labeling in the menu (using QT Designer just because it's a graphical UI Designer). From that I think easy improvements can be made just by renaming things. For example the difference between 'Adjust view distance' and 'Adjust LOD ranges' is not obvious. It's only after you click one you notice it was the wrong :-) Thomas _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
