- it's an external application because there is no need to put it in FG code and there would be some complication with the display and keyboard part ;
It would actually be very nice to have a FlightGear subsystem for this. Even nicer if it was possible to configure features via an xml config file (since not all FMCs are exactly the same). You can still manipulate data through the property system.
It should be very easy to use the NewGUI feature (xml gui) to present a display with buttons as well as pc keyboard input.
Having recently thought about means to add FMC functionality to FlightGear myself I would agree with Jim here, there are really many different kinds of FMCs - some with pretty basic functionality and others providing pretty advanced stuff.
So, having a basic subsystem as a backend and using XML files as well as possibly also some kind of basic skinning mechanism would certainly be
a good approach for the whole FMC thing, since it would not be specific
to a certain model or implementation but would rather provide a general
dynamic framework for FMC creation/customization - pretty much like
the current appraoch to define aircraft or panels.
Regarding the GUI, this may be really mainly about adding support for skins and defining clickable regions and possibly different states of buttons - but I would not be that much in favour of using basic PUI elements for these purposes, this might be okay in the beginning but later there should be really support to load a "skin" and assign certain regions to certain functions/actions or simply events that can be dealt with by using Nasal.
Most of the internal logics could certainly be very well handled using Nasal that then accesses the flight parameters via the Property Tree directly. The maths involved for the FMC calculations should also be possible to be realized using Nasal, I'd think - and then there'd still be the option of adding the more complicated stuff as a separate command.
That way the CDU could be implemented using some basic skinning mechanism and defining those regions that are "clickable" and where Nasal should act and then there would need to be a general control for screen output, possibly defining some basics like fonts, rows/colums and available colors - as well as possibly some minor controls like LEDs to display a status information or anything like that.
An approach like the one suggested by Jim would certainly have the potential to add many variations of FMCs simply because it would be mainly a thing of specifying the appeareance and logics using a XML file with some Nasal code.
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d