Norman Vine wrote: > Why -- all you need to do is document it > > Consider this scenario > I want my normal view down 20% slightly to the left > I can set these with the keys or whatever > I can now use the mouse to spin about do what ever in mouse mode > when I leave mouse mode I am back at my normal position
Right. You get this feature, but only at the cost of using both the mouse view code and the property view code everywhere that the view is interpreted. David's suggestion had you pushing and popping (or just saving and restoring, if we decide we don't need more than two levels of state) the view state inside the mouse code. This affects only the mouse code, and nowhere else. Code dependencies are bad, and this has less. To pick a specific example: the virtual panel code (or, say, the sun position code) doesn't want to care about view offset at all. It just wants to know where to draw. It *certainly* doesn't want to care about mouse view vs. property view. There should be one, and only one, place where clients go to get the current view orientation and location. Andy -- Andrew J. Ross NextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
