fly/fgdata
1
0
Fork 0
Code Activity
fgdata/gui/dialogs/autopilot.xml

540 lines
19 KiB
XML
Raw Normal View History

Switch to new, unified autopilot dialog, bound to the menu and to F11.
2003-01-18 22:04:50 +00:00
<?xml version="1.0"?>
<PropertyList>
Update autopilot dialog to use a new flag, to give feedback when the GPS/route-manager is driving the true heading.
2010-03-27 12:19:52 +00:00
<name>autopilot</name>
<layout>vbox</layout>
<!--
GUI layout management and a few visual/eye-candy modifications. See DOCS/README.layout in the base package for details, along with the modified dialog files.
2004-05-12 15:37:17 +00:00
/autopilot/locks/altitude
/autopilot/locks/heading
/autopilot/locks/speed
Added a Flightdirector Mode checkbox to the Autopilot dialog (Autopilot on / off) for the Primus 1000 system....
2007-03-18 04:18:20 +00:00
/autopilot/locks/passive-mode
GUI layout management and a few visual/eye-candy modifications. See DOCS/README.layout in the base package for details, along with the modified dialog files.
2004-05-12 15:37:17 +00:00
/autopilot/settings/heading-bug-deg
/autopilot/settings/target-agl-ft
/autopilot/settings/target-altitude-ft
/autopilot/settings/target-aoa-deg
/autopilot/settings/target-pitch-deg
/autopilot/settings/target-speed-kt
/autopilot/settings/true-heading-deg
/autopilot/settings/vertical-speed-fpm
-->
Gray-out dependant options, uniform close button
2010-12-15 12:43:09 +00:00
<group>
<layout>hbox</layout>
<empty><stretch>1</stretch></empty>
<text>
<label>Autopilot Settings</label>
</text>
<empty><stretch>1</stretch></empty>
<button>
<pref-width>16</pref-width>
<pref-height>16</pref-height>
<legend></legend>
<default>1</default>
<keynum>27</keynum>
<border>2</border>
<binding>
<command>dialog-close</command>
</binding>
<binding>
<command>dialog-apply</command>
</binding>
</button>
</group>
Update autopilot dialog to use a new flag, to give feedback when the GPS/route-manager is driving the true heading.
2010-03-27 12:19:52 +00:00
<hrule/>
<nasal>
<open>
initialize input field properties if necessary
2006-04-06 07:10:13 +00:00
## manage one AP property group with checkbox and radio buttons
- now that XML dialogs run their own Nasal namespace and have <open> and <close> block, remove autopilot helper file autopilot.nas and (re)implement its functionality in autopilot.xml - make AP dialog "bidirectional" and "live": all input fields are <live> (i.e. they are updated as the autopilot settings are changed, for example by panel actions or property browser changes) - dialog input is only forwarded to the AP; no direct checkbox/radiobutton handling through widget operation, instead: - changes to the AP properties operate checkboxes/radiobuttons This makes the AP dialog always reflect the AP state. If the AP refuses one setting and sets it back to something else, then the dialog will immediately react and show the actual setting.
2006-04-05 20:24:21 +00:00
#
Group = {
new : func(name, options) {
var m = { parents: [Group] };
m.name = name;
m.enabled = 0;
m.mode = options[0];
m.options = [];
some more object-oriented-ness & cleanup
2006-04-06 09:48:38 +00:00
var locks = props.globals.getNode("/autopilot/locks", 1);
if (locks.getNode(name) == nil or locks.getNode(name, 1).getValue() == nil) {
locks.getNode(name, 1).setValue("");
- now that XML dialogs run their own Nasal namespace and have <open> and <close> block, remove autopilot helper file autopilot.nas and (re)implement its functionality in autopilot.xml - make AP dialog "bidirectional" and "live": all input fields are <live> (i.e. they are updated as the autopilot settings are changed, for example by panel actions or property browser changes) - dialog input is only forwarded to the AP; no direct checkbox/radiobutton handling through widget operation, instead: - changes to the AP properties operate checkboxes/radiobuttons This makes the AP dialog always reflect the AP state. If the AP refuses one setting and sets it back to something else, then the dialog will immediately react and show the actual setting.
2006-04-05 20:24:21 +00:00
}
some more object-oriented-ness & cleanup
2006-04-06 09:48:38 +00:00
m.lock = locks.getNode(name);
- now that XML dialogs run their own Nasal namespace and have <open> and <close> block, remove autopilot helper file autopilot.nas and (re)implement its functionality in autopilot.xml - make AP dialog "bidirectional" and "live": all input fields are <live> (i.e. they are updated as the autopilot settings are changed, for example by panel actions or property browser changes) - dialog input is only forwarded to the AP; no direct checkbox/radiobutton handling through widget operation, instead: - changes to the AP properties operate checkboxes/radiobuttons This makes the AP dialog always reflect the AP state. If the AP refuses one setting and sets it back to something else, then the dialog will immediately react and show the actual setting.
2006-04-05 20:24:21 +00:00
m.active = dlg.getNode(name ~ "-active", 1);
some more object-oriented-ness & cleanup
2006-04-06 09:48:38 +00:00
- now that XML dialogs run their own Nasal namespace and have <open> and <close> block, remove autopilot helper file autopilot.nas and (re)implement its functionality in autopilot.xml - make AP dialog "bidirectional" and "live": all input fields are <live> (i.e. they are updated as the autopilot settings are changed, for example by panel actions or property browser changes) - dialog input is only forwarded to the AP; no direct checkbox/radiobutton handling through widget operation, instead: - changes to the AP properties operate checkboxes/radiobuttons This makes the AP dialog always reflect the AP state. If the AP refuses one setting and sets it back to something else, then the dialog will immediately react and show the actual setting.
2006-04-05 20:24:21 +00:00
foreach (var o; options) {
some more object-oriented-ness & cleanup
2006-04-06 09:48:38 +00:00
var node = dlg.getNode(o);
- now that XML dialogs run their own Nasal namespace and have <open> and <close> block, remove autopilot helper file autopilot.nas and (re)implement its functionality in autopilot.xml - make AP dialog "bidirectional" and "live": all input fields are <live> (i.e. they are updated as the autopilot settings are changed, for example by panel actions or property browser changes) - dialog input is only forwarded to the AP; no direct checkbox/radiobutton handling through widget operation, instead: - changes to the AP properties operate checkboxes/radiobuttons This makes the AP dialog always reflect the AP state. If the AP refuses one setting and sets it back to something else, then the dialog will immediately react and show the actual setting.
2006-04-05 20:24:21 +00:00
if (node == nil) {
node = dlg.getNode(o, 1);
node.setBoolValue(0);
}
append(m.options, node);
autopilot.xml: pick up initial mode route-managers.xml: cosmetics
2006-05-10 20:24:21 +00:00
if (m.lock.getValue() == o) {
m.mode = o;
}
- now that XML dialogs run their own Nasal namespace and have <open> and <close> block, remove autopilot helper file autopilot.nas and (re)implement its functionality in autopilot.xml - make AP dialog "bidirectional" and "live": all input fields are <live> (i.e. they are updated as the autopilot settings are changed, for example by panel actions or property browser changes) - dialog input is only forwarded to the AP; no direct checkbox/radiobutton handling through widget operation, instead: - changes to the AP properties operate checkboxes/radiobuttons This makes the AP dialog always reflect the AP state. If the AP refuses one setting and sets it back to something else, then the dialog will immediately react and show the actual setting.
2006-04-05 20:24:21 +00:00
}
replace depreciated cmdarg() in listener functions by regular arg
2007-10-15 18:59:34 +00:00
m.listener = setlistener(m.lock, func(n) { m.update(n.getValue()) }, 1);
- now that XML dialogs run their own Nasal namespace and have <open> and <close> block, remove autopilot helper file autopilot.nas and (re)implement its functionality in autopilot.xml - make AP dialog "bidirectional" and "live": all input fields are <live> (i.e. they are updated as the autopilot settings are changed, for example by panel actions or property browser changes) - dialog input is only forwarded to the AP; no direct checkbox/radiobutton handling through widget operation, instead: - changes to the AP properties operate checkboxes/radiobuttons This makes the AP dialog always reflect the AP state. If the AP refuses one setting and sets it back to something else, then the dialog will immediately react and show the actual setting.
2006-04-05 20:24:21 +00:00
return m;
},
some more object-oriented-ness & cleanup
2006-04-06 09:48:38 +00:00
del : func {
removelistener(me.listener);
},
- now that XML dialogs run their own Nasal namespace and have <open> and <close> block, remove autopilot helper file autopilot.nas and (re)implement its functionality in autopilot.xml - make AP dialog "bidirectional" and "live": all input fields are <live> (i.e. they are updated as the autopilot settings are changed, for example by panel actions or property browser changes) - dialog input is only forwarded to the AP; no direct checkbox/radiobutton handling through widget operation, instead: - changes to the AP properties operate checkboxes/radiobuttons This makes the AP dialog always reflect the AP state. If the AP refuses one setting and sets it back to something else, then the dialog will immediately react and show the actual setting.
2006-04-05 20:24:21 +00:00
initialize input field properties if necessary
2006-04-06 07:10:13 +00:00
## handle checkbox
- now that XML dialogs run their own Nasal namespace and have <open> and <close> block, remove autopilot helper file autopilot.nas and (re)implement its functionality in autopilot.xml - make AP dialog "bidirectional" and "live": all input fields are <live> (i.e. they are updated as the autopilot settings are changed, for example by panel actions or property browser changes) - dialog input is only forwarded to the AP; no direct checkbox/radiobutton handling through widget operation, instead: - changes to the AP properties operate checkboxes/radiobuttons This makes the AP dialog always reflect the AP state. If the AP refuses one setting and sets it back to something else, then the dialog will immediately react and show the actual setting.
2006-04-05 20:24:21 +00:00
#
enable : func {
me.enabled = me.active.getBoolValue();
some more object-oriented-ness & cleanup
2006-04-06 09:48:38 +00:00
me.lock.setValue(me.enabled ? me.mode : "");
- now that XML dialogs run their own Nasal namespace and have <open> and <close> block, remove autopilot helper file autopilot.nas and (re)implement its functionality in autopilot.xml - make AP dialog "bidirectional" and "live": all input fields are <live> (i.e. they are updated as the autopilot settings are changed, for example by panel actions or property browser changes) - dialog input is only forwarded to the AP; no direct checkbox/radiobutton handling through widget operation, instead: - changes to the AP properties operate checkboxes/radiobuttons This makes the AP dialog always reflect the AP state. If the AP refuses one setting and sets it back to something else, then the dialog will immediately react and show the actual setting.
2006-04-05 20:24:21 +00:00
},
initialize input field properties if necessary
2006-04-06 07:10:13 +00:00
## handle radiobuttons
- now that XML dialogs run their own Nasal namespace and have <open> and <close> block, remove autopilot helper file autopilot.nas and (re)implement its functionality in autopilot.xml - make AP dialog "bidirectional" and "live": all input fields are <live> (i.e. they are updated as the autopilot settings are changed, for example by panel actions or property browser changes) - dialog input is only forwarded to the AP; no direct checkbox/radiobutton handling through widget operation, instead: - changes to the AP properties operate checkboxes/radiobuttons This makes the AP dialog always reflect the AP state. If the AP refuses one setting and sets it back to something else, then the dialog will immediately react and show the actual setting.
2006-04-05 20:24:21 +00:00
#
set : func(mode) {
me.mode = mode;
foreach (var o; me.options) {
o.setBoolValue(o.getName() == mode);
}
if (me.enabled) {
some more object-oriented-ness & cleanup
2006-04-06 09:48:38 +00:00
me.lock.setValue(mode);
- now that XML dialogs run their own Nasal namespace and have <open> and <close> block, remove autopilot helper file autopilot.nas and (re)implement its functionality in autopilot.xml - make AP dialog "bidirectional" and "live": all input fields are <live> (i.e. they are updated as the autopilot settings are changed, for example by panel actions or property browser changes) - dialog input is only forwarded to the AP; no direct checkbox/radiobutton handling through widget operation, instead: - changes to the AP properties operate checkboxes/radiobuttons This makes the AP dialog always reflect the AP state. If the AP refuses one setting and sets it back to something else, then the dialog will immediately react and show the actual setting.
2006-04-05 20:24:21 +00:00
}
},
initialize input field properties if necessary
2006-04-06 07:10:13 +00:00
## update checkboxes/radiobuttons state from the AP (listener callback)
- now that XML dialogs run their own Nasal namespace and have <open> and <close> block, remove autopilot helper file autopilot.nas and (re)implement its functionality in autopilot.xml - make AP dialog "bidirectional" and "live": all input fields are <live> (i.e. they are updated as the autopilot settings are changed, for example by panel actions or property browser changes) - dialog input is only forwarded to the AP; no direct checkbox/radiobutton handling through widget operation, instead: - changes to the AP properties operate checkboxes/radiobuttons This makes the AP dialog always reflect the AP state. If the AP refuses one setting and sets it back to something else, then the dialog will immediately react and show the actual setting.
2006-04-05 20:24:21 +00:00
#
update : func(mode) {
me.enabled = (mode != "");
me.active.setBoolValue(me.enabled);
if (mode == "") {
mode = me.mode;
}
foreach (var o; me.options) {
o.setBoolValue(o.getName() == mode);
}
},
};
autopilot.xml: pick up initial mode route-managers.xml: cosmetics
2006-05-10 20:24:21 +00:00
## create and initialize input field properties if necessary
#
var apset = props.globals.getNode("/autopilot/settings", 1);
foreach (var p; ["heading-bug-deg", "true-heading-deg", "vertical-speed-fpm",
"target-pitch-deg", "target-aoa-deg", "target-altitude-ft",
"target-agl-ft", "target-speed-kt"]) {
if ((var n = apset.getNode(p)) == nil or n.getType() == "NONE") {
apset.getNode(p, 1).setDoubleValue(0);
}
}
- now that XML dialogs run their own Nasal namespace and have <open> and <close> block, remove autopilot helper file autopilot.nas and (re)implement its functionality in autopilot.xml - make AP dialog "bidirectional" and "live": all input fields are <live> (i.e. they are updated as the autopilot settings are changed, for example by panel actions or property browser changes) - dialog input is only forwarded to the AP; no direct checkbox/radiobutton handling through widget operation, instead: - changes to the AP properties operate checkboxes/radiobuttons This makes the AP dialog always reflect the AP state. If the AP refuses one setting and sets it back to something else, then the dialog will immediately react and show the actual setting.
2006-04-05 20:24:21 +00:00
var dlg = props.globals.getNode("/sim/gui/dialogs/autopilot", 1);
# - first entry ("heading" etc.) is the target property in /autopilot/locks/ *and*
# the checkbox state property name (with "-active" appended);
# - second entry is a list of available options for the /autopilot/locks/* property
# and used as radio button state property; the first list entry is used as default
#
var hdg = Group.new("heading", ["dg-heading-hold", "wing-leveler", "true-heading-hold", "nav1-hold"]);
var vel = Group.new("speed", ["speed-with-throttle", "speed-with-pitch-trim"]);
var alt = Group.new("altitude", ["altitude-hold", "vertical-speed-hold", "pitch-hold",
"aoa-hold", "agl-hold", "gs1-hold"]);
</open>
Update autopilot dialog to use a new flag, to give feedback when the GPS/route-manager is driving the true heading.
2010-03-27 12:19:52 +00:00
<close>
some more object-oriented-ness & cleanup
2006-04-06 09:48:38 +00:00
hdg.del();
vel.del();
alt.del();
- now that XML dialogs run their own Nasal namespace and have <open> and <close> block, remove autopilot helper file autopilot.nas and (re)implement its functionality in autopilot.xml - make AP dialog "bidirectional" and "live": all input fields are <live> (i.e. they are updated as the autopilot settings are changed, for example by panel actions or property browser changes) - dialog input is only forwarded to the AP; no direct checkbox/radiobutton handling through widget operation, instead: - changes to the AP properties operate checkboxes/radiobuttons This makes the AP dialog always reflect the AP state. If the AP refuses one setting and sets it back to something else, then the dialog will immediately react and show the actual setting.
2006-04-05 20:24:21 +00:00
</close>
Update autopilot dialog to use a new flag, to give feedback when the GPS/route-manager is driving the true heading.
2010-03-27 12:19:52 +00:00
</nasal>
<group>
- now that XML dialogs run their own Nasal namespace and have <open> and <close> block, remove autopilot helper file autopilot.nas and (re)implement its functionality in autopilot.xml - make AP dialog "bidirectional" and "live": all input fields are <live> (i.e. they are updated as the autopilot settings are changed, for example by panel actions or property browser changes) - dialog input is only forwarded to the AP; no direct checkbox/radiobutton handling through widget operation, instead: - changes to the AP properties operate checkboxes/radiobuttons This makes the AP dialog always reflect the AP state. If the AP refuses one setting and sets it back to something else, then the dialog will immediately react and show the actual setting.
2006-04-05 20:24:21 +00:00
<layout>hbox</layout>
Update autopilot dialog to use a new flag, to give feedback when the GPS/route-manager is driving the true heading.
2010-03-27 12:19:52 +00:00
<default-padding>8</default-padding>
<group>
<!-- Heading -->
<layout>vbox</layout>
<group>
<layout>hbox</layout>
<checkbox>
<label>Heading Control</label>
<halign>fill</halign>
<property>/sim/gui/dialogs/autopilot/heading-active</property>
<live>true</live>
<binding>
<command>dialog-apply</command>
</binding>
<binding>
<command>nasal</command>
<script>hdg.enable()</script>
</binding>
</checkbox>
</group>
<group>
<layout>table</layout>
<text>
<label>Wings Level</label>
<halign>right</halign>
<row>0</row>
<col>0</col>
</text>
<radio>
<row>0</row>
<col>1</col>
<property>/sim/gui/dialogs/autopilot/wing-leveler</property>
<live>true</live>
<binding>
<command>nasal</command>
<script>hdg.set("wing-leveler")</script>
</binding>
</radio>
<text>
<label>Heading Bug</label>
<halign>right</halign>
<row>1</row>
<col>0</col>
</text>
<radio>
<row>1</row>
<col>1</col>
<property>/sim/gui/dialogs/autopilot/dg-heading-hold</property>
<live>true</live>
<binding>
<command>nasal</command>
<script>hdg.set("dg-heading-hold")</script>
</binding>
</radio>
<input>
<row>1</row>
<col>2</col>
<property>/autopilot/settings/heading-bug-deg</property>
<live>true</live>
<binding>
<command>dialog-apply</command>
</binding>
</input>
<text>
<label>True Heading</label>
<halign>right</halign>
<row>2</row>
<col>0</col>
<visible>
<not>
<property>/autopilot/settings/gps-driving-true-heading</property>
</not>
</visible>
</text>
<!-- alternate UI for above, when GPS is controlling -->
<text>
<visible>
<property>/autopilot/settings/gps-driving-true-heading</property>
</visible>
<label>GPS/FMS Heading</label>
<halign>right</halign>
<row>2</row>
<col>0</col>
</text>
<radio>
<row>2</row>
<col>1</col>
<property>/sim/gui/dialogs/autopilot/true-heading-hold</property>
<live>true</live>
<binding>
<command>nasal</command>
<script>hdg.set("true-heading-hold")</script>
</binding>
</radio>
<input>
<visible>
<not>
<property>/autopilot/settings/gps-driving-true-heading</property>
</not>
</visible>
<row>2</row>
<col>2</col>
<property>/autopilot/settings/true-heading-deg</property>
<live>true</live>
<binding>
<command>dialog-apply</command>
</binding>
</input>
<!-- alternate UI for above, when GPS is controlling -->
<text>
<visible>
<property>/autopilot/settings/gps-driving-true-heading</property>
</visible>
<halign>right</halign>
<row>2</row>
<col>2</col>
<label>MMMM</label>
<format>%3.0f*</format>
<property>/autopilot/settings/true-heading-deg</property>
<live>true</live>
</text>
<text>
<label>NAV1 CDI Course</label>
<halign>right</halign>
<row>3</row>
<col>0</col>
</text>
<radio>
<row>3</row>
<col>1</col>
<property>/sim/gui/dialogs/autopilot/nav1-hold</property>
<live>true</live>
<binding>
<command>nasal</command>
<script>hdg.set("nav1-hold")</script>
</binding>
</radio>
</group>
<hrule/>
<group>
<layout>hbox</layout>
<checkbox>
<label>Velocity Control</label>
<halign>fill</halign>
<property>/sim/gui/dialogs/autopilot/speed-active</property>
<live>true</live>
<binding>
<command>dialog-apply</command>
</binding>
<binding>
<command>nasal</command>
<script>vel.enable()</script>
</binding>
</checkbox>
</group>
<group>
<layout>table</layout>
<text>
<label>Speed with Throttle</label>
<halign>right</halign>
<row>0</row>
<col>0</col>
</text>
<radio>
<row>0</row>
<col>1</col>
<property>/sim/gui/dialogs/autopilot/speed-with-throttle</property>
<live>true</live>
<binding>
<command>nasal</command>
<script>vel.set("speed-with-throttle")</script>
</binding>
</radio>
<input>
<row>0</row>
<col>2</col>
<rowspan>2</rowspan>
<property>/autopilot/settings/target-speed-kt</property>
<live>true</live>
<binding>
<command>dialog-apply</command>
</binding>
</input>
<text>
<label>Speed with Pitch</label>
<halign>right</halign>
<row>1</row>
<col>0</col>
</text>
<radio>
<row>1</row>
<col>1</col>
<property>/sim/gui/dialogs/autopilot/speed-with-pitch-trim</property>
<live>true</live>
<binding>
<command>nasal</command>
<script>vel.set("speed-with-pitch-trim")</script>
</binding>
</radio>
</group>
</group>
<!-- End of Heading/Speed -->
<vrule/>
<group>
<!-- Pitch/Altitude -->
<layout>vbox</layout>
<group>
<layout>hbox</layout>
<checkbox>
<label>Pitch/Altitude Control</label>
<halign>fill</halign>
<property>/sim/gui/dialogs/autopilot/altitude-active</property>
<live>true</live>
<binding>
<command>dialog-apply</command>
</binding>
<binding>
<command>nasal</command>
<script>alt.enable()</script>
</binding>
</checkbox>
</group>
<group>
<layout>table</layout>
<text>
<label>Vertical Speed</label>
<halign>right</halign>
<row>0</row>
<col>0</col>
</text>
<radio>
<row>0</row>
<col>1</col>
<property>/sim/gui/dialogs/autopilot/vertical-speed-hold</property>
<live>true</live>
<binding>
<command>nasal</command>
<script>alt.set("vertical-speed-hold")</script>
</binding>
</radio>
<input>
<row>0</row>
<col>2</col>
<property>/autopilot/settings/vertical-speed-fpm</property>
<live>true</live>
<binding>
<command>dialog-apply</command>
</binding>
</input>
<text>
<label>Pitch Hold</label>
<halign>right</halign>
<row>1</row>
<col>0</col>
</text>
<radio>
<row>1</row>
<col>1</col>
<property>/sim/gui/dialogs/autopilot/pitch-hold</property>
<live>true</live>
<binding>
<command>nasal</command>
<script>alt.set("pitch-hold")</script>
</binding>
</radio>
<input>
<row>1</row>
<col>2</col>
<property>/autopilot/settings/target-pitch-deg</property>
<live>true</live>
<binding>
<command>dialog-apply</command>
</binding>
</input>
<text>
<label>AoA Hold</label>
<halign>right</halign>
<row>2</row>
<col>0</col>
</text>
<radio>
<row>2</row>
<col>1</col>
<property>/sim/gui/dialogs/autopilot/aoa-hold</property>
<live>true</live>
<binding>
<command>nasal</command>
<script>alt.set("aoa-hold")</script>
</binding>
</radio>
<input>
<row>2</row>
<col>2</col>
<property>/autopilot/settings/target-aoa-deg</property>
<live>true</live>
<binding>
<command>dialog-apply</command>
</binding>
</input>
<text>
<label>Altitude Hold</label>
<halign>right</halign>
<row>3</row>
<col>0</col>
</text>
<radio>
<row>3</row>
<col>1</col>
<property>/sim/gui/dialogs/autopilot/altitude-hold</property>
<live>true</live>
<binding>
<command>nasal</command>
<script>alt.set("altitude-hold")</script>
</binding>
</radio>
<input>
<row>3</row>
<col>2</col>
<property>/autopilot/settings/target-altitude-ft</property>
<live>true</live>
<binding>
<command>dialog-apply</command>
</binding>
</input>
<text>
<label>AGL Hold</label>
<halign>right</halign>
<row>4</row>
<col>0</col>
</text>
<radio>
<row>4</row>
<col>1</col>
<property>/sim/gui/dialogs/autopilot/agl-hold</property>
<live>true</live>
<binding>
<command>nasal</command>
<script>alt.set("agl-hold")</script>
</binding>
</radio>
<input>
<row>4</row>
<col>2</col>
<property>/autopilot/settings/target-agl-ft</property>
<live>true</live>
<binding>
<command>dialog-apply</command>
</binding>
</input>
<text>
<label>NAV1 Glideslope</label>
<halign>right</halign>
<row>5</row>
<col>0</col>
</text>
<radio>
<row>5</row>
<col>1</col>
<property>/sim/gui/dialogs/autopilot/gs1-hold</property>
<live>true</live>
<binding>
<command>nasal</command>
<script>alt.set("gs1-hold")</script>
</binding>
</radio>
</group>
<empty>
<stretch>true</stretch>
</empty>
</group>
<!-- End of Pitch/Altitude VBox -->
</group>
<hrule/>
<group>
<!-- Passive Mode Toggle -->
- now that XML dialogs run their own Nasal namespace and have <open> and <close> block, remove autopilot helper file autopilot.nas and (re)implement its functionality in autopilot.xml - make AP dialog "bidirectional" and "live": all input fields are <live> (i.e. they are updated as the autopilot settings are changed, for example by panel actions or property browser changes) - dialog input is only forwarded to the AP; no direct checkbox/radiobutton handling through widget operation, instead: - changes to the AP properties operate checkboxes/radiobuttons This makes the AP dialog always reflect the AP state. If the AP refuses one setting and sets it back to something else, then the dialog will immediately react and show the actual setting.
2006-04-05 20:24:21 +00:00
<layout>hbox</layout>
<checkbox>
Update autopilot dialog to use a new flag, to give feedback when the GPS/route-manager is driving the true heading.
2010-03-27 12:19:52 +00:00
<label>FlightDirector Mode</label>
<halign>center</halign>
<property>/autopilot/locks/passive-mode</property>
<live>true</live>
<binding>
<command>dialog-apply</command>
</binding>
<binding>
<command>property-toggle</command>
</binding>
- now that XML dialogs run their own Nasal namespace and have <open> and <close> block, remove autopilot helper file autopilot.nas and (re)implement its functionality in autopilot.xml - make AP dialog "bidirectional" and "live": all input fields are <live> (i.e. they are updated as the autopilot settings are changed, for example by panel actions or property browser changes) - dialog input is only forwarded to the AP; no direct checkbox/radiobutton handling through widget operation, instead: - changes to the AP properties operate checkboxes/radiobuttons This makes the AP dialog always reflect the AP state. If the AP refuses one setting and sets it back to something else, then the dialog will immediately react and show the actual setting.
2006-04-05 20:24:21 +00:00
</checkbox>
Update autopilot dialog to use a new flag, to give feedback when the GPS/route-manager is driving the true heading.
2010-03-27 12:19:52 +00:00
</group>
Gray-out dependant options, uniform close button
2010-12-15 12:43:09 +00:00
GUI layout management and a few visual/eye-candy modifications. See DOCS/README.layout in the base package for details, along with the modified dialog files.
2004-05-12 15:37:17 +00:00
</PropertyList>
Copy permalink