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


Flightgear-devel mailing list

Reply via email to