> > Is the OpenGC interface in the FlightGear code base, or separate?
It's in the base, and if you had taken the care and time and listened to other's inputs and work efforts you should have realized that! In general, it is a good idea to follow the advice that has > come across this list during earlier discussions (especially from > Curt, Andy, and me), and rely on the property manager rather than the > C++ interfaces. Excuse me, but if you go back you will see that I allowed to the fact that I was unclear on the idea of the properties, but was willing to give it a go. If this is truely an open source project then other ideas and opinions need to be honored, not just the few with dictatorial commit authority! Property names do change occasionally, but the > breakages those changes cause are much less violent (and easy to debug > using the property browser). > I don't agree with that. IMHO that might be true if one is already cognizant and comfortable with the architecture. C++ is a common reference point and moving away from it adds obfuscation. And the more I think about it the less I like it. If one is writing code for a small group then properties might be okay, but in a larger group and open source efforts it seems that changes need to move more slowly and at a more measured pace > As Curt has mentioned recently, we do plan to remove most of > FGInterface as well, when we have the chance; we are able to test that > nothing in the FlightGear code base breaks, but obviously, we have no > way to test external code. Whoa! The arrogance of it all. Sounds like the microsoft way. Do it my way or no way. If your code breaks it's your fault. >If you're still using FGInterface calls to get the current altitude, velocities, etc., I recommend switching to > properties as soon as possible to avoid future problems. > You still haven't honored my request for information on where the gear property values are located or is it a case that each developer is free to defined the properties as they see fit within their own context. If that is the case then I don't think it will be possible to build and maintain an interface to external programs. In closing, I reference the following: <Are there any developers out there with nothing better to do who'd be <interested in getting the Open Glass Cockpit project building on Linux <and integrated with FlightGear? < < http://www.opengc.org < <Regards, < <Curt. <-- <Curtis Olson Intelligent Vehicles Lab FlightGear Project <Twin Cities [EMAIL PROTECTED] [EMAIL PROTECTED] <Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org Well, it builds on Linux , but integration is a dance and it takes two partners... Regards John W. _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
