- allow turning on/off extra widgets for developers (HUD dialog: colors,
rendering dialog: visualization of shadow edges), and to turn on/off new
- property key handler ('/'-key)
Both features are off by default, and their state is saved to autosave.xml.
/sim/current-view/dynamic-view. There are additionally <dynamic-view>
settings per view, but those only enable it for that view if it's
globally turned on.
algorithm (needed for the file selector and useful for other purposes, like
assembling lists of livery or screenshot files etc.)
- io.nas: move fixpath to string.nas (it's not only useful for file paths
but can also be used for property paths)
- screen.nas: move trim to string.nas (used by screen.nas and nasal-console.xml)
- gui.nas: add pattern matching to FileSelctor
- ufo.nas: use patterm matching (only *.ac and *.xml files shall be listed)
/sim/gui/dialogs/file-select/directory, the selected file's full path
is returned in /sim/gui/dialogs/file-select/directory. There will be
a gui.file_selector class that allows to have more than one of these
dialogs open, where each of them reports the result to a callback function.
The dialog toggles dotfile display with ctrl-click on the "." entry,
and switches to FG_ROOT and FG_HOME with ctrl-click and shift-click on
the ".." entry.
This dialog is ATM not used anywhere in fgfs, but might be needed by
add-ons, much like the xml.nas code. Note that backslashes are converted
to slashes, which should ensure that no characters can be sneaked in
on UNIX systems. This breaks files containing escaped characters on
MS Windows. Fix for that on request. :-) Special characters (like German
umlauts) aren't displayed correctly, but properly returned. (Depending
on the plib font.)
gui/menubar.xml: Tim Moore:
These patches implement a command to dump the entire OSG scene graph as
a .osg text file. While large, this allows debuggers to really see
what's happening in the scene graph.
all code shares a common namespace, so variables defined in one tab can
be used in another during the whole fgfs session
- make code persistent (saved in autosave.xml)
- better error messages (code borrowed from nasal/lib/interactive.nas)
- clear button (replaces close button, which is now on the title bar)
- help button (explains how to add more tab buttons, etc.)
$FG_ROOT/gui/dialogs/tutorial.xml. It combines the former selection
and description dialogs, which makes browsing much more pleasant.
No more switching back and forth between the two old dialogs. Also,
the <list> box can handle a bigger number of tutorials than the
<combo> box could.
- remove comments from the top of tutorial.nas. The documentation is
now $FG_ROOT/Docs/README.tutorials
preferences.xml gui/menubar.xml gui/dialogs/rendering.xml
Added Files:
Nasal/multiplayer.nas gui/dialogs/chat.xml
gui/dialogs/chat_full.xml:
the data part of Stuarts multiplayer/chat patch
but as this is an integral part of FlightGear, I don't want to push for it.
Try out and comment. It's available under "Debug/Property Browser". Note,
that this isn't the slow pure-Nasal implementation, but a regular dialog
using a c++ based widget. Only the handling is done in Nasal, so there should
really be not performance degradation compared with the old dialog.
Easter Eggs: some entries work differently when the Control-key is pressed:
"." -> toggle output of SGPropertyNode flags
".." -> go to root (not just one dir level)
bool entry -> toggle bool entry value
has to be given before a --wp or --flight-plan option to work.)
- let the "Remove" button remove the first entry by default, not the last.
(Note that you can remove any entry if you selected it in the list first.
Likewise you can insert a new waypoint at any position by selecting the
respective entry.)
<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.
