Jim Wilson wrote:
Harald said:

- 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.

---------- Boris

Flightgear-devel mailing list

Reply via email to