If /sim/highlighting/enabled is true, we highlight animated objects under the
pointer, and also highlight other objects that are animated by the same or
related properties.
The intent here is to be able to give a visual indication of what cockpit
controls do or what cockpit controls affect particular aircraft objects - for
example moving the pointer over the flaps will highlight the flaps and also
highlight any controls or rotary indicators in the cockpit that are associated
with the flaps.
To make this work, we have to discover associations between properties. This
is currently done for YASim (e.g. associations between /controls/flight/flaps
and /surface-positions/flap-pos-norm) and autopilot filters (e.g. with
the 777, digital filters associate /controls/flight/rudder-nul with
/fcs/fbw/yaw/rudder-ratio-out). We don't currently gather associations between
properties in JSBSim
We also detect associations between dialogs, menus and keypresses and
properties, which is used to populate /sim/highlighting/current with
information about dialogs, menus and keypresses that are associated with the
currently highlighted nodes' properties.
Details:
src/GUI/Highlight.cxx
src/GUI/Highlight.hxx
src/GUI/CMakeLists.txt
src/Main/fg_init.cxx
New subsystem called 'highlight', with support for registering and
recovering links between menus, dialogs, keypresses and OSG node
animations.
Provides a function Highlight::highlight_nodes() which highlights
related nodes using internal NodeHighlighting class, and populates
/sim/highlighting/current with information about related dialogs, menus and
keypresses.
The NodeHighlighting class works by making nodes use an alternative
StateSet which shows up as a distinct material on screen. We remember each
highlighted node's original StateSet so that we can un-highlight. We update
the material parameters using a listener for /sim/highlighting/material,
which allows some control over the appearence of highlighted nodes.
src/FDM/flight.cxx
src/FDM/flight.hxx
Added virtual method FGInterface::property_associations() which returns
property associations from the FDM. Default implementation returns empty
set. Implemented in YASim, but not (yet) in JSBSim. Uses a simple function
pointer at the moment to avoid requring FDMs to use recent C++ features.
src/FDM/YASim/FGFDM.cpp
src/FDM/YASim/FGFDM.hpp
src/FDM/YASim/YASim.cxx
src/FDM/YASim/YASim.hxx
Gathers information about property associations on startup such as
/controls/flight/flaps => /surface-positions/flap-pos-norm, then
YASim::property_associations() overrides default implementation to return
these associations.
src/Autopilot/analogcomponent.cxx
src/Autopilot/analogcomponent.hxx
src/Autopilot/digitalfilter.cxx
src/Autopilot/inputvalue.cxx
src/Autopilot/inputvalue.hxx
Filters now gather information about their input/output properties and
register with Highlight::add_property_property(). For example this makes
highlighting work on the 777, where pilot controls affect control surfaces
only via filters.
src/GUI/new_gui.cxx
Scan menus, keypresses and dialogs and register associations with
Highlight::add_*().
src/GUI/property_list.cxx
src/GUI/property_list.hxx
src/GUI/FGPUIDialog.cxx
Added <readonly> flag to property-list. If set, we don't show .. or . items
and don't respond to mouse/keyboard.
Used by fgdata's new Highlighting dialogue.
src/Model/acmodel.cxx
src/Model/acmodel.hxx
Visit the user aircraft's scene graph when it is loaded, gathering
information about osg::Node's that are animated by properties, and register
these associations with Highlight::add_property_node().
src/Viewer/renderer.cxx
When scanning for pick highlights, use Highlight::highlight_nodes() to
highlight animated objects under the pointer and related objects.
This can be used to validate atomic branches after individual members
have been changed.
(This is useful no matter how the discussion on aggregate property types
ends, and not meant to enforce/accelerate a decision.)
- this exposed a bizarre issue on Mac where dragging in <AGL/agl.h> in
extensions.hxx was pulling in all of Carbon to the global namespace
- very scary. As a result, I now need to explicitly include CoreFoundation
in fg_init.cxx.
- change SG_USING_STD(x) to using std::x
SimGear change. It changes all the SG_xxxx to be the 'real' includes, and gets
rid of many #ifdef SG_HAVE_STD_INCLUDES. As an added bonus, rather than
replacing 'SG_USING_NAMESPACE(std)' with 'using namespace std', I just fixed
the small number of places to use std:: explicitly. So we're no longer polluting
the global namespace with the entire contents of std, in many cases.
There is one more 'mechanical' change to come - getting rid of SG_USING_STD(X),
but I want to keep that separate from everything else. (There's another
mechnical change, replacing <math.h> with <cmath> and so on *everywhere*, but
one step at a time)
show "secret" values, that is: values of nodes with children. These
can be used like all normal (leaf) properties, but their values were
until now only shown in writeProperties() dumps. Also show the
number of attached listeners. Example: foo = 'bar' (string, AU, L3).
dialog.cxx: add warning message for broken <format>s; cosmetics
there's a bug that I had copied: update() checks each list node: if it
has no children, then a listener is attached. Later, when freeing the
children list, it assumed again that each node without children would
have a listener attached. This caused a crash when a node had children
before, but lost them in the meantime. Now we tried to remove a listener
where there never was one.
*many* years, so the property browser always leaked memory. I activated
this line in property_list.cxx and ... got a crash right there. So this
was the reason for it being commented out? Doing the same for now, until
I know the exact reason and can really fix it.
