Hi... Overall good ideas, but it might not need to be so complicated. The idea I originally had in mind was having three possible window configurations, with 1-3 gauges. 1 gauge is what we currently have, 2 would be side-by-side, and 3 would be a triangle (with 2 gauges at the top and 1 centered below). This mirrors the way Project Magenta does things, and I like their layout.
I'd prefer to keep all of the configuration stuff in config files that are parsed at runtime, rather than creating custom builds for each setup. This is especially important for Windows/FS200x users who may not (probably don't) even have a compiler, let alone know how to use one. So, the official Linux distro should include _all_ possible gauges and data sources, and likewise for the Windows version. Incompatibility between data sources can be handled with simple IFDEFs, and the gauges should work correctly on all platforms (even if they have to use the default values for parameter's not provided by a given data source). As far as directories go, take a look at the current CVS before changing too much. I'm a bit concerned that there are several different versions of OpenGC floating around now that aren't all in sync with each other. Establishing a "master" version should be a priority. I would also hesitate to break code down into panels at the directory level (although having separate directories for interfaces, gauges, and components is a good idea), since it should be up to the end-user to establish what exactly a panel is via config files at runtime; runtime configuration would involve picking Gauges, and not GaugeComponents (I don't want to get too crazy). So, you might define a config file, which (to make up syntax off the top of my head) would look like: DataSource = FG PanelLayout = 2gauge LeftGauge = Boeing777PFD RightGauge = Boeing777ND etc... It's also possible (not in the current code, but in theory) to have multiple ogcRenderWindows, which would most likely be preferable to have separate processes. The data source can be shared without much difficultly, and RenderWindows are designed to be more-or-less independent of everything except for the FontManager and DataSource. What do you think? I feel pretty strongly about having only one distro per platform, with configuration handled at runtime, unless there's a good argument against it (which I'm not discounting). -Damion- --On Saturday, December 01, 2001 11:09 PM -0800 John Wojnaroski <[EMAIL PROTECTED]> wrote: > > Hi Ross, > > Giving some thought on how to organize the OpenGC files. would have used > private mail but I don't have all your individual emails. > Given the size of monitors today, it is possible to fit more than one > display panel on a single screen. For example, a 19" screen can hold a > PFD and ND panel with a AFDS MCP above it. With a smaller 15" monitor to > the right you can place an EICAS primary and secondary, if you have a > third you can now provide an MCDU and also use it as a secondary MCP for > the secondary EICAS. Or a 15'' as a PFD and a 19" for the ND and EICAS. > or .... > Each monitor would/could be driven by an app and interconnected via the > LAN to the FG side and each other. If one has the resources you might > want to have a dedicated FMC to run the nav and generate commands to send > to the FCC's (which could be on the FG side or the Opengc side that > calculates the control commands to send to FG) or another scene > generator, or run some non-display apps in the background on each machine > to distribute the compute load, or whatever. In general, the idea is to > allow the user to mix and match the various applications to fit the > particular hardware configuration and compute resources. > As a first cut, seems reasonable to create a directory for each display > (entity) and build libraries for each; then envoke the linker with the > list of libraries to build the app as desired. it might get a little > tricky trying to get two or three panels in the right locations, but the > geometry of the flight deck and locations are static and known a priori > so it seems doable with .xml or .ini files at startup. > ATM I'm trying to relocate the files and some stubs into a set of > directories and create the associated makefiles and see what falls out. I > ' ve grown kind of fond ;-) of the FG structure so it will probably wind > up looking a lot like that. There will be a main, a directory for each > panel and entity, a network, some utilities (lots of strings and msgs), > and so forth. Also working on a brief description doc for all the various > displays and modes. (There is a lot, and I mean a LOT of code to design!) > > Any ideas, comments, opinions, suggestions, -- fire away! > > Regards > John W. > > Comments, suggestions, > _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
