The change introduced in commit 8c7fc119 to go to the last checklist
on open causes a problem when the first checklist has multiple pages.
If the last opened checklist did not have multiple pages, the previous
and next page buttons are still shown.
This commit runs the same binding as used by the combo box to reset
the visibility of these buttons immediately before the page is
displayed.
The change introduced in commit 8c7fc119 to go to the last checklist
on open causes a problem when the first checklist has multiple pages.
If the last opened checklist did not have multiple pages, the previous
and next page buttons are still shown.
This commit runs the same binding as used by the combo box to reset
the visibility of these buttons immediately before the page is
displayed.
Now that request-metar/clear-metar commands work properly, use those
instead of direct manipulation of metar properties. Also, don't write
to properties intended for read-only use.
Replaces existing Nasal/failures.nas script with a programmable failure
manager. The failure manager allows dynammic creation and removal of
failure modes, on demand activation and a flexible set of triggers.
The public interface can be found in Nasal/FailureMgr/public.nas
Aircraft/Generic/Systems/failures.nas provides a library of triggers and
failure actuators ready to use for programming the failure manager.
A compatibility layer is included under
Aircraft/Generic/Systems/compat_failure_modes.nas.
This compatibility layer is currently loaded on startup and programs the
FailureMgr to emulate the former behavior (same set of failure modes and
compatible interface through the property tree).
This first milestone is only intended to replace the failure management
engine underneeth with minimum visible changes, and hopefully no aircraft
breakages. Future milestones will build upon this to add a Canvas based
procedural GUI and example integration on aircrafts.
Fix the main bugs, add features and convert most of the layers.
Move/refactor some things as well. Add a canvas map dialog next to the
built-in one -- it's not 100% functional but it's quite close actually.
As before, the excitement has been taking place at our team clone.
https://gitorious.org/fg/canvas-hackers-fgdata/commits/0b4cc84
(topics/canvas-map-dialog branch this time, current HEAD in above URL.)
Replace the temporary UI with real solutions, in the view dialog
(for tooltips/popups) and a new 'input config' dialog accessed via
the file menu.
Make the mouse-cycle popup explicitly optional since some people
strongly dislike it.
* make into singleton class
* make sure FOV changes take place *immediately* when required
* current FOV is scaled with changes, though being preserved: resizing
window and going back ends up with the same FOV
Restore pre-2.12 functionality where GPS search was persistent across
opening and closing the GPS dialog. Since the state is now in Nasal
we need to ensure a couple of variables outlive the dialog itself.
Now tile refresh is gone, this dialog is much simpler.
(Scenery can still be reloaded from the Rendering dialog or sim reset,
but the pager will always wait on TerraSync)
- Fix bug when opening weather dialog when in manual mode.
- Move buttons to be opposite the appropriate radio buttons
- Keep buttons visible at all times.
- Update description to account for recent Basic Weather -> ALS integration.
These are then attached to buttons on the checklist dialog allowing
the user to ask the computer to execute the checklist step, which
they can observe.
State is saved to autosave.xml, and --disable-scenarios still avoids
loading any scenario at launch. At runtime scenarios can be added or
removed as normal.
Drive off the 'show view names' checkbox in the view dialog for now, this might
evolve into a generic 'on-screen hints' control to avoid an explosion of
GUI checkboxes.
Also add a GUI checkbox (oh the irony...) to disable mouse flight-controls, to
keep AndersG and Emilian happy.
This is temporary (hopefully!), to allow experimentation with different UX options in the near future. Right now it basically does nothing. As part of this, factor mouse-mode cycling into a separate command, and add some feedback. Feedback mechanism needs work, currently abusing the copilot facility.
Checklists may now be split into individual sections made up
of <pages> containing the <item> tags. Each page is displayed
individually with Previous/Next buttons to allow navigation.
Checklists items also support <marker> tags. These display
a marker when a ? button is pressed next to the checklist item.
The format is identical to that of the tutorial system.
