Curtis L. Olson wrote:
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

Reply via email to