Manuel Bessler wrote:
On Fri, Aug 06, 2004 at 01:37:11AM +0200, Boris Koenig wrote:
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
Yes, and this would not depend whether the FMC in internal or external
to fgfs.
That's somewhat correct, one could certain re-use such code if it
was general enough and could then optionally integrate it natively
into FlightGear as soon as it's mature enough for that purpose.
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.
Yeah, Nasal seems to be a way to implement a FMC within flightgear.
IF you really intend to link to SimGear (I read about it in the
thread) you could still use Nasal even externally, as Nasal is
not only a separate linkable lib available but also seems to
be integrated into SimGear directly, so there's no reason to
differentiate between a FlightGear based implementation and
a SimGear based version I think.
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.
This is something you'd wanna have in both variants, FMC implemented
inside of fgfs or outside as a standalone program.
Maybe Harald can provide some more details about what he want to
take into consideration and if there are any things that weren't
yet mentioned in that thread.
I guess the person who wirtes the software will ultimately decide.
Right, but as soon as it's ready there shouldn't be any reasons
for other people to add custom stuff, stuff which might not have
been taken into account in the original version - a modular
implementation would then of course come in handy.
Or... how about implementing it outside of flightgear at first and then
hooking it in when the code is somewhat stable?
dito :-)
I like the unix philosophy: for every task a seperate program that does
only the one thing its designed for. ( make each program do one thing
well)
I know this is not always appliceable esp. for a flightsimulator, but it
could be a good idea in this case.
I don't even mention that this whole thread ultimately brings us back
to the plugins discussion :-)
-------
Boris
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
