I've started to clean up the HUD code. I've moved all class-specific
code to the classes. Before, each class had an external initializer
that loaded the properties from the property tree and called a constructor
with *many* parameters. Now the constructors are only pointed to the
group node and fetch their stuff themselves. Now there are two questions:
1. I would like to create a HUD class that contains the generic
stuff (like setup, context, switching etc.), all of which is currently
a set of separate static functions. Should this be:
(a) an FGInstrumentMgr controlled class instance, and if so: should it
be moved to Instrumentation/HUD/?
(b) a subsystem on its own with an extra HUD::draw() method that's
called from the renderer (HUD::update() wouldn't be usable for drawing)?
(c) an unspecific, custom class?
Consider a possible render-to-texture HUD option in addition to the two
existing modes "OSD-like 2D-fullscreen mode (ufo)" and
"realistic-but-not-aircraft-
model-associated-3D-HUD (f16-3d)".
2. I want to drop the unflexible <loadfn> getters, and use <property>
instead, so that any HUD element can take its value from any property.
The current, ugly way is AFAIK due to the fact that the HUD code
predates the property code, so there wasn't much choice for the author
back then. Today really only properties make sense.
(d) can I simply switch to properties, if I make sure that all HUD
files in CVS get converted, and the result is identical (or otherwise
in agreement with the aircraft maintainer)? Or am I expected to
support both methods for one or two releases?
My preference is, of course, to switch and let <loadfn> die immediately. :-)
Erik, you looked into that a while ago, so you probably have specific
expectations? Anyone else?
m.
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
