On Thu, 2005-12-01 at 11:56, Buchanan, Stuart wrote: > > I propose then that every single instrument on the cockpit has the > > ability to be double-clicked, and if so then a separate draggable window > > appears containing a magnified view of that same instrument.
> Personally I think this is a fine idea, and indeed gets around the > challenge of having generic dialog boxes that don't match specific > instruments. I'm not sure whether it would need to be magnified, it would > be sufficient just to display them at "normal" resolution (e.g. 128X128 > for most round gauges, 256x60 (ish) for radio stacks). > On my screen I can just about read the round gauges and radios and can't read the compass (on the 3D Cessna). The 2D cockpit is much more legible. Hence the comment about magnification. > However, I don't know whether we can easily display the gauges in windows > by themselves - I'm not familiar with the graphics routines we have, but I > suspect that we are stuck with a single rendered window (as opposed to > dialogs created using GUI widgets), unless we want to take huge perf hits. > I was thinking of using the machine's underlying windows system for these popup per-instrument displays. So that would be GTK or similar on X-Windows and native MS Windows API on M$Windows machines. Alternatively, FlightGear could standardise on GTK for writing the things, and use the fact that there already are "GTK-on-M$Windows" and "GTK-on-MacOS" libraries out there that would take care of the platform-dependencies. > I think the main issue here is with the radios, GPS and autopilot. One > simple solution would be to create a "radio" panel for the plane > containing these components, the visibility of which could be toggled > either from the menu, or from a keypress. > I would leave the OpenGL engine to display the panel as it does now, but some instruments (at the users' discretion) may get duplicated in their draggable, scalable windows. > - The panel couldn't be dragged and dropped - though it could be shifted > using the normal controls. It could, if it was written to employ the ordinary windows-system windows, not be part of the OpenGL main display window. > - I don't think we'd be able to use the double-click idea, as that > normally causes two increments/decrements. > Double-click is normally detected as such really low down and doesn't normally get confused with two single-clicks. > - You can bind the key normally used for the radio dialog to displaying > this specific panel. > Indeed. And there's another possible plus side. There was a thread here a few weeks back about the serious flightsim-heads who like to build physical cockpits and have "real" instruments. Apparently, one way to get the effect of real instruments on a budget is to fit an LCD panel behind cutouts in a fascia plate and display the instruments on that LCD panel. Well, doing this gets a load easier if we've already written the code for every instrument to be able to render itself (magnified) in photo-realistic style in individual windows. The builder of a fake cockpit can then drag all the magnified instruments to wherever they're needed behind the cutouts in the fascia, and hey presto! Job done (pretty much). FlightGear would need to be able to remember at start-up how the user wants to display any instruments that have to start in this "windowed" mode: i.e their magnification (or window-size) and window location (X and Y coords on which physical screen). Steve. _______________________________________________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
