"Curtis L. Olson" <[EMAIL PROTECTED]> said: > Maybe what we need is several menu items such as: > > start at an airport on the ground > start relative to an airport in the air > start relative to a fix in the air > > Then each of these could have separate call back functions tied to the > "ok" which configured the /sim/presets/ tree correctly before calling > the presets-commit function. >
That's exactly what was coming to mind as I started reading your post. But see below... > > Isn't the advantage/purpose of the property tree to offer and easy interface > > through the command line, network connections, and configuration files? > > (Rather than short-cutting C++ class definitions, that is.) > > It's getting pretty late here, so I'm not following what you are > getting at with this last paragraph. I was pretty dull minded myself when writing this (been a rough week at work). The thing that bugged me was not the preset logic, but the fact that the altitude of the airport was stored into the presets. For example *after* teleporting to KBGR from KSFO the /sim/presets/altitude reflected the 350+/- altitude of KBGR's threshold. Probably that was done as a quick fix for the common dialog problem you describe above. Maybe radio buttons for onground/inair that are based on the previous selection would do the trick. Then it'd be up to the user to actually specify what they want to happen. In some ways a common dialog does make sense (from a usability prespective) and this would essentially solve the problem by placing it in the users control. Best, Jim _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
