- PropertyObject: remove additional "values" member again
- don't create entry lists for <list>, <select>, and <combo> at dialog
creation and delete them on dialog close, but let a separate class
fgValueList handle this. The three widgets are now subclassed and the
derived widget lets fgValueList manage the lists
- make <select> consistent with <list>. This breaks backwards
compatibility, but not a single dialog in fgfs uses it and did so
since ... forever. (Shoot me!)
Rationale: now that dialogs are a bit more dynamic than they used to be
(thanks to embedded Nasal), we have to delete and recreate entry lists
during dialog use. Deleting only at dialog closing doesn't cut it anymore.
Especially list widgets that are updated several times per second would
use up a lot of memory otherwise. The route-manager doesn't update that
often, but it did already leak. One TODO less. :-)
signals, this is meant for attaching listeners. The ufo will use that to
hide/reveal the status line in screenshots. The following signal properties
are now available:
/sim/signals/exit ... set to 1 right before quitting
/sim/signals/reinit ... set to 1 on re-init (Shift-Esc)
/sim/signals/screenshot ... set to 1 before and to 0 after screenshot
/sim/signals/click ... set to 1 after mouse clicks at terrain, signalling
that the geo coords in /sim/input/click/ were updated
only used by the <list> widget. It allows to "dialog-update" the list,
which rescans the <value> children and redraws the list widget with new
contents. The old contents are only freed at dialog close, which should
eventually get changed.
two almost identical functions for these methods. It only forces to repeat
the redundancy for every small change to either.
- abstract out generation and destruction of plib string arrays
- abstract out generation of lists from <value> children
used in dialog.cxx to allow XML dialogs access to their own prop tree via
Nasal's cmdarg(). That way dialogs can generate dynamic content, such as
list entries.
list) and the arrows are clicked (patch sent to plib; workaround it to
be removed once fgfs officially depends on a plib version that includes
the fix)
- fix (very unlikely) crash in case the widget is redrawn between list
destruction and setting of the new list.
colors: <color-{{back,fore}ground,highlight,label,legend,misc,editfield}>
<input-misc>, for example, sets the input field cursor color, <input-legend>
the input field text color. (This feature was always planned as part of the
'theming' capabilities, and most code is already in place. Only this line
was apparently fogotten. :-)
<property>, except if they are activated, in which case the user input
should, of course, not get overwritten. But if such an input was active and
the user selected a different widget, then its contents were dropped.
Fix that by setting the "DownCallback" for live input fields.
- reduce it to 20 (30 is excessive and didn't match the property brower look)
- call puSlider with this size explicitly (otherwise its size is derived
from the font size, unlike the arrow buttons!)
respected, and black text on dark grey is a bit hard to read).
TODO: - submit that for inclusion in plib's puAuxList
- drop custom version and use plib's (after 0.9.10)
entry was selected. Return 0 in this case, not an invalid string address
(causing segfaults).
dialogs.cxx: don't set property if no list entry was chosen.
<nasal>
<open>print("I'm called on dialog open")</open>
<close>print("I'm called on dialog close")</close>
</nasal>
All Nasal runs in a dialog namespace, so that variables and functions
defined in the <open> block can be used in <binding>s, etc. This is
especially useful for <radio> button handling. See "location-in-air.xml".
right corner, not those that are result of centering a dialog if no x/y are
given. This centers screen.log messages correctly. But maybe we have to
rethink that special meaning of negative coords altogether.
Erik Hofman:
This patch contains an update to net_ctrls.hxx that adds an extra 100 bytes
(or an equivalent of 25 (u)int32_t types) of reserved space. This could be
used to make the protocol forward and backward compatibel within a certain
scope. Be sure to read the instructions at the begining of the header file
when addinf new variables.
