Jon Stockill wrote:
Thomas Förster wrote:
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...)
With the added advantage of not bloating the simulator - gets my vote.
For what it's worth, I think that some sort of minimal built in gui for FG is still a good idea. FG already provides a lot of support for developing an external gui (i.e. for an operator/instructor station.) I have done exactly this for the ATC flight sim single engine trainer and it works quite well.
Agreed - the internal GUI we have at the moment, while not the prettiest available certainly gets the job done, and can be configured without having to resort to coding - it's perfectly adequate for the job. What I was against was multiple GUIs util different toolkits, as that would significantly increase the bloat, and make packaging flightgear an awful lot more complicated.
-- Jon Stockill [EMAIL PROTECTED]
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d