Unfortunately, there's no simple way to distinguish them. plib has no
user defined widget classes, and getTypeString() -- which could be used
for that -- isn't virtual. Sigh. I'll discuss the problem on the plib list.
For now I can only offer an ugly workaround. (Don't look closely!)
- 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. :-)
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.
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.
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.
to other color than "Yeukky Pink"; #undef'ed for older plib versions; plib
patch will be made available in case fgfs 0.9.9 is released before plib 0.8.5
right/upper screen edge (analogous to the --geometry spec), assuming
that we never want to draw outside the screen area; for this to work
we need to write the original x/y coords back to overwrite the absolute,
positive values that the layouter stored there
property (e.g. <keynum>49</keynum>). The numbers are the same as in
keyboard.xml. (Could later be replaced/enhanced with <key>Ctrl-a</key>
notation.) This does, of course, only work for widgets with assigned
bindings.
or data blocks) from layouter and dialog creator. This is required for
dynamically generated/modified dialogs. Parts in the XML file can be
hidden and turned on by the C++ code. Other hidden parts can be used
as templates that are multiply used. Hidden datablocks can contain
strings that are used in dialog context, that are easier to translate
or modify in the XML file.
LayoutWidget::setDefaultFont() wants puFont* /and/ pointsize as extra
parameters, when puFont knows its pointsize anyway. Didn't want to change
that yet, though.) Now the HELVETICA_10 font makes actually sense. :-)
- add <vrule>
- allow elements to default to foreground color (black)
- remove redundant if (foo) delete foo;
The rules do currently need a dummy child for the layouter to work correctly,
(<hrule><foo/></hrule>). The goal is to make a simple <hrule/> work.
showDialog() is careful not to create a new FGDialog() if a dialog with the
same name is already open (active). But at this point it is already too late:
newDialog(), which was called shortly before, has already overwritten the
dialog properties. This leads to animated garbage in the best case, and a
segfault in format_callback() in the worst case.
- GUI::newDialog(): Don't you overwrite properties of an active dialog!
- GUI::readDir(): You may do that, but delete the old dialog first!
(necessary for reloading the GUI)
- FGDialog::makeObject(): only set format_callback() with setRenderCallback()
if the property is "live". Otherwise, only call it once at construction
time. This isn't only a performance improvement. Without this the label
was growing until it hit the limit (256).
The previous message wasn't totally correct. Strings are now allowed, too. And
the pattern is now '[ -+#]?\d*(\.\d*)?l?[fs]' and *may* be embedded in a string.
There may only be one %s or %f, though. %% is allowed in the preamble/postamble.
(Yes, %ls is allowed, too, and treated as %s.)
Also, "end" is superfluous now.
Printing floats in dialogs with 8 digits after the comma is inappropriate
for most cases.
- implement a "format" property for "text" gui elements (a.k.a. pui label).
Number formats are set by strtod/snprintf, while formats on non-numbers
are replaced by "%s". Practical example in the upcoming material.nas update.
Valid formats regex: '%[ -]?\d*(\.\d*)?l?f' (IOW: the format must begin
with '%' and end with 'f').
# Nasal:
number = dialog.addChild("text");
number.set("label", "3.1415926");
number.set("format", "%.3f");
The dialog handling has been written at a time when only one dialog was
shown at the same time, and dialogs were shallow -- with only children, but
no grand-children. This makes finding a draggable spot on modern, dialogs
with nested objects quite a challenge. The patches fixes this, and other things:
- check full object tree on button press, not only the outmost layer;
and don't give up just because we are in *something* (which could well be
something harmless, like a group); only ignore a few, sensible objects
(we don't want to drag after a click on a button or into an input field)
- don't lose dialogs as easily when dragging too fast (it does still happen
if one manages to enter an editable field while dragging, but this is
a plib problem and I don't feel like fixing that now :-)
- don't "live"-update input fields while they are in edit mode
- remove some "if (foo) delete foo;" redundancy
I have made the
'Select Airport from List' option in FlightGear work
(I think) properly. I have some concerns about the
solution, which could be broken by changes to plib (if
they re-use the value I have assigned to
PUCLASS_LIST), but for the moment it seems to work OK.
Erik Hofman:
A request has been sent to John Fay to include the puList
code in the puAux subdirectory of plib so expect some
changes for future version of FlightGear.
I'm attaching a small change to Andy's dialog.cxx that I needed
to make so that it enables XML/Nasal-dialogs to also contain
puLargeInput boxes.
The text will be retrieved/buffered from/within a specified
property tree, like:
<textbox>
<x>100</x>
<y>100</y>
<width>200</width>
<height>100</height>
<property>/gui/path-to-text-node/contents</property>
<slider>15</slider>
<editable>true</editable>
</textbox>
little larger.
The text widget can now be meaningfully associated with a property; in
PUI, it's "value" isn't the same thing as its label, but we can hack
things to treat them symmetrically.
Commit an experimental "live" property that can be set on widgets to
cause them to update their values every frame. This works great for
text widgets, as above. Note that this synchronization is input-only:
no support is provided (or needed -- the GUI only changes when the
user does something) for writing those properties out every frame.
for a while, it turned out to be pretty easy to implement. Also, the
property picker is now non-modal, I presume the modality wasn't an
intentional feature.
TITLE: Using delete [] versus delete
The extra "[]" warns the compiler that there is a whole array of objects here so that P's destructor must be called on each element of the array rather than just on P itself (which would be equivalent to the first element only).
Fix memory leaks (PUI doesn't make copies of lists, so we have to make
our own copies and keep pointers to them).
Adjust for new method names in NewGUI.
Move the GUIInfo struct into the cxx file so that it's not part of the
public interface.
