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.
even be more than once in the same list. We need to remove all such instances,
or the a pointer to TowerPlaneRec may become invalid and cause crashes.
The proper fix would, of course, be to be careful with state changes and
to prevent *any* duplication of entries. [OK'ed by David]
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. :-)
a crash when using the model manager from XML files (which apparently
nobody does, anyway ;-) Now those models work (again), but have no
shadows. Those placed at runtime (e.g. via ufo) still have a shadow.
<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.
Here is one patch that to make FlightGear run without floating point
exceptions on FreeBSD. Apparently, if we do not ignore floating point
exceptions per this patch, there is some occasional condition where the
nvidia driver is involved in delivering spurious floating point exceptions
to the fgfs process, causing it to core-dump occasionally without the patch.
With only this patch, FlightGear will compile and run properly on
FreeBSD 6.X as long as the nvidia accelerated driver is installed,
modulo proper switches to the SimGear and FlightGear configure script
executions.
Again, kudos to your team for the great work on the big release
push; it is super to see things come together like this!
- 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)
I had inadvertently terminated a data line when reaching a tab character after
initial data was supplied. I tested the lightning file and it now appears to
read in correctly.
