John Wojnaroski writes: > 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.
I cannot find that message or my replies to it through Google, but it may have missed indexing some archived postings. When you asked about using properties, I probably suggested that you start either by looking at $FG_ROOT/preferences.xml or by saving a flight (using the drop-down menu). Now, fortunately, we have an interactive GUI property browser built right into FlightGear, as well as HTTP and telnet interfaces, so it's very easy to study the properties while the program is running. There are two important C++ APIs you have to learn for properties -- I added extensive documentation comments to both so that contributors won't have to guess how to use them. The low-level implementation is declared in simgear/misc/props.hxx, and Curt has autogenerated HTML documentation here: http://www.simgear.org/doxygen/props_8hxx.html Most of the time, though, you can get away with using the higher-level functions declared in src/Main/fg_props.hxx. Curt hasn't generated HTML documentation from this yet, but if you look at the file, you'll see about a 1:1 documentation:code ratio, and the comments are fairly easy to read. You can look at many parts of FlightGear to see how properties are being used in actual code. > 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 That's a valid point, and one that Norman Vine (whom I respect greatly) has made forcefully many times. Our problem is that our C++ code base is a mess of spaghetti code with stale methods and excruciating interdependencies -- some of it, like the HUD, isn't even recognizably object-oriented. Writing good, clean C++ code is hard, and refactoring old code is even harder. More importantly, the project was stalling badly a while ago because there were so few hard-core C++ programmers willing and able to contribute. I added the property manager especially so that non-programmers could contribute more easily, but it turned out that it was useful for programmers as well (witness Andy's rapid development of YASim) -- instead of having to learn dozens of inconsistent C++ interfaces, you have to learn only one property-tree structure and you can get and set whatever information you need. The filesystem idiom used in the property tree is familiar to many more people than C++ design patterns (which we don't use well anyway), and given the accelerated progress since we introduced the property manager, it seems to have been a success. > > 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. What's wrong with Microsoft? No, I'm just joking, and I think you misunderstood what I wrote. I apologize that I haven't had time to look at the OpenGC code yet -- FlightGear's a big project. Let me rephrase: I had assumed that your code was already in the FlightGear CVS somewhere, and that when there were no compilation errors, I hadn't broken it. > 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. Again, I cannot find this posting with Google, but the indexing may be incomplete; I also cannot find the message from Tony Peden a couple of months ago where he explained the gear properties to everyone in detail, because that would have most helpful. The gear control position is in /controls/gear-down which is either true or false. Actual gear information for each wheel is published by JSBSim under the /gear hierarchy, but we haven't really standardized that yet -- status reporting from the FDMs for aircraft parts is still something new, and subject to reorganization. YASim may be doing something totally different right now. Please feel free to participate in this discussion and contribute your suggestions as we try to standardize all of this, but remember, also, that we're not a big, impersonal organization like Microsoft, so please try not to use us as a target of any anger or frustration you might have -- everyone runs into code problems sometimes, and I've spent dozens of evenings trying to fix my own contributions that someone else accidentally broke. It's annoying, but it's also one of the true joys of open source, especially when you discover ways to improve your own code or add new features in the process. Like me, Curt, Jon Berndt, Tony Peden, Dave Luff, Andy Ross, and the rest of the main contributors are not paid for our FlightGear, and we do not have a big organization, documentation writers, and a tech-support call centre to back us up. I'm an independent XML consultant -- if my customers need something done, I have to drop FlightGear (and ignore all e-mail) until I'm finished, or else I might not have food or a house, much less a computer to use for contributing new code. We're all in the same position. All the best, David -- David Megginson [EMAIL PROTECTED] _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
